On 15/10/12 16:32, Chad wrote: > There's a lot more to it than that, and it is indeed a performance > drain (which is why we don't use it at WMF). Each pageview > writes to the hitcounter table. Every so often the page table is > updated with the hits from hitcounter. > > Sure, displaying the hits is a simple query to the page table, > but updating hitcounter each pageview just does not scale. > > -Chad
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? 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. 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. Regards _______________________________________________ MediaWiki-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
