On Feb 4, 2018 12:32, "Dominik Ruf" <dominik...@gmail.com> wrote:
On Sun, Feb 4, 2018, 12:03 Mads Kiilerich <m...@kiilerich.com> wrote: > On 02/03/2018 10:12 PM, Dominik Ruf wrote: > > > Mads Kiilerich <m...@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. > > > Perhaps. 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 depends on caching. This is with a hot cache, ie not just invalidated? Do you see the same for a similar mercurial repository, or is it specific to git? What makes the difference? Is this on an SSD disk or spinning disk? In our old installation we had performance problems with a large (mercurial) repo with many heads (review repo where nothing ever gets merged), particularly after invalidating of the cache. After upgrading Kallithea we were able to bump mercurial (which was supposed to have improvements to dealing with many heads), and additionally convert our repos to the generaldelta storage format. Now performance is relatively fine. Loading a changelog page definitely does not take 54 seconds, with both cold and hot cache.
_______________________________________________ kallithea-general mailing list firstname.lastname@example.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general