<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Mads Kiilerich <<a href="mailto:mads@kiilerich.com">mads@kiilerich.com</a>> schrieb am Sa., 3. Feb. 2018 um 19:32 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/01/2018 12:50 AM, Dominik Ruf wrote:<br>
> Hi all,<br>
><br>
> I'm currently looking at the caching Kallithea does. And I'm a<br>
> bit...baffled.<br>
<br>
Yes, it is quite baffling and not very efficient.<br>
<br>
I think it very rarely gives any real benefit - it might even make<br>
things slower. In real world setups with multiple repositories served by<br>
each worker process, cache hits are quite rare.</blockquote><div>For large git repositories we certainly do need caching.</div><div>In fact, we need more of it, because currently showing the changelog for large repositories like the linux kernel, takes for ages.</div><div>That is the reason why I'm looking at the caching.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> The way I understand it is that first an entry is made to<br>
> CacheInvalidation to mark a cache invalid,<br>
<br>
That is to register the in-memory cache in the database.<br>
<br>
> and later that entry is checked to decide if that cache should be<br>
> invalidated.<br>
<br>
That is to see if other process have invalidated the cache.<br>
<br>
/Mads<br>
</blockquote></div></div>