I can't reproduce this on the provided links. They report a more similar count now. ("636 727" on the canonical, "638 263" on the useskin urls).

It's still off by 2,000 however. And it seems the canonical url count hasn't changed since you reported the issue. What kind of caching do you have set up?

What kind of caching do you have set up?

File cache.

In T136538#2350895, @Nemo_bis wrote:

What kind of caching do you have set up?

File cache.

Right, that means for users without an active session, the HTML response of cacheable requests (by default, this is only page view and page history) is cached for as long as the page isn't edited or purged.

I purged the article just now and it now correctly shows the latest count of "636 727".

See Article::isFileCacheable(), FileCacheBase::isCacheGood(), and HTMLFileCache::useFileCache().

Aside from canonical skin/language view of page and page history, requests are considered uncacheble (to avoid bloat, and because they're harder to purge). So uselang and useskin with a value that does not match the default will bypass the cache.

While HitCounters has been improved over the last year to perform better (e.g. not doing database changes on every single page view, and it caches the displayed count for a few hours), it remains fundamentally incompatible with most caching strategies. Including proxies like Varnish or Squid and FileCache.

If you want to keep HitCounters you'll need to disable FileCache, or manually purge FileCache more frequently (e.g. every 24 hours for example).

Alternatively, one could investigate to a performant way to substitute the count in the cached html with the latest (also) cached count from HitCounters. That way it will let HitCounters handle the incrementing and caching of the count separately from the parser cache. Right now they are intertwined (FileCache is managed solely by wiki page edits and purges).

it remains fundamentally incompatible with most caching strategies

AFAICT, it was working with the hit counters in core; it broke when we upgraded MediaWiki.

I notice this is about user status rather than skin: as unregistered user I see one number whatever the skin, as registered user another number whatever the skin (checked by setting ?useskin=monobook or ?useskin=vector).