Intelligent caching

Intelligent caching

[cgit]

Hi,

Reading through our caching code, I wondered why we don't make it a bit
more clever. For every dynamically created page, we could just store a
fingerprint that can be computed quite fast and indicates whether the
cache slot is still up-to-date or not.

For example, on the log pages, we could save the commit the
corresponding ref points to and invalidate the cache slot when the ref
has changed. Using that, we could use the power of caching and never
deliver outdated pages at the same time.

What do you think about that?

Regards,
Lukas

Intelligent caching

[Jason]

This could be clever, if it's done properly. It'd have to be something
along the lines of "this page won't ever change, unless you can create an
sha1 hash collision", and we'd have to be certain that such pages then only
use information out of that sha1 object, and not additional related objects
that can be changed.

On Wed, Feb 5, 2014 at 11:18 AM, Lukas Fleischer <cgit at cryptocrack.de>wrote:

> Hi,
>
> Reading through our caching code, I wondered why we don't make it a bit
> more clever. For every dynamically created page, we could just store a
> fingerprint that can be computed quite fast and indicates whether the
> cache slot is still up-to-date or not.
>
> For example, on the log pages, we could save the commit the
> corresponding ref points to and invalidate the cache slot when the ref
> has changed. Using that, we could use the power of caching and never
> deliver outdated pages at the same time.
>
> What do you think about that?
>
> Regards,
> Lukas
> _______________________________________________
> CGit mailing list
> CGit at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/cgit
>



-- 
Jason A. Donenfeld
Deep Space Explorer
fr: +33 6 51 90 82 66
us: +1 513 476 1200
www.jasondonenfeld.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20140206/a3c6209f/attachment.html>

Intelligent caching

[cgit]

On Thu, 06 Feb 2014 at 20:55:14, Jason A. Donenfeld wrote:
> This could be clever, if it's done properly. It'd have to be something
> along the lines of "this page won't ever change, unless you can create an
> sha1 hash collision", and we'd have to be certain that such pages then only
> use information out of that sha1 object, and not additional related objects
> that can be changed.
> [...]

I started to work on this. The main difficulty is that currently, the
caching layer currently sits on top of prepare_repo_cmd() and is
executed at a very early stage when there is no still no access to the
Git repository.  So before implementing this, I guess that we should
check whether the caching mechanism can be moved without performance
impacts (someone needs to review the code and benchmark this).

For now, I will just merge the patches that have been sitting in
lf/staging for several days.