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.
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
Received on 2011-03-10 21:03:13 CET