[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Drastic performance difference with subversion client on Solaris

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-03-19 05:55:17 CET

--On Thursday, March 18, 2004 5:00 PM -0600 Ron Bieber <ron@bieberlabs.com>
wrote:

> here are the timings for cvs2svn checkout:
>
> Checked out revision 838.
>
> real 2m7.190s
> user 0m1.590s
> sys 0m3.360s

At this point, you need to give detailed description of your environment
because your results aren't close to anything else.

What OS patches do you have applied - you do have all of the recommended
Solaris patches applied, right? Are you sure you aren't network-bound - could
you have full/half-duplex problems?

What box did you do compilation on: your Solaris 2.6 box? What happens if you
compile SVN on your Solaris 9 box? While the binaries won't be backwards
compatible, APR does gets to take advantage of some features if it is compiled
on newer Solaris versions.

If you are current wrt patches and your network isn't the bottleneck and
changing where it is compiled, then let's go a level deeper: what speed is
your processor? What compiler: version, optimizations, etc? Kernel revision,
file system mount options, local/networked drives, etc, etc.

On an old Ultra-5 on Solaris 8, I get:

Checkout to NFS'd home dir:
svn co http://svn.collab.net/repos/cvs2svn/trunk cvs2svn 2.53s user 4.77s
system 18% cpu 38.998 total

Checkout to local /tmp:
svn co http://svn.collab.net/repos/cvs2svn/trunk cvs2svn 2.37s user 0.97s
system 22% cpu 14.872 total

% uname -a
SunOS ... 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-5_10
% psrinfo -v
Status of processor 0 as of: 03/18/04 20:35:15
  Processor has been on-line since 02/23/04 08:03:35.
  The sparcv9 processor operates at 400 MHz,
        and has a sparcv9 floating point processor.
% prtconf | grep Memory
Memory size: 128 Megabytes
% cc -V
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
(I use debugging builds with no optimizations.)
% ping -s svn.collab.net
PING svn.collab.net: 56 data bytes
64 bytes from morbius.ch.collab.net (216.127.237.133): icmp_seq=0. time=69. ms
64 bytes from morbius.ch.collab.net (216.127.237.133): icmp_seq=1. time=121. ms
64 bytes from morbius.ch.collab.net (216.127.237.133): icmp_seq=2. time=71. ms
64 bytes from morbius.ch.collab.net (216.127.237.133): icmp_seq=3. time=70. ms
64 bytes from morbius.ch.collab.net (216.127.237.133): icmp_seq=4. time=69. ms
64 bytes from morbius.ch.collab.net (216.127.237.133): icmp_seq=5. time=67. ms

This box is not idle as it has some nice'd jobs running. So, I'd expect this
to be about the worse case performance-wise *if* the network isn't your
bottleneck as these boxes are on a pretty fat pipe. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 19 05:55:28 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.