On Mon, Apr 14, 2014 at 6:17 PM, Ivan Zhakov <i...@visualsvn.com> wrote:
> On 12 April 2014 00:01, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> > wrote: > > It seems that the document in notes/ did not make it clear what > > the actual problem is and how it applies to Subversion servers. > > Let me try to illustrate it. > > > [...] > > > > > Should these trends be confirmed for "real" HW, networks and ra_serf, > > I'd love to see this code in 1.9 - after due review and feedback. > > > > Hi Stefan, > > I got the idea from original description, but thank you for explaining > it one more time. Anyway my concerns are still valid and I am -1 on > implementing this at FSFS layer. Especially if we're going to release > Subversion 1.9 in 2014. > Having taken more measurements and analysis on my server hardware last weekend, it seams that mod_dav_svn requires a refined throttling scheme. So, unless 1.9 gets massively delayed, I now schedule the thunder branch merger for 1.10. > I'm also skeptical on FSFS full texts caching. I think that caching > worth only for small metadata, that doesn't consume a lot of memory > but expensive to build. But that's different story. > [Only to give you a data point:] Well, it can be disabled and it can even be moved out to memcached (and is the only the item type where a network indirection is acceptable). However, constructing fulltexts from data that is not in disc cache can be very expensive: we read 10-ish concurrent data streams and then do quite a bit of unzipping and checksumming on the data. Apache is already needs 8 CPU cores to saturate a single 10Gb network connection (uncompressed, non- encrypted source code) *with* 100% fulltext cache hits. Adding more CPU load can be a problem. -- Stefan^2.
