[viewvc-dev] viewvc repository listing very slow
Wolfgang Friebel <[email protected]> Fri, 23 Oct 2015 01:59:36 -0700 (PDT)
| Newsgroups | gmane.comp.version-control.cvs.viewcvs.devel |
|---|---|
| Message-ID | <332586807.14768.1445590776694.JavaMail.httpd@localhost> |
We do have an svn server with about 400 repositories and a single authz access file containing about 600 group definitions. The file itself has about 8000 lines.
When doing a repo listing the '_get_paths_for_root' method in viewvc/lib/vcauth/svnauthz/__init__.py is called for each repo. One call takes in our environment about 0.8 seconds. A user would have to wait therefore for the repo listing about 5 minutes if he is lucky, if not, the connection would time out.
It would be very beneficial to reorganize the svnauthz plugin and parse the file only once keeping the parsed results in memory. As a quick and dirty hack and proof of concept I did cache the parsed group definitions (for version 1.1.24):
--- __init__.py.orig 2015-10-22 20:42:19.457665386 +0200
+++ __init__.py 2015-10-22 20:54:15.259056248 +0200
@@ -78,8 +78,12 @@
aliases.append(alias)
# Figure out which groups USERNAME has a part of.
- groups = []
- if cp.has_section('groups'):
+ global groups
+ myuser = '__user__:' + (self.username or '')
+ if not globals().has_key('groups') or groups[0] != myuser:
+ groups = [None]
+ if cp.has_section('groups') and groups[0] != myuser:
+ groups = [myuser]
all_groups = []
def _process_group(groupname):
That brought the time already down from about 5 minutes to 20 seconds.
Of course using a 'global' definition and storing the username in the first element of groups is bad, but that was the quickest solution for me.
Instead of repeatedly calling the function for all repository roots it would also be much more efficient to call it only once for all repo roots.
Could something like that be foreseen in some future version of viewvc?
------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=3143575
To unsubscribe from this discussion, e-mail: [[email protected]].