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

Re: 1.7 Performance via HTTP

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Thu, 12 May 2011 11:16:22 +0400

On Thu, May 12, 2011 at 10:12, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:
> On Wed, May 11, 2011 at 4:40 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> The story using Serf is not as good.  There are a few places where it
>> is fastest, namely merge.  But there are other cases where it is
>> dramatically slower.  The number of HTTP requests with Serf is 80,990.
>>  Looking at the numbers, it seems like Serf is slowest when it comes
>> to the areas where it issues all those GET requests, such as checkout
>> and update.  On other operations it is more inline with Neon.  Maybe
>
> r1102173 will help slightly when there are lots of checkouts as
> ra_serf wasn't asking for the REPORT response to be compressed - doing
> that saves a fair bit of traffic before the parallelization can begin.
>  (86k down to 16k for a checkout of notes/.)
>
> I'm also assuming you've appropriately configured your httpd server...see:
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201101.mbox/%3CAANLkTi=AN-2BZgjSioowmEFgqFt5L=wyW9yzfFayO6Xy@mail.gmail.com%3E
>
Unfortunately huge memory leak in mod_deflate/mod_dav prevents
enabling gzip on compression on production servers, especially on
Windows where single process mode is used:
http://svn.haxx.se/dev/archive-2009-08/0274.shtml

-- 
Ivan Zhakov
Received on 2011-05-12 09:17:45 CEST

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.