On Thu, Mar 10, 2011 at 23:02, Greg Stein <gst...@gmail.com> wrote: > On Thu, Mar 10, 2011 at 11:50, Ivan Zhakov <i...@visualsvn.com> wrote: >> On Thu, Mar 10, 2011 at 19:42, Justin Erenkrantz >> <justin.erenkra...@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
