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

Re: Trouble With Show Log

From: Andy Levy <andy.levy_at_gmail.com>
Date: 2007-06-14 17:12:09 CEST

On 6/14/07, Troy Bull <troy.bull@uni.edu> wrote:
> Andy Levy wrote:
> > On 6/14/07, Troy Bull <troy.bull@uni.edu> wrote:
> >> Andy Levy wrote:
> >> > On 6/14/07, Troy Bull <troy.bull@uni.edu> wrote:
> >> >> Greetings:
> >> >>
> >> >> I posted yesterday about this but I have much more information today.
> >> >> First, I have a subversion repository I am responsible for, I
> >> recently
> >> >> switched over from CVS. My repository has 419 "projects" on the top
> >> >> level directory. In each of these project directories I have 3
> >> folders
> >> >> trunk, branches, and tags.
> >> >>
> >> >> I have an initial import of the head of my cvsnt repository which
> >> >> consisted of each project (419 of then) for a total of about 16k
> >> files,
> >> >> these are a mix of html, perl, images, and pdf's. My repository has
> >> >> been live about a week, I think we are about r 140 as I type
> >> this. My
> >> >> revision 1 adds almost all of the 16k files in one import.
> >> >>
> >> >> I use http as my access method, (mod_dav_svn), my problem is svn
> >> log -v
> >> >> http://machine.domain.com/svn/Access seems to take forever.
> >> >>
> >> >> Here are some numbers in the format command(time in seconds to
> >> complete)
> >> >>
> >> >> svn log -v http://source.its-is.uni.edu/svn/Access (104) - fs-type
> >> = bdb
> >> >> svn log -v http://source.its-is.uni.edu/svn/AccessFSFS (79) - fs-type
> >> >> = fsfs
> >> >> svn log -v file:///source/AccessFSFS(1) - fs-type=fsfs
> >> >>
> >> >> Is this what I should be expecting? Is there anything I can do to
> >> >> improve my access times for this operation? Many of my "clients" use
> >> >> TortoiseSVN on windows and it times out before the command completes.
> >> >> Any help would be greatly appreciated.
> >> >
> >> > My repository has 1490 revisions, not sure how many files but it's
> >> > fewer than yours (log operation speed should depend more on the # of
> >> > revisions, not the size of the repository I think) and it took me 15
> >> > seconds to get svn log -v on the root of the repository via HTTP. FSFS
> >> > backend, SVN 1.2.3 on Apache 2.0.59, Win2K.
> >> >
> >> > Have you ruled out network problems?
> >> These numbers were done at the command line of source.its-is.uni.edu so
> >> local on the machine where the repository resides..
> >
> > Please remember to use Reply To All.
> >
> > In this scenario, is it looping back, or is it still making a trip out
> > to the network? Do you have any kind of packet filtering going on?
> >
> > HTTP access is the slowest of the 3 access methods, but that's a
> > *huge* difference which doesn't make a lot of sense to me. Someone
> > else suggested directory access controls & if there's a lot or they're
> > particularly complex, that may be taking a performance toll as well.
> There aren't any access controls really, if you have access to the
> repository, you can commit, so valid user is required for access no
> other controls.
>
> I tried svn+ssh and it was really fast too. I may just switch my
> developers to that, but conceptually I liked the http access methods..

2 more data points here. I logged onto my SVN server and ran svn log
using file:/// and http:// for the same repository as above. file:///
took 7 seconds, http://18 seconds

I think we've eliminated on your system the server CPU/RAM/disk and
your choice of back-end, as things work fine for everything other than
HTTP. And HTTP is pretty fast (by comparison) for me. I'd start
looking at Apache itself, or how your network & server handle HTTP
traffic.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 14 17:12:42 2007

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

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