From: Kay Sievers <kay.sievers@vrfy.org>
Date: Wed, 19 Oct 2005 01:23:41 GMT
Subject: Re: gitweb.cgi
Message-ID: <20051019012341.GA15256@vrfy.org>
In-Reply-To: <Pine.LNX.4.64.0510181753340.3369@g5.osdl.org>

On Tue, Oct 18, 2005 at 06:02:29PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 18 Oct 2005, H. Peter Anvin wrote:
> > 
> > It turns out that the default CacheSize is only 256K.  D'oh!  Fixed.
> > 
> > I also changed the CacheDefaultExpire to 600 seconds.
> 
> Ok, that sounds like it should improve things. My quick tests didn't seem 
> to show any difference, though. Do you need to re-load the apache module 
> or something?
> 
> > The only thing the front page really should need is to know when the last
> > change to the tree was, which presumably means looking at each head of each
> > tree and follow the chain until there is a datable object.
> 
> Yeah. I tried to follow gitweb.cgi, but I'm neither http- nor 
> perl-literate, so I'm not sure I caught everything.
> 
> But it does seem to basically end up doing a "git_read_commit()" for each 
> project, and that in turn was doing the "git-rev-list --max-count=1" thing 
> that I just sent out a suggested improvement for.
> 
> It effectively removes two or more copies of
> 
> 	stat64("/objects/xy/zzy", {...})
> 	fd = open("objects/xy/zzy", O_RDONLY|O_NOATIME)
> 	addr = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0)
> 	close(fd)
> 	munmap(addr, size)
> 
> which really should be very cheap operations, but hey, if the disk head is 
> somewhere else (and busy) and it's not cached, it can be quite expensive. 
> Especially since we don't end up usign the result.
> 
> I'm sure there's room for improvement inside gitweb itself too, but maybe 
> the git-rev-list optimization will help.

There definitely is! But I tried a single "stat() all HEAD files" with a
simple script and it took more than 3 seconds for the 80 trees. Then I
gave up "optimizing" and was sure we want to have a single-file cached front
page instead. :)

Kay