Shall we drop the pedantic pissing about and get back to the real issue, then?
Yes, please.
I talked to Leon about ways to make hit counters feasible, for all projects. The core points are:
* Just like Edward did, use JS code trigger an HTTP request on page views. But this should be throttled to a probability of 1% - or, for large projects, 0.1%. This should still give us usable stats for the most popular pages.
* Just like Edward, use a persistent server, not cgi/php. To avoid exposing home brewen hacks to the wild web, we should stick to something tried and true. I suggested to implement it as a Java servlet. Should be fairly straight forward, and we have Tomcat running anyway.
* To get around latency issues with the database, don't spawn (cause more load on the already troubled DB); instead, cache updates in RAM for a minute or so, the flush the into the db in a single insert.
* Edward used a lot of ram for a name -> id mapping. This should be avoided - the name is unique, we don't need the page ID. If we want the ID, it should be determined on the wikipedia server and supplied with the request - I talked to Tim Starling about making this and other useful things available as JS variables.
Perhaps Edward and Leon can work on this together. In any case, I would suggest to throttle updates from the ruwiki to 1% of page hits, *if* the page counter is to be enabled again. something like this should do:
if (round(random()*100)=1)...
Regards, -- Daniel