Re: Current caching

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

Re: Current caching

gt; >>>> 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

Re: Current caching

lower. 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. >> >> >> Perhaps. But it is probably a very different kind of caching we need. >> &g

Re: Current caching

. But it is probably a very different kind of caching we need. > Displaying a changelog page with 100 changesets currently takes 54 seconds even with the current caching for the Linux Kernel. I'm about to make some changes that will get this down to about 2.5 seconds. But of course this also depen

Re: Current caching

s 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. > > > Perhaps. But it is probably a very different kind of caching we need. > Displaying a chang

Re: Current caching

On 02/03/2018 10:12 PM, Dominik Ruf wrote: Mads Kiilerich > 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 >

Re: Current caching

Mads Kiilerich 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

Re: Current caching

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

Re: Current caching

Thanks for still helping the project. That helped. On Thu, Feb 1, 2018, 09:04 Marcin Kuzminski wrote: > Hi Dominik, > > The database table is used for invalidation multiple processes. e.g if you > run 3 workers via gunicorn each of them will register an entry in cache >

Current caching

Hi all, I'm currently looking at the caching Kallithea does. And I'm a bit...baffled. The way I understand it is that first an entry is made to CacheInvalidation to mark a cache invalid, and later that entry is checked to decide if that cache should be invalidated. But why this detour? Why not