On Tue, Dec 22, 2009 at 12:58 AM, Paul Querna <p...@querna.org> wrote: > What I found interesting is that for several tests, a significant > portion of my 'real time' of a checkout or update was spent in > svn_ra_serf__exchange_capabilities, detecting what features of the > server were available. > > I used libcloud trunk as an example project, it is quite small > compared to most projects making it easy to test, and using the ASF > eu/us mirrors let me easily see the effect of network latency, for two > servers configured essentially identically. > > us mirror URL was: > https://svn.us.apache.org/repos/asf/incubator/libcloud/trunk/ > eu mirror URL was > https://svn.eu.apache.org/repos/asf/incubator/libcloud/trunk/ > > us mirror, checkout: 5.4% spent in exchange_capabilities > us mirror, update: 35.1% spent in exchange_capabilities > > eu mirror, checkout: 11.7% spent in exchange_capabilities > eu mirror, update: 55.2% spent in exchange_capabilities > > Latency to US mirror: ~95ms average > Latency to EU mirror: ~225ms average.
Well, isn't it because there are only like 2 or 3 HTTP requests going on when you do an update and you are already up-to-date? So, it'd make sense that the first HTTP request might take a disproportionate amount of time then (due to TCP setup, etc, etc.)? IOW, how many HTTP requests are there and is OPTIONS taking noticeably longer than the rest of them? -- justin
