Re: [viewvc-dev] viewvc repository listing very slow

------=_Part_15547_1674657360.1445611643554
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 23 Oct 2015, C. Michael Pilato wrote:

> Thanks for the well-written and detailed email. I can certainly=20
> understand your situation and why a repeated parsing of the svn authz=20
> file would be troublesome.=C2=A0 It never occurred to me that of all the=
=20
> places to find a performance bottleneck, group parsing would be an issue=
=20
> for anyone.
>=20
> The complicated part of this is, as you already noted, persistence --=20
> too little hurts performance, while too much hurts agility.
>=20
> Using a global variable as you did solves your re-parsing problem, and=20
> would probably work out okay for ViewVC when hosted as a CGI application=
=20
> and where all the Subversion repositories use the same authz file.
>=20
> Unfortunately, for a mod_python- or mod_wsgi-based instance, this=20
> creates a circumstance where the Apache web server has to be restarted=20
> in order to enact a change to the authz file. Subversion itself deems=20
> this an unacceptable scenario, and so re-parses the authz file at least=
=20
> as often as with each new Subversion-related network connection made to=
=20
> the Apache server.

The code as it looks now even with my changes is still reading the authz=20
file on each invocation of the script. By also remembering an md5sum of=20
the authz file one could properly react and reparse the changed group=20
information. This would also solve the problem of using several distinct=20
authz files as for each new file the cached information would be thrown=20
away.

When it comes to parsing the access rules for different users you would=20
get of course different results (roots to display) for different users.

That is why I inserted the calling user in the global groups array. The=20
idea was to reevaluate the list of roots only if the user changes. If I do=
=20
see that correctly this should also work for mod_python- or mod_wsgi-based=
=20
installations.

> Additionally, ViewVC supports repos-relative authz paths (just as=20
> Subversion itself does).=C2=A0 In such configurations, there are many aut=
hz=20
> files (most commonly, one per repos) and so you have to be sure that=20
> your cache doesn't bleed data where it shouldn't.=C2=A0 One authz file's=
=20
> group definitions shouldn't be applied to a different authz file.

I do know and was even considering it. As the authz file is generated from=
=20
a database, generating one file was at least the quicker solution. And up=
=20
to now viewvc was the only bottleneck. As users had the choice to either=20
use a direct link to their repo with viewvc or to use websvn ther was not=
=20
much of a complaint yet.

> In answer to your question, though: yes, I am absolutely interested in=20
> making ViewVC perform as well and as quickly as possible, and open to=20
> all ideas as to how to do this without compromising data integrity,=20
> ideally without making its already-obnoxious configuration file even=20
> larger. If you (or anyone else) has some bright ideas as to how to make=
=20
> this happen, please do share them!

Instead of using a global variable I was also considering attaching the=20
cached information to the self object, but I did not know whether a) that=
=20
worked and b) it would be a tolerable solution. If you think that both=20
taking care of a changed authz file and putting the cached information=20
elsewhere is worth trying I could try coming up with some better snippet=20
of code. What do you think?

--=20
Best regards
Wolfgang

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=3D4251&dsMessageId=3D3=
143635

To unsubscribe from this discussion, e-mail: [[email protected]=
.org].
------=_Part_15547_1674657360.1445611643554--