Roan Kattouw <> changed:

           What    |Removed                     |Added
                 CC|                            |,
                   |                            |

--- Comment #5 from Roan Kattouw <> 2010-09-27 09:12:08 
UTC ---
(In reply to comment #4)
> Re: my modulo idea; that was borne of my ignorance+forgetfulness of how our
> caching works.  I'm not sure exactly how things are configured, but since tghe
> parser cache uses memcached (right?), and memcached already uses LRU and maybe
> even expiration times to dump things out of the cache, there's probably not 
> the
> need for additional complexity in the app.  
There's actually two different layers of caching you're dealing with here:
revision cache and parser cache. Both live in memcached.

The revision cache caches the wikitext of every revision that's ever obtained
from the external storage and caches it for 7 days. There is no discrimination
between old and new revisions here, other than that LRU will most likely
advantage newer revisions.

The parser cache caches the parser output (rendered HTML plus metadata like
links, used templates and used images) for a variety of parser options (e.g.
whether to show [edit] links, whether to use weird redlinks with a ? at the
end, etc.) but only for the latest version of each page. The expiry time will
be an hour or so if time-dependent magic words like {{CURRENTDAY}} are
involved, but is generally set to never. When a page is visited for the first
time after having been edited, MW will notice the parser cache entry is stale
(because it's older than the newest revision) and reparse the page. As a
consequence, ParserCache::get() can only fetch the latest revision of a page.

I believe you're right that memcached uses LRU to evict things from cache when
it runs out of space. Whether storing old revisions in the parser cache
(possibly forever) is desirable and whether additional complexity in MW is
needed to do this sanely is a question I think is best answered by Tim (CC).

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Wikibugs-l mailing list

Reply via email to