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 _______________________________________________ MediaWiki-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
