> 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) > > Out of curiosity, repo.or.cz isn't running this as a CGI is it? If so, wouldn't > > running it as a FastCGI or modperl be a vast improvement? > > Unlikely. Currently the machine is mostly IO-bound and only small > portion of CPU usage comes from gitweb itself. Thats about the same as what I saw, it's disk bound vs. cpu/memory bound. - John 'Warthog9' Hawley -- 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
