[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Workaround for slow RepositoryBrowser on large repositories

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Sat, 12 Jan 2013 18:18:04 +0100

On 11.01.2013 22:03, Schnyder Franz wrote:
> We use the TortoiseSVN (1.7.11) with various internal repositories
> (Subversion 1.6.16) and the Repository Browser is very slow, more
> than 2 minutes to show the initial screen, on larger repositories. I
> already disabled the RepoBrowserPrefetch and the
> RepoBrowserShowExternals flags but this did not show the hoped for
> performance improvement. We also see that a Repository Browser
> generates quite a CPU load on the server.
>
> I found the fixed Issue 180 "Optimize repo browser for big
> repositories" and saw that the “incomplete” fetch is only used when
> fetching the URLs up to the root and not for the rest. So I got the
> TortoiseSVN code of the 1.7.11 tag and changed the Repository Browser
> so it always uses the incomplete fetch for all SVN::List
> (dirent_fields=0x0) calls. But again the performance did not improve
> much.
>
> In a next attempt I changed the fetch_locks parameter inside
> SVN::List to always be false. I now the repository browser starts in
> a 1 to 2 seconds! I reverted the change to use the incomplete fetch
> for all SVN::List calls and it still starts within 2 seconds. The
> only thing I loose is the info in the Lock column.
>
> So it looks like the fetch_locks causes the performance problem. I’m
> not sure where root cause of the problem lies (Subversion, Server,
> TortoiseSVN) but my change is a workaround for the problem.
>
> Has anyone ever discovered similar performance problems or heard/read
> from problems with the fetch_locks flag?

I've now tested with 5 different svn repositories and servers, some with
38'000 folders in its root. Fetching the locks took about half a second
for the biggest ones.

So I guess it is something on your server that's causing this slowdown.
For the repositories I tested, the part that uses up most of the fetch
time are the dirent fields - if all are fetched then it takes much much
longer than if those fields are not fetched.

> I will try to clean up my code changes and introduce an
> RepoBrowserFetchLocks flag so TortoiseSVN users with the same problem
> than I, then could disable the lock fetching.
>
> Is there interest in such a patch?

No need, I'll have that change done maybe today.

> And is there a chance to integrate it into the official TortoiseSVN
> version, because for us it would be nice to have this workaround in
> the official version, so we don’t have to manage our own TortoiseSVN
> version?

At least part of this could go even to the 1.7.x branch.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3042966
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-01-12 18:18:16 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.