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.
Received on 2016-02-17 22:32:07 CET