Current caching

Dominik Ruf dominikruf at gmail.com
Sat Feb 3 21:12:13 UTC 2018


Mads Kiilerich <mads at kiilerich.com> schrieb am Sa., 3. Feb. 2018 um
19:32 Uhr:

> On 02/01/2018 12:50 AM, Dominik Ruf wrote:
> > Hi all,
> >
> > I'm currently looking at the caching Kallithea does. And I'm a
> > bit...baffled.
>
> Yes, it is quite baffling and not very efficient.
>
> I think it very rarely gives any real benefit - it might even make
> things slower. In real world setups with multiple repositories served by
> each worker process, cache hits are quite rare.

For large git repositories we certainly do need caching.
In fact, we need more of it, because currently showing the changelog for
large repositories like the linux kernel, takes for ages.
That is the reason why I'm looking at the caching.

>
> > The way I understand it is that first an entry is made to
> > CacheInvalidation to mark a cache invalid,
>
> That is to register the in-memory cache in the database.
>
> > and later that entry is checked to decide if that cache should be
> > invalidated.
>
> That is to see if other process have invalidated the cache.
>
> /Mads
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20180203/be68ee12/attachment-0001.html>


More information about the kallithea-general mailing list