From: Jeff Garzik Date: Sat, 09 Dec 2006 12:42:25 GMT Subject: Re: kernel.org mirroring (Re: [GIT PULL] MMC update) Message-ID: <457AAF31.2050002@garzik.org> In-Reply-To: <200612091251.16460.jnareb@gmail.com> Jakub Narebski wrote: > First, it would (and could) work only for serving gitweb over mod_perl. > I'm not sure if overhead with IPC and complications implementing are > worth it: this perhaps be better solved by caching engine. It is. At least for kernel.org, the issue isn't that CGI is expensive, its that I/O is expensive. > In addition to setting either Expires: header or Cache-Control: max-age > gitweb should also set Last-Modified: and ETag headers, and also > probably respond to If-Modified-Since: and If-None-Match: requests. > > Would be worth implementing this? IMO yes, since most major browsers, caches, and spiders support these headers. > For some pages ETag is natural; for other Last-Modified: would be more > natural. Yes, a good point to note. > Usualy you can compare ETags base on URL alone. Mostly true: you must also consider HTTP_ACCEPT > Wouldn't it be simplier to just set Last-Modified: header (and check > it?) That would be a good start, and suffice for many cases. If the CGI can simply stat(2) files rather than executing git-* programs, that would increase efficiency quite a bit. A core problem with cache hints via HTTP headers (last-modified, etc.) is that you don't achieve caching across multiple clients, just across repeated queries from the same client (or caching proxy). At least for the RSS/Atom feeds and the git main page, it makes no sense to regenerate that data repeatedly. Internally, gitweb would need to do a stat() on key files, and return pre-generated XML for the feeds if the stat() reveals no changes. Ditto for the front page. > P.S. Can anyone post some benchmark comparing gitweb deployed under > mod_perl as compared to deployed as CGI script? Does kernel.org use > mod_perl, or CGI version of gitweb? CGI version of gitweb. But again, mod_perl vs. CGI isn't the issue. Jeff