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. :-) -- Petr "Pasky" Baudis Whatever you can do, or dream you can, begin it. Boldness has genius, power, and magic in it. -- J. W. von Goethe -- 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
