Re: repo.or.cz renovation

> On Thu, Mar 13, 2008 at 05:36:39PM -0700, J.H. wrote:
> > 
> > > You are of course right - I wanted to do the rename, but forgot to write
> > > it in the actual code. :-)
> > > 
> > > There is a more conceptual problem though - in case of such big sites,
> > > it really makes more sense to explicitly regenerate the cache
> > > periodically instead of making random clients to have to wait it out.
> > > We could add a 'force_update' parameter to accept from localhost only
> > > that will always regenerate the cache, but that feels rather kludgy -
> > > can anyone think of a more elegant solution? (I don't think taking the
> > > @projects generating code out of gitweb and then having to worry during
> > > gitweb upgrades is any better.)
> > 
> > You could do something similar to the gitweb caching I'm doing,
> > basically if a file isn't generated you make a user wait (no good way
> > around this really).  If a cache exists show it to the user unless the
> > cache is older than $foo.  If a re-generation needs to happen it happens
> > in the background so the user who triggers the regeneration sees
> > something immediately vs. having to wait (at the cost of showing out of
> > date data)
> 
> By the way, the index page is so far really the only bottleneck I'm
> seeing, other than that even project pages for huge repositories are
> shown pretty quickly. Did you ever try to just cache the index page on
> kernel.org? What sort of impact did it have? What evere the hotspots -
> project pages for the main repositories or some less obvious pages?
> 
> Just caching the index would be far less intrusive change than
> introducing caching everywhere and it might help to bring kernel.org
> gitweb back in sync with mainline. :-)