I took this testing a little further last night, this time repeating both my
svnsync and merge tests (same data, same methods) using a VPN connection
between my home (in NC, USA) and CollabNet HQ (in CA, USA), but with the
target server living in Chennai, India. I've attached the data from all
test runs to date.
I saw similar percentage-based improvements with NC>CA>India as I saw with
just NC>CA. Overall, it's clear that ra_serf offers performance
improvements over ra_neon. But I guess that's no surprise to folks.
Notable was that a series of neon-based merge operations which showed some
decent improvement in the NC>CA case show almost no improvement in the
NC>CA>India case. I guess whatever savings were found in fewer network
requests just became noise in the overall cost of the operation over such a
slow link or something.
Unfortunately, the NC>CA>India figures seem to confirm that one case of
performance degradation seen earlier might not have been a testing anomaly
after all: HTTPv2 actually does slow down svnsync over ra_serf from a
remote server to a local (file:///) repository. I'll need to dig into that
some to figure out why.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-05-11 16:16:43 CEST