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

Re: Subversion trunk (r1078338) HTTP(/WC?) performance problems?

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Thu, 10 Mar 2011 23:26:23 +0300

On Thu, Mar 10, 2011 at 23:02, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Mar 10, 2011 at 11:50, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On Thu, Mar 10, 2011 at 19:42, Justin Erenkrantz <justin.erenkrantz_at_gmail.com> wrote:
>>> Heh, while we've got you testing stuff...what happens if the server is
>>> on a different physical machine?  Are your results in line with
>>> Philip's which says that ra_serf and ra_neon are within margin of
>>> error (if serf is not indeed faster)?  Are the timings still off by
>>> that much?  Because it's async, I expect serf has substantially
>>> different performance characteristics when it is going over localhost
>>> (no network) versus using the actual network stack...  -- justin
>> Unfortunately ra_serf will be worse than ra_neon, because it uses
>> skelta style update editor with many GET/PROPFIND requests. While
>> ra_neon just uses one REPORT request with large response. I have task
>> in my todo list to implement non-skelta (send-all) mode update editor
>> in ra_serf to make performance comparable.
> That was an explicit design choice. ra_serf should not be using the
> REPORT style of query. Those GETs are cachable by local proxy caches,
> reducing the need to (re)fetch the content over a WAN. The big REPORT
> response is never cachable.
As Mark pointed there is known implementation of such proxy. And it's
hard to implement for corporate environment due SSL and

Anyway we have option for mod_dav_svn to ignore send-all flag and
always use skelta mode.

Ivan Zhakov
Received on 2011-03-10 21:27:10 CET

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.