Re: [PATCH 3/3] gitweb: use new Git::Repo API, and add optional caching

From: Lea Wiemann <lewiemann@gmail.com>
Date: Jul 15, 2008, 01:16 UTC
Message-ID: <487BFA67.3020304@gmail.com>
In-Reply-To: <200807150252.52604.jnareb@gmail.com>

Jakub Narebski wrote:

Show 7 quoted lines

> On Tue, 15 July 2008, Lea Wiemann wrote:
>> # Transient cache entries (like get_sha1('HEAD')) are automatically
>> # invalidated when an mtime [...] changes.
> 
> Nice idea... for project pages.  I'm not so sure about projects_list
> page, if wouldn't be better to have expire time for *this* page.  You
> would have/have to stat a lot of files/directories to detect changes.

It doesn't seem to be too much of a performance issue (it takes ~500ms to generate the project list on kernel.org), and project lists aren't requested often enough to be a good optimization target.

I'll see how it performs when the OS's page cache is cold though; if it's too slow then I might revisit the issue.

> BTW. some summary of the above should be IMHO in the commit message.

*nods*

> In this case you don't have any basis to set expires for transient views;
> on the other hand situation doesn't differ much from serving static
> files (wrt. cache validation) so perhaps no expires but no "no-cache"
> would be a good solution.

Gitweb provides a view on a live repository, so I don't think caching is usually what you want (e.g. static pages really tend to change much less frequently). (And yes, my Opera *does* seem to cache those pages unless you add no-cache.)

Really, I don't think the performance penalty of revalidation will be significant enough to justify risking stale data. IOW, it's pretty fast. Check out repo.or.cz's performance (and repo.or.cz doesn't even use Last-Modified).

> P.S. is there any cache evision mechanism (to limit cache size)
> in gitweb cache, or just those implemented by caching backend?

For the $cache, it's in the caching backend, for the $large_cache, there is no mechanism, so you need to clean up yourself. See the patch. ;-)