On 17/10/12 08:56, Platonides wrote:
I think the problem was in writes to the page table
locking the `page`
table for read, which in turn slowed everything, since requests to read
`page` are ubiquitous.
This is clearly a problem with MyISAM. I would expect InnoDB to not have
so much problems with the writes. Does anyone know?
Erik Moeller thought so:
<http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/1337>
But Jimmy Wales suggested just getting rid of page view counters since
they are mostly pointless:
<http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/2389>
They were disabled in the UI, but it took until approximately
September 2003 for someone to notice that the UPDATE queries were
still being done:
<https://www.mediawiki.org/wiki/Special:Code/MediaWiki/1711>
And that was 8 months after the switch to InnoDB:
<http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/2279>
So I don't think the rationale for r1711 could have been to work
around MyISAM problems. In any case, it soon became a moot point,
since we deployed Squid in early 2004 and the existing feature could
not work with it. The hitcounter table was introduced in December 2003
by E23, but I don't think it was ever deployed to Wikimedia.
Also, the page views could be moved to a separate
table for freeing
`page` from locks.
Incrementing a counter doesn't even need to take a lock. The cost is
probably just the journaling. Which is likely the reason we first
aggregate in a MEMORY table.
It aggregates in a MEMORY table because the MEMORY table is faster, I
don't think it was ever analysed further than that.
I think it could scale (while we still are with a
single webserver),
although I'm not good at determining where would the bottleneck lie.
That's a funny definition of "scale".
-- Tim Starling