Hi dev_at_svn:
Greg sez I broke serf stuff, so today I found some time today to play
with Serf Trunk (and Subversion trunk!), yay for the holidays.....
I am using Instruments.app on osx to profile basic performance of SVN,
from my parent's sloooooowww DSL line in Spokane, WA. (1.5mb/s down,
768 up)
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.
Because the OPTIONS request made by svn_ra_serf__exchange_capabilities
essentially blocks all other operations until it completes, the larger
the network latency, the larger percentage it takes up of the whole
application runtime.
I think the solution is to cache the capabilities of a server for a
short time period, even just caching them for 24 hours would speed of
the day to day interactiveness of update/commit/update cycles.
I think one approach would be to add cache-control & expires headers
to mod_dav_svn responses, and while this approach is good in the HTTP
respects, it relies upon everyone upgrading their servers.
The other approach is to arbitrarily cache capabilities of a server
for 24 hours.
The downside of course is if someone upgraded to 1.7 on the server,
and then downgraded to 1.5 (or whatever), they potentially would break
some clients -- I think it would be best to have some kind of backoff
if an RA capability failed, the easiest way would be to just wipe the
cache if the server communication failed for any reason, and on the
next svn command, the cache would be repopulated. Would this be an
acceptable user experience?
In either case, you would need somewhere to store them, and that is
why I am writing the dev list: Where and how should a cache like this
live?
I looked quickly at how the auth cache works, and its pretty specific
to authentication, and not really a generic way to store data in
~/.subversion.
It seems like it might be nice to create an SQLite backed svn_cache__t
that lived in ~/.subversion, where ra_serf could store these kinds of
caches. (or more in the future)
Thoughts?
Thanks,
Paul
Received on 2009-12-22 09:59:14 CET