Manual talk:$wgHitcounterUpdateFreq

I don't get this. Does this mean if it is set to a high number, that the statistics will be less accurate, or just that it won't hurt the DB as much and will still be the same stats? Does that make sense? --12.219.111.23 04:05, 12 April 2007 (UTC)

The statistics will still be gathered accurately, it just will be shown with some delay. --CodeMonk 03:29, 18 June 2008 (UTC)

Sure? Because "any higher value n cause them to update on average every n hits" doesn't sound like that. --Subfader 14:10, 30 April 2010 (UTC)

To answer my own question: I'm using it for quite a while now and it seems to work properly, although I wonder how it can boost performance??? --Subfader 15:03, 26 May 2010 (UTC)

I thought it should be something about privacy, not performance. --219.139.224.121 07:40, 23 May 2010 (UTC)

Database Alleviation?

How exactly does enabling a higher number alleviate database hits? Is it still updating the database every time a person hits a page and only updating the statement at the bottom of pages?

If it's supposed to be stopping the amount of times the database gets updated for each page hit, is it saving this 'average' in JavaScript, or opening and writing to a document? I don't know enough about MediaWiki's internals so i'm not going to update the main page with a better description on how exactly this helps keep database calls down, but it would be much appreciated if someone that knows how this works does update the page.

Just saying "update on average" really doesn't answer any questions on just how that happens.

--Iarp 02:17, 28 October 2010 (UTC)

Technical details

Changing after a few years?

Question: What happens if you change this from 1 to 2000 after the wiki has been live for a few years? Will it still be OK all will all hell break loose with data consistency? I guess it boils down to how the data is transferred from hitcounter to pagecounter. Is the hitcounter count multiplied by $wgHitcounterUpdateFreq when the data is added back to pagecounter?

Older questions

Now that we finally got a technical description about how this works, I wonder even more: How can it be accurate when "if the same page is visited twice (or more) between updates of the page table, it is only counted once."??? Sounds like a non-sense feature to me, sorry. Now that I used it for months I ruined all viewcount stats. Now the only true fact is: "This page has been accessed more than X times". --Subfader 20:59, 9 February 2011 (UTC)

PLEEEASE! No dev feels the need to post? Since WP uses $wgDisableCounters = true; nobody cares? REMOVE this feature if it doesn't work...

Meanwhile I observed that the description ("if the same page is visited twice (or more) between updates of the page table, it is only counted once.") can't be true:

I use $wgHitcounterUpdateFreq = '1100';. According to the description this means that the view counter of an accessed page is raised by 1 within 1100 total wiki page accesses, no matter if said page has been accessed more than once within those 1100 page accesses. Today I added a new page which I knew would be HOT. After 15 minutes the footer did not read the view count yet (less than 1100 total page accesses within that time, which seems ok with ~250,000 real hits per day). After 30 mins it read that the page was accessed 50 times. This seems real too but can't be true with $wgHitcounterUpdateFreq = '1100'; according to the description! Cos this would mean that my wiki had 1100 x 50 = 55,000 page access in 30 minutes. No way!

So $wgHitcounterUpdateFreq seems to count properly but a) the description is total nonsense and b) it doesn't seem to sdave any CPU load at all!? I added a bug report in hope for final clearification: https://bugzilla.wikimedia.org/show_bug.cgi?id=28286 --Subfader 23:30, 27 March 2011 (UTC)

It would presumably save cpu/etc because it wouldn't have to lock stuff in the page table on each view to update the counter field. The hitcounter table is also a memory table (Which from my understanding) is much faster to update. As for the actual behaviour of this. The code is written as if each hit would be recorded in the hitcounter table (it uses a group by to count total hits per page), but that doesn't seem to happen since duplicate rows aren't recorded. Bawolff 03:55, 28 March 2011 (UTC)

Bawolff description was wrong in that using $wgHitcounterUpdateFreq does not increase the page_counter but in 1 but in the number of page views that happened (they are counted in a delayed way). Thus your Disadvantages section derived from that was also wrong. I don't see anything supporting the statement that "visiting a page twice won't update it", so I have also removed it. You don't loss views not even while a parallel process is updating the page_count. Platonides 15:29, 28 March 2011 (UTC)

My apologies. It appears I was totally and utterly wrong. I think I got confused because in my testing I tried loading a page multiple times, and that only resulted in a single entry in the hitcounter table. I interpreted that as being due to it rejecting duplicates, where really it was because I was being served a 304 not modified page (And thus the hit counter code did not run). I really should not add things like that to pages like this without being sure. Sorry for the confusion. Bawolff 16:55, 28 March 2011 (UTC)

Happy this was clearified. Your description made sense tho :D Sorry for the kinda strong language above. --Subfader 18:34, 28 March 2011 (UTC)