Talk:Requests for comment/Removing hit counters from MediaWiki core

People like stats, I don't think it should be removed. I have however, been wanting for some time to add the needed hooks so one can use a different counter implementation. Platonides (talk) 19:46, 27 November 2013 (UTC)
 * I use them on wiki regularly. --Nemo 09:35, 27 November 2013 (UTC)
 * For what? --MZMcBride (talk) 19:00, 2 December 2013 (UTC)
 * To know how many hits a page has. --Nemo 19:34, 2 December 2013 (UTC)
 * Platonides: I agree that people like stats. However, these stats are inaccurate and have no granularity. Wikis wanting actual stats install Extension:Google Analytics or similar. I'm not sure why core needs its own hit counters when the cost is so much higher than the benefit. We know that all Wikimedia wikis do not and cannot use built-in hit counters. Which wikis are effectively using them?
 * Regarding hooks and such, I believe most engineers in this field have decided that using client-side JavaScript is the best way to gather analytics. ResourceLoader and site-wide JavaScript pages (such as MediaWiki:Common.js) already cover most of what you'd need, right? --MZMcBride (talk) 19:00, 2 December 2013 (UTC)

The stats are good for smaller wikis that don't have any other stats solution. They have to be in place from the time of installation if they're going to be accurate. They can be switched off later if the system administrator doesn't want them.

In what way are they too inflexible? Don't config settings like Manual:$wgHitcounterUpdateFreq give us some flexibility? I am curious, though — how much of a performance hit do wikis take when they use hitcounters? Leucosticte (talk) 07:06, 28 November 2013 (UTC)
 * The current implementation is a single integer field in the page table. There's no granularity: there's no additional information stored about unique v. non-unique visitors, browser user agents, geolocation data, etc.
 * As for performance, if hit counters are enabled (as they are by default) and there's no front-end caching, you're writing to the database on every page view. For small sites, this is negligible for performance. For larger sites, it can be a major performance bottleneck. No large wiki would ever keep this setting enabled, which is why guides such as User:Aaron Schulz/How to make MediaWiki fast and Five minutes of MediaWiki performance tuning recommend disabling counters. Even on sites that keep counters enabled, I fail to see the value if the stats are simply wrong. --MZMcBride (talk) 19:00, 2 December 2013 (UTC)
 * Wikia has globally turned off all this code as well due to performance reasons. It doesn't scale for wikis with any kind of traffic (thousands of hits per day is probably okay, but not millions).  site_stats has a similar lack of time granularity and we disabled ss_total_views because its also a useless metric which causes performance problems but most of the other fields there are reasonable.  I can see the argument for having a simple stats mechanism, but I personally feel like that should be an extension, not a part of core.  Owyn (talk) 22:04, 2 December 2013 (UTC)


 * Some #wikimedia-dev discussion

Hit statistics requirements
I have been playing with Piwik for a while for traffic analysis and other statistics. As google analytics, though, Piwik is way more than a hit counter. And, the more powerful an analytics system is, the more does one want to know :) So, one issue I came across several times is the question, what information do I need in order to get good statistics. Only once we do know the requirements, we can talk about whether we need a hook or any other mechanism to get this info to the analytics software. Here's some suggestions: All of these are readily availavle client side. In my own example, I also had the need to track only pages that contained a certain tag. A standard way of hooking in this information might be a good idea! --Mglaser (talk) 14:28, 31 December 2013 (UTC)
 * Article title
 * Namespace
 * Category
 * User (?)