On Mon, 2008-03-17 at 18:49 +0100, Petr Baudis wrote: > 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. :-) I think we are likely going to want to keep caching everything vs. just the front page. There are a few repos that get hit quite a bit and it would be better to have those cache vs. not. Really I would argue this is just a step in the direction of integrating all of my caching changes back into gitweb vs. us dropping what we've done so far. BTW I'm about halfway through refactoring my tree from multiple files back to one, which at that point means I can start bringing it back into mainline and getting a patch series ready for submission. - John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
