Hi d...@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
