You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Juergen Richtsfeld <ju...@segue.at> on 2005/12/19 12:18:35 UTC
checkout performance
hi!
I'm just about to try around with subversion. But it seems to be quite slow.
my server has about 1GHZ, 1GB ram, windows 2000 server.
my repository has about 350 MB in about 11000 files. my repository was created with default settings (svn 1.2) (bdb). my client is a P4 3Ghz with 1 gig ram.
doing a clean checkout takes about 12 minutes with apache and about 10 minutes with svnserve (100 mbit lan).
I'm currently testing with fsfs. are my measurements normal? i think it's quite slow. the problem is, we're currently using ms sourcesafe, which is much faster (but lacks lot of features).
i alreday found (and read) the other performance threads, but i didn't find any possibility to improve performance.
jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Jose Thomas <jo...@gmail.com>.
>
> To make you feel better: I serve Subversion on a super fast Linux Enterprise
> server with 4 Xeon processors, tons of disk space, and tons of RAM. All the
> users' desktop clients are Pentium4 @3-4GHZ with WinXP + 512MB to 1GB of
> RAM. And a complete fresh check out still takes 20-25 minutes for a 250MB
> project! Sometimes my patience just runs out. Not to mention it's
> extremely CPU intensive and takes my PC hostage. I literally cannot do
> anything until SVN is done checking out. NOW, consider yourself lucky :)
>
I think you may need to check the services running on your windows
machine. Virus scanners & indexing services are known to slow down the
checkout time. Check the I/O writes in your Task Manager. Remember,
for each file in the repository, svn client needs to create 2+ files
on the local disk.
Anyway checkout is a one time operation, u can schedule it when u go
home in the evening, :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Richard Musil <ri...@gmail.com>.
Paul Koning wrote:
> Richard> Now, while you are mentioning this, I recall I have seen on
> Richard> ethereal capture session that for each file there are two
> Richard> Kerberos authentication requests (I do not use keytab) - the
> Richard> first one failing.
>
> Richard> As far as SVN documentation goes, it seems to be desired
> Richard> behavior (auth check on each access).
>
> That doesn't make any sense.
>
> It is only useful to authenticate often enough to catch invalidation
> of authentication credentials. A person's identity doesn't change
> from millisecond to millisecond! Authentication results should be
> cached. Ideally, there is external information available that guides
> the caching rules. (For example, public key certificates have such
> information in them.)
To avoid misunderstanding, please read the last sentence "It seems to be
desired behavior (according to SVN doc) to do authorization check on
each file access."
Why is this authorization check propagated into authentication module is
another question. It seems that each access to file in repository
represents standalone request and authorization credentials are cached
only for the time request is served.
This idea (keeping it valid only for the time of the request) does not
seem to be wrong either - only the nature of SVN normal operation does
unfortunately suffer from it - a lot.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Richard" == Richard Musil <ri...@gmail.com> writes:
Richard> Now, while you are mentioning this, I recall I have seen on
Richard> ethereal capture session that for each file there are two
Richard> Kerberos authentication requests (I do not use keytab) - the
Richard> first one failing.
Richard> As far as SVN documentation goes, it seems to be desired
Richard> behavior (auth check on each access).
That doesn't make any sense.
It is only useful to authenticate often enough to catch invalidation
of authentication credentials. A person's identity doesn't change
from millisecond to millisecond! Authentication results should be
cached. Ideally, there is external information available that guides
the caching rules. (For example, public key certificates have such
information in them.)
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Richard Musil <ri...@gmail.com>.
Now, while you are mentioning this, I recall I have seen on ethereal
capture session that for each file there are two Kerberos authentication
requests (I do not use keytab) - the first one failing.
As far as SVN documentation goes, it seems to be desired behavior (auth
check on each access).
I thought that turning on KrbSaveCredentials for mod_auth_kerb might
solve this, but I have not verified it afterwards. This should preserve
credentials until the request is served - the question is, what is
exactly one request from SVN point of view and whether there has to be
special support for this feature from authz_svn module.
Do you know how it is done in mod_auth_ldap? Does this module implement
credentials caching on its own? And if yes, for how long?
Richard
Tony Butt wrote:
> We run our server on a 2.8HGz Xeon processor running SuSE Enterprise
> Linux 9, running apache2.0.49 and subversion 1.2.3.
>
> Our authentication system uses mod_auth_kerb to refer to a Windows 2000
> domain controller, and authz_svn to control access to various parts of
> the repository. There seems to be a bottleneck with the interaction
> between mod_auth_krb and mod_authz_svn, where the authentication
> information is not a cached, but checked for EACH FILE in the repository
> that a transaction looks at.
>
> I found that something like 4 DNS lookups were also being performed
> for each file, and fixed most of that by hardcoding IP addresses into
> the krb.conf configuration file. This has reduced the server CPU load,
> but checkouts and log operations are still much slower than we would
> like, and something like 10x slower than using svn: protocol, with no
> authz_svn (and no auth_kerb). We like mod_auth_kerb for the single sign
> on ability it gives us, but the lack of credential caching is really
> killing our performance. We have experimented with bdb and fsfs
> backends, but found no definitive performance differences, so you might
> be able to gain a little there, but not much.
>
> In all likelihood, your problems are related to authentication and
> authorisation - maybe mod_auth_ldap would be better for you?
>
> Tony Butt
>
> CEA Technologies
> Canberra, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Tony Butt <to...@cea.com.au>.
We run our server on a 2.8HGz Xeon processor running SuSE Enterprise
Linux 9, running apache2.0.49 and subversion 1.2.3.
Our authentication system uses mod_auth_kerb to refer to a Windows 2000
domain controller, and authz_svn to control access to various parts of
the repository. There seems to be a bottleneck with the interaction
between mod_auth_krb and mod_authz_svn, where the authentication
information is not a cached, but checked for EACH FILE in the repository
that a transaction looks at.
I found that something like 4 DNS lookups were also being performed
for each file, and fixed most of that by hardcoding IP addresses into
the krb.conf configuration file. This has reduced the server CPU load,
but checkouts and log operations are still much slower than we would
like, and something like 10x slower than using svn: protocol, with no
authz_svn (and no auth_kerb). We like mod_auth_kerb for the single sign
on ability it gives us, but the lack of credential caching is really
killing our performance. We have experimented with bdb and fsfs
backends, but found no definitive performance differences, so you might
be able to gain a little there, but not much.
In all likelihood, your problems are related to authentication and
authorisation - maybe mod_auth_ldap would be better for you?
Tony Butt
CEA Technologies
Canberra, Australia
Res Pons wrote:
> Juergen,
>
> To make you feel better: I serve Subversion on a super fast Linux
> Enterprise server with 4 Xeon processors, tons of disk space, and tons
> of RAM. All the users' desktop clients are Pentium4 @3-4GHZ with WinXP
> + 512MB to 1GB of RAM. And a complete fresh check out still takes
> 20-25 minutes for a 250MB project! Sometimes my patience just runs
> out. Not to mention it's extremely CPU intensive and takes my PC
> hostage. I literally cannot do anything until SVN is done checking
> out. NOW, consider yourself lucky :)
>
>
>
>
> ----Original Message Follows----
> From: Kjell H Andersen <kh...@lentic.net>
> To: Ryan Schmidt <su...@ryandesign.com>
> CC: Juergen Richtsfeld <ju...@segue.at>, users@subversion.tigris.org
> Subject: Re: checkout performance
> Date: Mon, 19 Dec 2005 15:08:27 +0100
> MIME-Version: 1.0
> Received: from tigris.org ([64.125.133.100]) by
> bay0-mc3-f3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211);
> Mon, 19 Dec 2005 06:15:35 -0800
> Received: (qmail 13122 invoked by uid 5000); 19 Dec 2005 14:09:57 -0000
> Received: (qmail 12974 invoked from network); 19 Dec 2005 14:09:37 -0000
> X-Message-Info: JGTYoYF78jFSuACWoi/6zybCOlS8nnQQqeMXsbFvV/Y=
> Mailing-List: contact users-help@subversion.tigris.org; run by ezmlm
> Precedence: bulk
> X-No-Archive: yes
> list-help: <ma...@subversion.tigris.org>
> list-unsubscribe: <ma...@subversion.tigris.org>
> list-post: <ma...@subversion.tigris.org>
> Delivered-To: mailing list users@subversion.tigris.org
> User-Agent: Thunderbird 1.5 (Windows/20051025)
> References: <31...@atmail1.segue.com>
> <59...@ryandesign.com>
> Return-Path: users-return-42597-pons32=hotmail.com@subversion.tigris.org
> X-OriginalArrivalTime: 19 Dec 2005 14:15:36.0035 (UTC)
> FILETIME=[AE33CB30:01C604A6]
>
> I've had some experience with large check-out/in. The problem isn't
> the size itself, but the number of files.It looks like most file
> systems has a noticeable overhead for each file it has to create. I've
> had some problems related to this when checking out a working copy to
> a nfs mount. NFS performs really poor when trying to perform
> operations on many files.
>
> But to answer your question, I don't think 10-12 minutes are that much
> considering the number of files. Remember that all later operations
> will only be performed on a small amount of data. If you keep your
> working copy on a network drive, you can probably improve performance
> by moving it to your local drive, but that might lead to some backup
> issues..
>
> Kjell
>
>
> Ryan Schmidt wrote:
>> On Dec 19, 2005, at 13:18, Juergen Richtsfeld wrote:
>>
>>> I'm just about to try around with subversion. But it seems to be
>>> quite slow.
>>>
>>> my server has about 1GHZ, 1GB ram, windows 2000 server.
>>> my repository has about 350 MB in about 11000 files. my repository
>>> was created with default settings (svn 1.2) (bdb). my client is a P4
>>> 3Ghz with 1 gig ram.
>>>
>>> doing a clean checkout takes about 12 minutes with apache and about
>>> 10 minutes with svnserve (100 mbit lan).
>>>
>>> I'm currently testing with fsfs. are my measurements normal? i think
>>> it's quite slow. the problem is, we're currently using ms
>>> sourcesafe, which is much faster (but lacks lot of features).
>>
>> I don't know if 10 or 12 minutes is normal for a working copy of that
>> size. I have heard that checkouts on Windows take longer than on
>> other operating systems. But the important thing to remember is that
>> you only do a full checkout very rarely, usually just when you first
>> start working with Subversion. From then on you can just update the
>> existing working copy, which should be much faster.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
> _________________________________________________________________
> FREE pop-up blocking with the new MSN Toolbar – get it now!
> http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Re: checkout performance
Posted by Gunter Ohrner <G....@post.rwth-aachen.de>.
Patrik Rak wrote:
> If you use BDB, you might consider using FSFS instead. I did not measure
> the check out speeds of BDB, the initial import speed was so terribly slow
> I gave up and went with FSFS right away.
Funny, using an 1.1.x server on a really low-end machine I noticed just the
opposite. :-)
Checkin in the file list was pretty slow, but the actual data transmission
phase was several times faster using BDB than with an FSFS backend.
Greetings,
Gunter
--
The three most dangerous things in the world are a programmer with a
soldering iron, a hardware type with a software patch and a user with
an idea.
*** PGP-Verschlüsselung bei eMails erwünscht :-) *** PGP: 0x1128F25F ***
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Andy Levy <an...@gmail.com>.
See if it's possible to exclude the WC directory from the scanner's view.
Although that would put a whole bunch of users at risk, if one
person's WC got infected, it would spread to the repository on the
next commit and then to other WCs upon update. Maybe a temporary
disable is the smarter way to go.
But I'd take it as a good time to take a forced break. Many desk-job
folks don't get up and walk around enough, it gets to be bad for your
back and circulation.
On 12/20/05, Res Pons <po...@hotmail.com> wrote:
> Thanks! Since I can't disable my virus scanner temprarily (or should I?), I
> guess check out is a great excuse to walk away from my desk for a break?! :)
>
> ----Original Message Follows----
> From: Andy Levy <an...@gmail.com>
> To: users@subversion.tigris.org
> Subject: Re: checkout performance
> Date: Tue, 20 Dec 2005 14:40:52 -0500
> MIME-Version: 1.0
> Received: from tigris.org ([64.125.133.100]) by bay0-mc1-f8.bay0.hotmail.com
> with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 11:58:13 -0800
> Received: (qmail 17456 invoked by uid 5000); 20 Dec 2005 19:40:55 -0000
> Received: (qmail 17431 invoked from network); 20 Dec 2005 19:40:53 -0000
> X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
> Mailing-List: contact users-help@subversion.tigris.org; run by ezmlm
> Precedence: bulk
> X-No-Archive: yes
> list-help: <ma...@subversion.tigris.org>
> list-unsubscribe: <ma...@subversion.tigris.org>
> list-post: <ma...@subversion.tigris.org>
> Delivered-To: mailing list users@subversion.tigris.org
> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
>
> h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
>
> b=Ebp6L7W71/X/mrY6ijLdxaPafeB/3EnTrOZGGEuKueE8ubiy/O+atn7dHHSmwRyipCWxGQ95bzbOet1yYvixcLDH4PIxkFEodO10vWZFYlOGCibpq62bbn0lDZdLdUkbDmfFD55MkEzshAgutdNaQ18xAVmwCM+gZHkM6PwfGwY=
> References:
> <Pi...@falcon.bh.mindwarestudios.com>
> <BA...@phx.gbl>
> Return-Path: users-return-42684-pons32=hotmail.com@subversion.tigris.org
> X-OriginalArrivalTime: 20 Dec 2005 19:58:13.0901 (UTC)
> FILETIME=[B60EF3D0:01C6059F]
>
> On 12/20/05, Res Pons <po...@hotmail.com> wrote:
> > I use FSFS & run SVN on Apache. Yeah I figured the bottle necking could
> be
> > happening on the windows desktop. And not just mine. All my users have
> the
> > same complaints. Any suggesting for optimization? I did suggest to them
> to
> > run chkdsk /f or scandisk and force a defrag.
>
> One performance-killer can be on-access virus scanners (desktop or
> server, or both). You're creating/modifying a *lot* of files doing
> the checkout (on the desktop) and that can sometimes bog down in the
> virus scan.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
--
Andy
http://home.rochester.rr.com/alevy/
---
Never tell people how to do things. Tell them what to do and they will
surprise you with their ingenuity.
-George S. Patton
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Andy Levy <an...@gmail.com>.
On 12/20/05, Res Pons <po...@hotmail.com> wrote:
> I use FSFS & run SVN on Apache. Yeah I figured the bottle necking could be
> happening on the windows desktop. And not just mine. All my users have the
> same complaints. Any suggesting for optimization? I did suggest to them to
> run chkdsk /f or scandisk and force a defrag.
One performance-killer can be on-access virus scanners (desktop or
server, or both). You're creating/modifying a *lot* of files doing
the checkout (on the desktop) and that can sometimes bog down in the
virus scan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Res Pons <po...@hotmail.com>.
I use FSFS & run SVN on Apache. Yeah I figured the bottle necking could be
happening on the windows desktop. And not just mine. All my users have the
same complaints. Any suggesting for optimization? I did suggest to them to
run chkdsk /f or scandisk and force a defrag.
I have a question on upgrading SVN. When I download the new .rpm, do I need
to bring down apache and can I just install the newer version seamlessly
while the server's running? And does it by defualt install on top of the
old version and overwrite the old installation or completely to a new
directory?
Thanks.
----Original Message Follows----
From: Patrik Rak <pa...@mindwarestudios.com>
To: Res Pons <po...@hotmail.com>
CC: "juergenr@segue.at" <ju...@segue.at>,users@subversion.tigris.org
Subject: Re: checkout performance
Date: Tue, 20 Dec 2005 10:48:53 +0100 (CET)
MIME-Version: 1.0
Received: from eagle.mindwarestudios.com ([82.119.242.130]) by
bay0-mc10-f3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20
Dec 2005 02:02:07 -0800
Received: from hawk.bh.mindwarestudios.com (hawk.bh.mindwarestudios.com
[192.168.2.2])by eagle.mindwarestudios.com (Postfix) with ESMTPid
DC97C3679E; Tue, 20 Dec 2005 10:48:53 +0100 (CET)
Received: from falcon.bh.mindwarestudios.com (falcon.bh.mindwarestudios.com
[192.168.2.65])by hawk.bh.mindwarestudios.com (Postfix) with ESMTPid
BFCD313255; Tue, 20 Dec 2005 10:48:53 +0100 (CET)
Received: by falcon.bh.mindwarestudios.com (Postfix, from userid 1000)id
96C8F675; Tue, 20 Dec 2005 10:48:53 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])by
falcon.bh.mindwarestudios.com (Postfix) with ESMTP id 6C313495;Tue, 20 Dec
2005 10:48:53 +0100 (CET)
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
X-X-Sender: patrik@falcon.bh.mindwarestudios.com
References: <BA...@phx.gbl>
Return-Path: patrik@mindwarestudios.com
X-OriginalArrivalTime: 20 Dec 2005 10:02:08.0273 (UTC)
FILETIME=[70153810:01C6054C]
On Mon, 19 Dec 2005, Res Pons wrote:
>To make you feel better: I serve Subversion on a super fast Linux
>Enterprise server with 4 Xeon processors, tons of disk space, and tons of
>RAM. All the users' desktop clients are Pentium4 @3-4GHZ with WinXP +
>512MB to 1GB of RAM. And a complete fresh check out still takes 20-25
>minutes for a 250MB project! Sometimes my patience just runs out. Not to
>mention it's extremely CPU intensive and takes my PC hostage. I literally
>cannot do anything until SVN is done checking out. NOW, consider yourself
>lucky :)
What backend do you use, BDB or FSFS?
We use FSFS, our server is a lame 2.6GHz P4 with 1G RAM and I thought the
speed quite sucks when it checks out at 4MB/s (on repositories ranging from
2GB to 8GB). The CVS was able to check out the 8GB repository in less than
20 minutes (but of course the CVS suffers from the notoriously known
problems SVN has solved).
If you use BDB, you might consider using FSFS instead. I did not measure the
check out speeds of BDB, the initial import speed was so terribly slow I
gave up and went with FSFS right away.
Also notice that the FSFS format has improved in 1.2.x to speed up the check
outs, but you have to redump your 1.1.x repository to get that advantage.
However, the bottleneck in your case may be in the windows clients. The
windows filesystems are ridiculously slow when compared to Linux or Mac,
especially when the operation involves huge number of files.
Patrik
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Patrik Rak <pa...@mindwarestudios.com>.
On Mon, 19 Dec 2005, Res Pons wrote:
> To make you feel better: I serve Subversion on a super fast Linux Enterprise
> server with 4 Xeon processors, tons of disk space, and tons of RAM. All the
> users' desktop clients are Pentium4 @3-4GHZ with WinXP + 512MB to 1GB of RAM.
> And a complete fresh check out still takes 20-25 minutes for a 250MB project!
> Sometimes my patience just runs out. Not to mention it's extremely CPU
> intensive and takes my PC hostage. I literally cannot do anything until SVN
> is done checking out. NOW, consider yourself lucky :)
What backend do you use, BDB or FSFS?
We use FSFS, our server is a lame 2.6GHz P4 with 1G RAM and I thought the
speed quite sucks when it checks out at 4MB/s (on repositories ranging
from 2GB to 8GB). The CVS was able to check out the 8GB repository in less
than 20 minutes (but of course the CVS suffers from the notoriously known
problems SVN has solved).
If you use BDB, you might consider using FSFS instead. I did not measure
the check out speeds of BDB, the initial import speed was so terribly slow
I gave up and went with FSFS right away.
Also notice that the FSFS format has improved in 1.2.x to speed up the
check outs, but you have to redump your 1.1.x repository to get that advantage.
However, the bottleneck in your case may be in the windows clients. The
windows filesystems are ridiculously slow when compared to Linux or Mac,
especially when the operation involves huge number of files.
Patrik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Res Pons <po...@hotmail.com>.
Juergen,
To make you feel better: I serve Subversion on a super fast Linux Enterprise
server with 4 Xeon processors, tons of disk space, and tons of RAM. All the
users' desktop clients are Pentium4 @3-4GHZ with WinXP + 512MB to 1GB of
RAM. And a complete fresh check out still takes 20-25 minutes for a 250MB
project! Sometimes my patience just runs out. Not to mention it's
extremely CPU intensive and takes my PC hostage. I literally cannot do
anything until SVN is done checking out. NOW, consider yourself lucky :)
----Original Message Follows----
From: Kjell H Andersen <kh...@lentic.net>
To: Ryan Schmidt <su...@ryandesign.com>
CC: Juergen Richtsfeld <ju...@segue.at>, users@subversion.tigris.org
Subject: Re: checkout performance
Date: Mon, 19 Dec 2005 15:08:27 +0100
MIME-Version: 1.0
Received: from tigris.org ([64.125.133.100]) by bay0-mc3-f3.bay0.hotmail.com
with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 06:15:35 -0800
Received: (qmail 13122 invoked by uid 5000); 19 Dec 2005 14:09:57 -0000
Received: (qmail 12974 invoked from network); 19 Dec 2005 14:09:37 -0000
X-Message-Info: JGTYoYF78jFSuACWoi/6zybCOlS8nnQQqeMXsbFvV/Y=
Mailing-List: contact users-help@subversion.tigris.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
list-help: <ma...@subversion.tigris.org>
list-unsubscribe: <ma...@subversion.tigris.org>
list-post: <ma...@subversion.tigris.org>
Delivered-To: mailing list users@subversion.tigris.org
User-Agent: Thunderbird 1.5 (Windows/20051025)
References: <31...@atmail1.segue.com>
<59...@ryandesign.com>
Return-Path: users-return-42597-pons32=hotmail.com@subversion.tigris.org
X-OriginalArrivalTime: 19 Dec 2005 14:15:36.0035 (UTC)
FILETIME=[AE33CB30:01C604A6]
I've had some experience with large check-out/in. The problem isn't the size
itself, but the number of files.It looks like most file systems has a
noticeable overhead for each file it has to create. I've had some problems
related to this when checking out a working copy to a nfs mount. NFS
performs really poor when trying to perform operations on many files.
But to answer your question, I don't think 10-12 minutes are that much
considering the number of files. Remember that all later operations will
only be performed on a small amount of data. If you keep your working copy
on a network drive, you can probably improve performance by moving it to
your local drive, but that might lead to some backup issues..
Kjell
Ryan Schmidt wrote:
>On Dec 19, 2005, at 13:18, Juergen Richtsfeld wrote:
>
>>I'm just about to try around with subversion. But it seems to be quite
>>slow.
>>
>>my server has about 1GHZ, 1GB ram, windows 2000 server.
>>my repository has about 350 MB in about 11000 files. my repository was
>>created with default settings (svn 1.2) (bdb). my client is a P4 3Ghz with
>>1 gig ram.
>>
>>doing a clean checkout takes about 12 minutes with apache and about 10
>>minutes with svnserve (100 mbit lan).
>>
>>I'm currently testing with fsfs. are my measurements normal? i think it's
>>quite slow. the problem is, we're currently using ms sourcesafe, which is
>>much faster (but lacks lot of features).
>
>I don't know if 10 or 12 minutes is normal for a working copy of that size.
>I have heard that checkouts on Windows take longer than on other operating
>systems. But the important thing to remember is that you only do a full
>checkout very rarely, usually just when you first start working with
>Subversion. From then on you can just update the existing working copy,
>which should be much faster.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar � get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Kjell H Andersen <kh...@lentic.net>.
I've had some experience with large check-out/in. The problem isn't the
size itself, but the number of files.It looks like most file systems has
a noticeable overhead for each file it has to create. I've had some
problems related to this when checking out a working copy to a nfs
mount. NFS performs really poor when trying to perform operations on
many files.
But to answer your question, I don't think 10-12 minutes are that much
considering the number of files. Remember that all later operations will
only be performed on a small amount of data. If you keep your working
copy on a network drive, you can probably improve performance by moving
it to your local drive, but that might lead to some backup issues..
Kjell
Ryan Schmidt wrote:
> On Dec 19, 2005, at 13:18, Juergen Richtsfeld wrote:
>
>> I'm just about to try around with subversion. But it seems to be
>> quite slow.
>>
>> my server has about 1GHZ, 1GB ram, windows 2000 server.
>> my repository has about 350 MB in about 11000 files. my repository
>> was created with default settings (svn 1.2) (bdb). my client is a P4
>> 3Ghz with 1 gig ram.
>>
>> doing a clean checkout takes about 12 minutes with apache and about
>> 10 minutes with svnserve (100 mbit lan).
>>
>> I'm currently testing with fsfs. are my measurements normal? i think
>> it's quite slow. the problem is, we're currently using ms sourcesafe,
>> which is much faster (but lacks lot of features).
>
> I don't know if 10 or 12 minutes is normal for a working copy of that
> size. I have heard that checkouts on Windows take longer than on other
> operating systems. But the important thing to remember is that you
> only do a full checkout very rarely, usually just when you first start
> working with Subversion. From then on you can just update the existing
> working copy, which should be much faster.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checkout performance
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 19, 2005, at 13:18, Juergen Richtsfeld wrote:
> I'm just about to try around with subversion. But it seems to be
> quite slow.
>
> my server has about 1GHZ, 1GB ram, windows 2000 server.
> my repository has about 350 MB in about 11000 files. my repository
> was created with default settings (svn 1.2) (bdb). my client is a
> P4 3Ghz with 1 gig ram.
>
> doing a clean checkout takes about 12 minutes with apache and about
> 10 minutes with svnserve (100 mbit lan).
>
> I'm currently testing with fsfs. are my measurements normal? i
> think it's quite slow. the problem is, we're currently using ms
> sourcesafe, which is much faster (but lacks lot of features).
I don't know if 10 or 12 minutes is normal for a working copy of that
size. I have heard that checkouts on Windows take longer than on
other operating systems. But the important thing to remember is that
you only do a full checkout very rarely, usually just when you first
start working with Subversion. From then on you can just update the
existing working copy, which should be much faster.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org