For those who are too lazy to click:

It seems that nobody knows how $wgHitcounterUpdateFreq works or even saves CPU load.

A few weeks ago someone FINALLY added a description about the technical details:
"When this setting is set to a number bigger than 1, the page id of any page viewed is stored in the hitcounter table. About 1 in every ($wgHitcounterUpdateFreq)*0.25 hits, the number of entries in the hit counter table is checked. If there is more than $wgHitcounterUpdateFreq entries in the hitcounter table, then for each entry in the hitcounter table, the relevant page_counter field in the page table is updated by 1 (and the hitcounter table is emptied). Note if the same page is visited twice (or more) between updates of the page table, it is only counted once."

But this doesn't seem to be true:

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 ~200,000 real page 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!

This bug seems to lack a problem statement.

I added the stuff you're referring to on the page on mw.org. Hopefully I didn't say anything stupid and wrong.

The behaviour of how $wgHitcounterUpdateFreq updates is what I see on my computer. However the code seems to indicate the more expected behaviour should happen (it does a group by on hc_id, which is pointless unless you somehow get duplicate rows into that table). On my computer, inserting a duplicate row into the hitcounter table doesn't create two identical rows (As one expects in a relational database...).

(In reply to comment #2)

The behaviour of how $wgHitcounterUpdateFreq updates is what I see on my
computer. However the code seems to indicate the more expected behaviour should
happen (it does a group by on hc_id, which is pointless unless you somehow get
duplicate rows into that table). On my computer, inserting a duplicate row into
the hitcounter table doesn't create two identical rows (As one expects in a
relational database...).

C:\Projects\MediaWiki\maintenance>php sql.php

insert into hitcounter values(1);

Query OK, 1 row(s) affected

insert into hitcounter values(1);

Query OK, 1 row(s) affected

select count(*) from hitcounter;

stdClass Object
(

[count(*)] => 2

)

select * from hitcounter;

stdClass Object
(

[hc_id] => 1

)
stdClass Object
(

[hc_id] => 1

)

Please don't use Bugzilla for support questions, and wiki pages are also offtopic here. In plain words, if you set $wgHitcounterUpdateFreq to 1000, it will update page view stats once in 1000 views, but if you press F5 1000 times on one page, its view counter will be increased by 1000, not by one. No bug ==> closed.

"if you set $wgHitcounterUpdateFreq to 1000, it
will update page view stats once in 1000 views, but if you press F5 1000 times
on one page, its view counter will be increased by 1000, not by one"

Then how is it performing better than without using it?