[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn log --ignore-properties option

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 26 Sep 2013 11:34:06 +0200

On Thu, Sep 26, 2013 at 09:59:54AM +0100, Patrick Sawyer wrote:
> I believe this improvement request stems from the fact that Medtronic (the
> customer) did a massive commit (to a very large change-set) setting the
> properties of ~300k files.
>
> This has caused significant performance issues especially with svn log.
> There reasoning was if they could ignore properties this would help combat
> these performance issues.
>
> Does this make sense?

This sounds as if the performance issue was on the server side.

The client requests a list of changed paths if 'svn log' is run
with the --verbose option (some GUI clients do this by default).
Adding an option to the client that filters out some data before
displaying it won't help at all because the server will still perform
work to obtain and send the changed paths list anyway.

The real fix for this issue would be scalability improvements on the server.
That implies finding the actual bottleneck. If they have authz enabled
and the bottleneck is checking authz rules against 300k paths, then
there is not much we can do about this because every path needs to
be matched to enforce access rules. Some performance penalty is expected
and documented in this case.
See http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
("in certain situations, there's very noticeable performance loss")
They can measure the authz performance penalty buy temporarily disabling
authz and running the log request without it.

I know of a case where someone imported close to a million paths in
revision 1, and when they run 'svn log -v' against the authz-enabled
server it takes forever to gather log information for revision 1.
All other revisions which changed much fewer paths are fine, and
the problem is mitigated if authz is disabled.

Perhaps your customers are running into another bottle neck, but I think
that's unlikely. But in this case tuning server-side caching (with
Subversion 1.7 and up on the server) might mitigate the issue somewhat.
Received on 2013-09-26 11:35:40 CEST

This is an archived mail posted to the Subversion Dev mailing list.