https://wikitech.wikimedia.org/wiki/PoolCounter
TL;DR:
It's a limiter on how many workers start rendering the new page version when the old page version in cache has been invalidated.
https://wikitech.wikimedia.org/wiki/PoolCounter
TL;DR:
It's a limiter on how many workers start rendering the new page version when the old page version in cache has been invalidated.
There are more (coherent and to-the-point) details about PoolCounter in the prologue to PoolCounter.php in MediaWiki's source tree:
https://github.com/wikimedia/mediawiki/blob/1617e7822eaf7426...
And in a short blog post by Domas Mituzas, who is the original author of PoolCounter:
* Cache never automatically expires, but you do have some notion of staleness * Whenever you request data, you get it from the cache (if it exists), and check for staleness, so you cached data needs to know when it was cached. * Return the data as usual, but if the data was also stale, you fire off a worker to update the cached data. * If you have lots of requests happening at the same time, you have a system for seeing if a worker already exists, to ensure that you only create one (for each piece of cached data). * For the time it takes for the worker to complete, you have to be okay with serving stale data, in most cases this is okay.
There's an edge case missed here, which is what to do when the cache is empty (either because it's one of the first requests, or because the cached data has been evicted). That's up to you, depending on your use case. You can basically either return a default value, you can pre-warm your cache, or you can let the requests hang until the data is ready.
A former colleague of mine built a Django implementation of this pattern, which is pretty useful: https://github.com/codeinthehole/django-cacheback
The advantage is less coordination is necessary and you should be able to get down to a single concurrent rerender per page.
I suppose, in this case you could use the time since invalidation as your input. The downside is that changes in the source aren't immediately reflected in the rendered output, especially for infrequently updated pages.
There's a wikipedia article on the thundering herd problem.
https://en.wikipedia.org/wiki/Thundering_herd_problem
The article needs a little love, though.