Thanks.
strace seems to indicate I/O issues as the bottleneck. The file is
loaded from NFS without caching.
The per-repository access file seems like my best bet for an immediate
solution. It is example 4 in this config:
http://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_authz_svn/INSTALL
For a longer term solution, I am looking at contributing some code to
mod_authz_svn to 1. allow rule caching, or 2. provide some sort of db
support.
Joel Eidsath
On Thu, Mar 22, 2012 at 1:11 PM, Andy Levy <andy.levy_at_gmail.com> wrote:
> On Thu, Mar 22, 2012 at 15:24, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>>> Joel Eidsath wrote on Thu, Mar 22, 2012 at 09:11:48 -0700:
>>> > I was just handed a large SVN install with thousands of users and
>>> > hundreds of individual repositories. It is experiencing serious
>>> > performance issues. I believe that it mostly boils down to a 14MB
>>> > AuthzSVNAccessFile.
>>> >
>>> > What can I do to speed this up? Is there a database solution to use
>>> > instead of the flatfile? Can I implement caching somehow? I am willing
>>> > to code something up if I have to.
>>> >
>>> > Thanks for any help! Please CC me on any replies.
>>> >
>>> The relevant code is in libsvn_repos/authz.c. Look at the call to
>>> svn_repos_authz_read() in mod_authz_svn.c: the file is read and parsed once
>>> per connection.
>>>
>>> I guess you could cache the parsed svn_authz_t struct in a longer-lived pool, or
>>> perhaps increase the lifetime of connections (compare the configuration
>>> suggestions in http://subversion.apache.org/docs/release-notes/1.7#serf).
>>>
>>> The impact of this will be, of course, that changes to the authz config file might
>>> not take effect as soon as they do now.
>>>
>>
>> Cruise control .Net caches it's config info... however if uses a file watcher to see if the file changes... and if so reparses it. Could svn take this approach.
>
> Wouldn't that depend on where the bottleneck is? If the issues is file
> I/O, this could help. If the issue is the time it takes to check every
> rule, the improvement may not be significant.
Received on 2012-03-22 21:50:37 CET