[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
authentication.

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.