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