Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be> wrote on 05/22/2009
10:31:03 AM:
> > Anyone do any performance analysis of using memcached? I'm not
> > seeing much (if any) benefit, but that could be due to a fairly
> > high performance SAN storage solution for storage.
> >
> > Here are my numbers:
> >
> > no cache: 10 min 33 sec
> > cold cache: 10 min 30 sec
> > hot cache: 10 min 26 sec
> > (The differences are statistically insignificant.)
> >
> > This is for a single repo with 600M of data in 30k files.
> >
> > Server cpu usage seemed consistent with and without
> > the cache. I (unfortunately) wasn't able to monitor disk I/O.
> >
> > I was using a 2G memcached, of which it used around 600M for the
> > cache. Oddly enough, monitoring memcached showed only a 70%
> > cache hit when repeatedly downloading the same repository.
> > (I would have expected a 100% hit ratio from the memcached side.)
> >
> > memcached was running on the same server as apache for the tests.
> > (A quad core 64-bit AMD server running solaris 10 x86. 4G of RAM
> > with storage on an enterprise SAN connected with fiber.)
> >
> > svn 1.6.2
> > httpd 2.2.11
> > apr 1.3.3
> > apr-util 1.3.4
> > neon 0.28.4
> > memcached 1.2.8
> >
> > Test repository was created and populated with svn 1.6.2.
> >
> > I also noticed if no memcached servers were running, but a repository
> > was configured to use it, a checkout would fail during the checkout
> > of the first directory. It probably should continue to work as
> > if no cache was configured instead of failing...
> >
> > Anyone else see some better results?
> >
>
> It's not really clear to me what you measured here, but deducing
> from your previous post, I'm guessing you timed a large checkout or
> something similar. What was your test setup (what kind of client,
> how did it access the repo (local/remote, svn(+ssh), http(s), file),
> ...)? And how did you measure it (e.g. running "time svn co ..." in
> a console, or via TortoiseSVN, or ...)?
Yes, it was a repeated clean checkout of 600M (30k files) over http.
The numbers are from TortoiseSVN, but verified the similar results on
RHEL4 (linux) and Solaris 10 x86. ("time svn co ..." on the unix
machines)
> 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.
> I don't know that much about SVN (client) internals, but I'm hoping
> this will be improved in 1.7 by the new WC-NG (see http:
> //subversion.tigris.org/issues/show_bug.cgi?id=3357). Another issue
> that might be related (and will probably go away with WC-NG) is
> http://subversion.tigris.org/issues/show_bug.cgi?id=3369.
>
> It would be interesting to know which svn actions are significantly
> improved by memcached (log, blame, ...). Any chance you could test
> this with your setup?
Sure, I can test almost anything, but I was hopeful someone would
have an idea what operations would have the most benefit.
Kevin R.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2355812
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-27 17:21:18 CEST