On Fri, May 4, 2012 at 6:39 PM, Philip Martin <philip.mar...@wandisco.com> wrote: > Ivan Zhakov <i...@visualsvn.com> writes: > >> On Wed, May 2, 2012 at 6:25 PM, Johan Corveleyn <jcor...@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
