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. I'm also a little curious about serf using more CPU, as our testing a few years ago showing serf to be faster and with less CPU. Mebbe something changed since then :-/ Cheers, -g
