gmane.comp.version-control.subversion.trac.devel

Tim Hatch | 23 Apr 23:20

[Trac-dev] Improving next_rev for scoped svn paths

Hi all,

We've had a number of tickets related to either silly memory growth  
or slow performance on scoped svn repositories (in particular,  
#5213).  This is a big issue for everyone since the same code paths  
are taken for restricted changesets (which search engines will index,  
even if your users don't click on them).

I saw this happen for one big user of Trac and tracked down that the  
cached repository isn't using a cached representation of next_rev.   
I'd like review of the following patch, which improves the situation  
bigtime on my system.  In particular, I'm not aware of any backends  
using CachedRepository other than svn, which uses numeric revs  
(please correct me if wrong).

normal changeset: 0.25s
restricted changeset: 12s
restricted w/ cached next_rev: 0.6s

Tim

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Attachment (next_rev.diff): application/octet-stream, 1633 bytes

(Continue reading)

headers

Christian Boos | 24 Apr 13:28

[Trac-dev] Re: Improving next_rev for scoped svn paths

Hi Tim,

Tim Hatch wrote:
> Hi all,
>
> We've had a number of tickets related to either silly memory growth  
> or slow performance on scoped svn repositories (in particular,  
> #5213).  This is a big issue for everyone since the same code paths  
> are taken for restricted changesets (which search engines will index,  
> even if your users don't click on them).
>
> I saw this happen for one big user of Trac and tracked down that the  
> cached repository isn't using a cached representation of next_rev.   
>   

Was he using a recent enough 0.11dev? In particular, was this happening 
despite of r6594?

> I'd like review of the following patch, which improves the situation  
> bigtime on my system.  In particular, I'm not aware of any backends  
> using CachedRepository other than svn, which uses numeric revs  
> (please correct me if wrong).
>   

In case this is a problem, we could add a "linear_changesets" property 
to the CachedRepository: If set to True, this would take the fast path. 
I've updated the patch along these lines (and it seems to work quite 
well, please test also on your side).
Next step would be to do that for prev_rev as well.

(Continue reading)

headers

Tim Hatch | 24 Apr 14:49

[Trac-dev] Re: Improving next_rev for scoped svn paths


> Was he using a recent enough 0.11dev? In particular, was this happening
> despite of r6594?

Yes, even on trunk.  The memory usage remains "reasonable",  it just takes
a long time to read the revs from the disk (especially over nfs).  The
timings I gave were for a local reposory, requesting ~r7000 out of 13000
total, where no further change exists at that path.  Here's an example on
t.e.o.:

http://trac.edgewall.org/changeset/2826 -> averages 2s
http://trac.edgewall.org/changeset/2826/sandbox/trac-xref -> averages 18s

Tim

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---