On Fri, May 4, 2012 at 6:39 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>
>> On Wed, May 2, 2012 at 6:25 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> [...]
>>
>>> [2] On a Solaris build machine @work (Solaris 10 on x86 on ESX, with
>>> 1.6.17 client, 1.5.4 server (sorry, old stuff)), most interactions
>>> with the svn server are a lot faster when using serf than with neon.
>>> Things like ls, cat, log, mergeinfo, ... are all a lot faster (like
>>> 150ms vs. 900ms).
>> That's true: ra_serf is significantly faster when working with pre-1.7
>> servers because it have DAV baseline cache (see r1080245 and
>> subversion/libsvn_ra_serf/blncache.c). It dramatically reduce number
>> of PROPFIND requests when working with pre-1.7 servers. But it's not
>> used when server is HTTPv2 capable. That's why I didn't ported this
>> cache to ra_neon, while it's should be easily possible.
>
> I'm confused. You say serf/v1 is faster because of the baseline cache,
> and that the cache is not used by serf/v2. Does that mean serf/v1 is
> faster than neon/v1 or that serf/v1 is faster than serf/v2?
>
Yes, serf/v1 is faster than neon/v1 for some operations like svn merge
on svn ls, but it most likely slower for update/export.
> I hope you mean that serf/v1 is faster than neon/v1 and that serf/v2 is
> also fast because the v2 protocol means the cache is unneeded. How does
> serf/v2 compare to neon/v2?
>
serf/v2 and neon/v2 doesn't send propfind requests: they construct
baseline URL locally.
--
Ivan Zhakov
Received on 2012-05-04 16:58:53 CEST