Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be> wrote on 05/27/2009
10:52:35 AM:
> > > If it's really a checkout, I think it's normal that you don't see an
> > > improvement (especially if it's with a windows client). In my
> > > experience, a checkout (or update) on Windows is mainly client-side
> > > cpu-bound (also heavy on IO, but mainly constrained by cpu). Could
> > > you verify this?
> >
> > The Windows client was a high end workstation (4 cores, 4G ram, 80+M
> > sustained I/O capability, Windows XP.) CPU and I/O were monitored
> > on the client and nowhere near max during most of the test.
>
> By maxed on cpu I mean just one core of course. On my pc (Windows
> XP, 2.8Ghz Pentium D (2 cores? or hyperthreading or something like
> that), 2G ram), the svn client (both TortoiseSVN and svn CLI client
> from SlikSVN) took one core, i.e. 50% cpu. This actually happened in
> bursts, every once in a while it would get a breather (during which
> one of the server cpus was maxed out (one httpd child)). Most of the
> time it was the client side that was maxed out though.
Yes, I was monitoring CPU usage per core (on both the client and server).
I have found the client CPU usage varies significantly based upon
the number of files in the working copy.
One big question I had, why does memcached only show 70% cache
hits when reperforming the same operation? That sounds like it
is checking the cache for some data, but not updating the cache
with the resulting data... The cache was not full - 600M/2G.
I'd also like to get it to "fail" gracefully if no memcached
servers are available.
I haven't dug into the code yet, but I was hopeful one of
the original developers of the memcached functionality would
know more.
I do believe the memcached performance would be a big win if
the repo was stored on a slow storage area. I haven't been
able to test this. (I'm complaining about storage that is
too fast. What is the world coming to... :)
Kevin R.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2355822
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-27 18:26:43 CEST