Below is our configuration and performance data:
(Yes, I know we're not on the latest version. We've been at a critical
point in development so we have been unable to upgrade yet, but we will
be able to soon. I noticed that 1.2.x has some performance
improvements, but unless the performance difference for update and
status is an order of magnitude, it is not going to help us much. We
are planning to upgrade in the next few weeks though and I will repost
my performance results at that time.)
Repository Server Information
-----------------------------------------------------------------------
Intel Pentium 4 3.0 GHz
1 GB RAM
80 GB ATA disk, UDMA 100
Fedora Core 3
FSFS back end on Ext3, 37 GB of 72 GB used
Subversion-1.1.4
Client Information
-----------------------------------------------------------------------
Intel Pentium 4 2.4 Ghz
1 GB RAM
115 GB ATA disk
Windows XP service pack 2
NTFS, 53 GB of 115 GB used
Subversion client version 1.1.3 (r12730) compiled Jan 20 2005, 05:51:34
Repository Sizes and Status/Update times
-----------------------------------------------------------------------
Total size of trunk on client (including .svn dirs):
3.35 GB
13,598 directories
81,168 files
Update time from root of trunk on client: (svn update)
First time: 58 seconds (5 small files updated, dir data not in FS
cache)
Second time: 10 seconds (no files updated, dir data in FS cache)
Third time: 11 seconds
Status time from root of trunk on client: (svn status)
First time: 23 seconds
Second time: 17 seconds
Third time: 19 seconds
I think that the filesystem cache (NTFS) is helping a lot on subsequent
updates and statuses, which indicates that we are hitting the drive a
lot. Actually, now that I'm looking at the times, it's looking better
than I had figured, but it's still going to be more difficult to sell
this to the rest of the company if they are having to wait for a minute
or more (since we'll be adding all of their stuff to the repository too)
for an update.
Thanks guys! Subversion is the best thing out there.
Robert
> -----Original Message-----
> From: Bob Proulx [mailto:bob@proulx.com]
> Sent: Sunday, August 21, 2005 9:22 PM
> To: Robert Cronk
> Cc: users@subversion.tigris.org
> Subject: Re: Subversion working copy speed
>
> Robert Cronk wrote:
> > Bob,
> >
> > Thanks for the speedy reply. We use Linux (ext3) and windows (NTFS)
on
> the
> > clients and Linux (ext3) on the server where the repository is
> > stored.
>
> I have heard reports that NTFS is slower than ext3. But on my linux
> filesystems (mostly reiserfs) I do not see anything that I would count
> as a speed problem. A large-ish working copy (several hundred
> megabytes) I can 'svn status' in less than 5 seconds. That same
> working copy on HP-UX takes over two minutes. That prompted my reply
> about filesystem speed.
>
> > It would be nice if there was an index or something that could help
> > it be faster on the client side. Our repository is in the
> > Multi-Gigabyte range. We actually store our build tools in it too
> > so that our builds are completely self contained. This is part of
> > the reason for the large repository size.
>
> Uhm... I think what you just told me is that you check in the
> binaries for your build tools too. That is pretty extreme. I would
> just check in the source for the build tools.
>
> > It all works beautifully except for the speed. Sure, a faster hard
> drive
> > and filesystem would help, but an index (or something) would be nice
too
> > and would benefit all platforms. I do like that there is a local
> pristine
> > copy - especially when I'm working remotely from a 57.6 Kbps
connection!
>
> Exactly what operations are you referring to when you say fast or
> slow? I probably jumped to conclusions with my statement about
> filesystem speed because of personal experience. Because to me I
> expect 'svn status' to be very fast. Along with all of the other
> local operations such as 'svn diff' and things like that. Remote
> operations will be limited by your connection and server speed.
>
> But if you are checking out a multi-gigabyte working copy over a 57.6
> kbps connection I think you have just answered for yourself already
> why your operations are going to be very slow. Checking out a one
> gigabyte working copy at 57.6kbps would take five hours just to copy
> the data across the connection!
>
> Can you report the times for some typical operations?
>
> time svn status
> time svn diff
> time svn update
> time svn update # time when the wc is already up to date
>
> Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 22 18:50:14 2005