On 9/26/13 12:45 PM, Mark Moe wrote:
> We found that about half the performance issue was solved by using
> "SVNPathAuthz off" while the other half was solved by skipping that
> big revision when doing svn log -v. Just the sheer transfer of all
> those lines of text was a big hit even with SVNPathAuthz off.
First of all I would like to note that I wouldn't recommend anyone having
performance problems with log and commits that changed a lot of paths
implementing SVNPathAuthz off without putting some serious thought into this.
This option disables checking secondary paths for access when processing
requests that touch multiple paths. Secondary paths meaning paths that are not
in the request URI. There are many cases in which a Subversion client receives
information about paths other than the path in the request URI. Log reports
happen to be one but so are update reports.
Update reports are much worse as they can also reveal the contents of files
that are secondary paths. This can be mitigated by using SVNAllowBulkUpdates
Off, which causes the file contents to be separately requested via GET requests.
I would encourage anyone having such a problem to try SVNPathAuthz
short_circuit first, which should help mitigate some of the cost of handling
authz for these secondary paths. However, this does bypass some of the Apache
httpd authz handling. Very few users actually depend on this extra work from
the Apache httpd side, but you should read the documentation and make sure you
understand what implications this has for your configuration.
If that doesn't help use SVNPathAuthz off should be considered even more
carefully. This is not a widely used configuration and not one that gets
tested much by developers. So before deploying it I'd encourage a careful
testing that you're not leaking information that you don't want to. I'd also
encourage a re-testing of the behavior with future upgrades of Subversion.
> The performance solution for us (with help from WANdisco) was to null
> out that big revision using a dump/filter/load cycle on the repo. The
> big change was *only* svn:mime-type property settings and no actual
> file content change. The dump/filter/load cycle worked great (with
> --force-uuid) and I even did that on 2 other smaller but still big
> svn:mime-type only revisions as well. Going forward we have a
> pre-commit check to block big changes like this without a special
> comment message know to admins.
Be careful doing this, if you remove revisions that have file content changes,
add or delete files you're invalidating the working copies of users.
Also beware that if you replace a repository you need to restart the server in
order to invalidate caches since at current the server believes that the
content it has already cached is the same as long as the UUID doesn't change.
> Although not as critical to us now, we still think svn log
> --ignore-properties would be useful to (a) help narrow down svn log
> output to content changes only and (b) be consistent with svn diff
> --ignore-properties (which is where we got the idea of wanting it with
> svn log).
I agree for a UI perspective there is reason enough to implement this feature,
but let's not confuse the performance issues since it can't help with those.
Received on 2013-09-27 00:41:14 CEST