On Wed, Feb 17, 2016 at 05:33:21PM +0300, Ivan Zhakov wrote: > As we are adding more and more of such code, more and more users > become faced with the significant performance regression (see [1] and > other cases). > > Do you intend to resolve this problem in the future commits? I have > some obvious solutions in mind, but maybe you also know something > about this. > > [1] http://svn.haxx.se/users/archive-2015-12/0060.shtml
As I understand it, that's a misconfigured server, not a bug, at least in terms of where our configuration guidelines stand right now. And as I mentioned in that thread, I'd prefer if we could fail more gracefully in such situations. But I also advocated for a small default cache size to keep svn working in low-memory environments by default. Just growing the cache by default is not really an option I'd like. But perhaps we should reconsider raising the default size to something like 1GB in the next patch release, and have the server fail to start up in low-memory environments rather than failing during normal operation in standard servers. In the long term, could we try to make the cache tune itself at runtime instead of forcing users to specify a size in config files or command line? Is this really a setting we want users to have to worry about? We've always been trying to avoid configuration knobs, and cache size is a big warty knob people have to tune on virtually every SVN server instance out there. If we could automate this somehow I believe we would see a lot of benefits.
