On Tue, Jul 15, 2014 at 4:09 AM, Justin Erenkrantz <jus...@erenkrantz.com> wrote: > On Mon, Jul 14, 2014 at 9:09 AM, Stefan Fuhrmann > <stefan.fuhrm...@wandisco.com> wrote: >> On the same machine actually (which may be a contributing factor). >> The client is svn-bench that simply handles the editor drive but >> discards incoming file contents etc. > > We've historically seen oddity in loopback scenarios on Windows - the > loopback network drivers on Windows have always seemed a bit shaky to > me. If/when you get a chance, it's worth seeing if you see it happen > with a remote box. -- justin
So, it turned out to be a problem in the Subversion libs and got fixed by r1611379. When multiple connections to the same repo were opened concurrently (ra_serf over loopback), our file API workarounds for Windows (retry for up to 10-ish seconds) would interact badly with the initialization serialization code we use for the "revprop caching" feature. As a result, the feature initialization would fail (hurts performance but is not a major problem) but it would also waste 10+ seconds until it gives up. This fully explains why runtimes would fluctuate between e.g. 21, 31 and 42 seconds. I'm currently running a few extra tests and will post the final results once they come in. -- Stefan^2.
