On Tue, Dec 22, 2009 at 12:58 AM, Paul Querna <paul_at_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
Received on 2009-12-22 17:53:37 CET