[PATCH] hgwebdir: cache hgweb instances (and their repos) between calls

Sune Foldager cryo at cyanite.org
Tue May 24 06:09:23 CDT 2011


On 2011-05-24 13:01, Sune Foldager wrote:
># HG changeset patch
># User Sune Foldager <cryo at cyanite.org>
># Date 1306234857 -7200
># Node ID 70b4f148d838bbd8b2da7540b135cc092ef98250
># Parent  25137d99a5ed215f302ffc1793590bdbdb437b55
>hgwebdir: cache hgweb instances (and their repos) between calls

Ok, I forgot to write an intro... this is an RFC, not a patch that's meant
to be pushed right now.

There are some differences in cache refresh from hgwebdir to hgweb:

- hgwebdir refreshes all configuration every 20 seconds.
- hgweb never refreshes configuration, unless the repo changes, in which
   case a new repo instance is created.
- since hgwebdir didn't cache hgweb's before, hgweb running under hgwebdir
   had its configuration reloaded every time.

So applying this patch will cause hgweb to no longer refresh its config,
like when you run it alone. This is a regression.

I was thinking if we should do a bit better when caching and/or refreshing
the configuration. Couldn't we have ui store which files it has loaded
so far, and then stat those in the refresh code (maybe only every n seconds)?

That would mean:

- hgwebdir only has to reload config if something changed.
- hgweb can react on config changes when running alone (can't right now).
- the caching in this patch won't mess with the above, and will progress
   instead of regressing.

The problem is, of course, that a lot of things can change such as environment
variables causing different config paths to take effect etc. But I don't think
it's too much to ask that people manually recycle their web server or similar
in such cases, or restart hg serve.

Thoughts..? :)

-Sune

PS:

The hgwebdir code has, just before it looks for repos in run_wsgi, this line:

repos = dict(self.repos)
                  
...where it copies the repo list into a temporary dictionary, instead of using
a single one in the instance. Does anyone know why this is done? In this patch
I have not done something similar with my new cache, but that might be
necessary depending on the reasons for the existing code.


More information about the Mercurial-devel mailing list