The impact of Prince’s death on Wikipedia
blog.wikimedia.org
blog.wikimedia.org
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:
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.
* 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
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.
It's easier to see on the full resolution graph:
https://upload.wikimedia.org/wikipedia/commons/f/f2/Prince_a...
But with certain people there's a variety of connected items that need referential integrity. For instance, I can imagine Prince being on one of those lists (eg highest grossing) that has bold text for still living artist. For office holders, they need to be moved from "incumbent" to a box with dates and the new incumbent needs to be updated. And then there's text snippets that are in present tense ("Prince and David Bowie are among the greatest living artists").
And then there's the corresponding pages in other languages.
How's it done?
They aren't. There is no transactional/referential integrity on Wikipedia. When someone famous dies a pretty common pattern is that first the death date is added, and then in a later subsequent edit someone gets around to changing the present tense verbs into past tense verbs ("Prince is a singer..." --> "Prince was a singer...").
I can tell you all about how category normalization is maintained, though. It starts with this process: https://en.wikipedia.org/wiki/Wikipedia:Categories_for_discu...
A lot, however, is just done manually by the armies of volunteers that contribute to the site. More than a few people specialize in updating bits of minutia like that.
Google beats everyone :-) they are so far ahead that I didn't even consider mentioning them!
Writes to the same object go in the same stack, iterate over stacks, pop the first item, write it, clear the stack.
It works miracles for ephemeral data like wikipedia edits.
If you have extremely spikey load on servers, stacks are also a great replacement for queues, admit that during the deluge some portion of queries will timeout and go unanswered, instead of trying to process queries that are likely to timeout, simply process the first query on the stack and don't waste time processing the ones bound to fail.
I know MongoDB still haven't marked the bug [1] reported by Kyle Kingsbury [2] that found stale reads on all consistency and write concern levels...
1. https://jira.mongodb.org/plugins/servlet/mobile#issue/SERVER...
luckily, knowledge is decentralized
Compared to, lets say Bill Gates who's saved millions of lives?
Even artistically, I'm not sure Prince was up there in the top 1%
The power of marketing.....
I never saw Prince live, but talking to people who did, he commanded the stage and the audience like few others. Without exception they describe him as one of the best live performers they have ever seen.
I don't see why you bring up Bill Gates. His philanthropy is laudable and that stands on its own. I don't see how recognizing that Prince is probably up there with the best performing artists in human history takes anything away from that.
Different people contribute differently to the betterment of mankind. That doesn't mean some contributors need to be censored away from popular culture just because you perceive their contributions to be not as important as others'.
http://historyworld.net/wrldhis/PlainTextHistoriesResponsive...
I know that he didn't gas 6 million people but letting people buy their way out of moral debt with a fraction of the money they gained still seems horribly repugnant.
[0]: https://blog.wikimedia.org/2015/12/14/pageview-data-easily-a... [1]: https://en.wikipedia.org/wiki/Wikipedia:Pageview_statistics
(1) 800rps TO THAT PAGE is the metric. The entire rest of Wikipedia was still getting traffic, and as an educated guess I would estimate raw traffic to be on the order of magnitude of 3-4krps (across editing and views). They are quite open with operations and if I weren't mobile I could probably find the accurate answer.
(2) There are much higher traffic properties. I'm aware of one property beyond 200krps in aggregate.
If you had said "most people don't have to worry about C10k," then I'm on board. That's true. Irrelevant? Far from it.
And yes, query rate and connection count have a complicated relationship. You need three or four other metrics to explain their relationship, but raw query rate is a good yardstick for active connections when combined with quantiled request latency. (Not averaged.) Simple example: a 750ms 95th% page hit 10,000 times per second is almost certainly far > C10k because of the outliers.
Now I will grant that C10k itself is somewhat irrelevant, yes, but not for the reason you are saying. It was defined in an age when 10,000 active connections was pretty surprising (didn't it come from FTP or some other heavy eyeball protocol?). These days with long poll apps, long-running protocols, and so on, millions of open connections are quite common at consumer scale. I find C1M far more interesting these days. C10M is still kinda nuts, but does exist in the magical world of metal and fiber and hot aisles and all those great things that nobody uses anymore (depressingly).
Nice find!
https://ganglia.wikimedia.org/latest/stacked.php?m=ap_rps&c=...
which you can see is not showing any substantial increase due to the passing of Prince. The big hole of two days that ends just before the news broke is due to wikimedia switching traffic to a second datacenter for two days, see http://blog.wikimedia.org/2016/04/18/wikimedia-server-switch...
http://www.phoenixframework.org/blog/the-road-to-2-million-w...
Typo and/or I call bullshit.
1: https://web.archive.org/web/20090412054158/http://www.suntim...
[1] http://www.maxim.com/entertainment/prince-2007-super-bowl-pe...
a hundred million people in one venue is certainly an unbelievable number though.