On Fri, 2011-07-08 at 03:58 +0300, Daniel Shahaf wrote:
> Tony Butt wrote on Fri, Jul 08, 2011 at 10:41:43 +1000:
> > On Fri, 2011-07-08 at 02:59 +0300, Daniel Shahaf wrote:
> > > This doesn't address memcached directly, but there has been a /lot/ of
> > > work on server-side optimization and caching in 1.7 (also for
> > > non-memcached-backed caches).
> > >
> > > http://subversion.apache.org/docs/release-notes/1.7#server-performance-tuning
> > >
> > > You might want to take 1.7.0-alpha3 for a spin...
> > >
> > Probably don't want to do that.
> > We are in a commercial environment, with some 20 developers relying on
> > subversion - not the time for an alpha release.
> >
>
> I wasn't suggesting that you upgrade your production server!
I didn't really think you would be :-)
>
> Just that you install the alpha in a test environment to see if it
> improves the situation for you. (or if there is anything you see that
> requires modification /before/ the release --- before compatibility
> promises apply --- as in eg issue #3952)
>
My available test server also syncs the production repository to itself
as a hot spare. I am probably brave enough to install 1.7.0-alpha3 on
that, so long as there are no issues syncing from 1.6.17 to 1.7.0
I was starting to think that apache 2.2 + subversion 1.6.17 probably did
as much caching as was necessary for good performance, and that adding
in memcache to serve what is almost static data was really adding an
overhead.
Anyway...
Not really complaing about the performance of apache + subversion, just
surprised at the effect of apache + subversion + memcached, and
wondering if anyone else had any positive or negative experiences.
Thanks,
Tony
> > We are actually happy with the current performance, particularly since
> > the load of other tasks on the server (backups, opengrok indexing of the
> > repo for instance) is now shared by 4 processors instead of 1. I was
> > reviewing the overall configuration, and we already use memcached to
> > support ReviewBoard for code reviews.
> >
> > We will be particularly interested in server side performance
> > improvements when 1.7.0 is released - we have home grown build
> > dependency tools that are sometimes heavy on the repository usage -
> > these will be difficult to upgrade to 1.7.0, but if there are uncoupled
> > server performance improvements, the server upgrade is trivial by
> > comparison.
> >
> > Thanks,
> > Tony Butt
> > > Tony Butt wrote on Wed, Jul 06, 2011 at 15:20:27 +1000:
> > > > We are running subversion 1.6.17 on a vmware hosted server. We recently
> > > > reconfigured the server to give 4 virtual CPUs (up from 1), and a
> > > > significant amount of memory.
> > > >
> > > >
> > > > In order to spruce up our performance a little, I looked into the use of
> > > > memcached with subversion again, found the correct config parameter, and
> > > > set it up. Our server is running Ubuntu 10.04, Apache 2.2. Access
> > > > mechanism is http (of course). The client used is running Ubuntu 11.04,
> > > > and svn commandline (1.6.17 also)
> > > >
> > > > The results were interesting, to say the least.
> > > >
> > > > Checkout of a tree, about 250M in size:
> > > >
> > > > Without memcached, 1 1/2 to 2 minutes, varies with server load
> > > > With memcached, 12 minutes (!)
> > > >
> > > > Update of the same tree,
> > > > Without memcached, 9 seconds
> > > > With memcached, 14 seconds - repeated several times, similar results.
> > > >
> > > > I am not sure what anyone else's experience is, but we will not be
> > > > enabling memcached for subversion any time soon.
> > > > --
> > > > Tony Butt <tjb_at_cea.com.au>
> > > > CEA Technologies
> > > >
> >
> > --
> > Tony Butt <tjb_at_cea.com.au>
> > CEA Technologies
--
Tony Butt <tjb_at_cea.com.au>
CEA Technologies
Received on 2011-07-08 06:15:25 CEST