Jakub Narebski wrote:
quoted text
> 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.


quoted text
> 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.


quoted text
> For some pages ETag is natural; for other Last-Modified: would be more
> natural.

Yes, a good point to note.


quoted text
> Usualy you can compare ETags base on URL alone.

Mostly true:  you must also consider HTTP_ACCEPT


quoted text
> 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.


quoted text
> 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


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html