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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
httpv2-testing.xls
Description: MS-Excel spreadsheet
signature.asc
Description: OpenPGP digital signature
