Caching and concurrency?

[John Keeping]

On Sat, Apr 13, 2013 at 03:54:35PM +0200, Peter Wu wrote:
> I was wondering how well the caching mechanism of cgit works. Is it
> designed for concurrent access to the cache folders? I am tempted to
> use nginx cache mechanism, but a downside of that is that duplicate
> cache entries may occur (?id=d34db33f vs ?id=d34db33f000000 are
> possibly the same, but I guess nginx sees it as the same) and that
> entries are at least as old as the nginx cache expirity time.
> 
> Anyway, the questions:
> - Is cgits cache immediately updated whenever the git tree is updated?
> If not, what delay can I expect?

CGit's cache is updated only when the cache is out-of-date.  The TTL for
each cache entry can be specified in the configuration file.  See the
documentation of the cache-size and cache-*-ttl variables in cgitrc(5)
for the full details.

> - Is it better to use a dedicated caching proxy (nginx) instead of
> cgit when available?

I suspect the caching proxy will perform better in general since CGit
must go to the filesystem for every cache access (although frequently
accessed entries are likely to be in the operating system's filesystem
cache so I wouldn't expect this to be too expensive).

Using a dedicated caching proxy will also avoid the overhead of starting
CGit for each request.  On the other hand, it may be harder to specify
different TTLs for the different types of page CGit generates.

> - How well prepared is cgit for concurrent access?

CGit works fine with concurrent access.  If a page is cached and the
cache is in the process of being generated, CGit will serve the state
cache contents.