[PATCH] localrepo: introduce persistent caching of revset revision's branch names
mads at kiilerich.com
Wed Oct 15 06:55:09 CDT 2014
On 10/15/2014 06:53 AM, Gregory Szorc wrote:
> Append only is a nice ideal and just that: an ideal. Things like
> transaction rollbacks are effectively strips. And transaction
> rollbacks can happen when e.g. a server-side hook rejects a push. And
> if that hook (or a hook that ran before) accesses branch data and
> causes a cache update that would trigger invalidation on rollback, the
> next unsuspecting user triggers a fresh cache rebuild and experiences
> extreme latency (if the repo is moderately sized).
(It sounds like _that_ issue could be mitigated by disabling saving of
caches while inside transactions and leave it to the next user to update
the cache. A real solution would however be nice.)
> We see this at Mozilla with rejected pushes causing branchcache
> rebuilds. On our Try repo, this leads to CPU exhaustion from multiple
> clients all triggering cache generation simultaneously (because there
> is no lock on the cache). This is why we spent time at the Summit
> coming up with a better way to add non-revlog files into transactions.
> Whatever you do, please avoid full cache (re)populations wherever
Sure, perfect would be good ... but also its enemy.
If you have a plan for a general solution, shouldn't we use that instead
of coming up with something special here? Until then, wouldn't it be
better to give the lucky users the speed-up instead of giving everybody
the worst case?
More information about the Mercurial-devel