The HTTP Cache component handles CDN purging and FileCache storage in MediaWiki core.
This includes:
Maintained by: Performance-Team
Parent project: MediaWiki-General
Well, I implemented my bot a long time ago, and check in on it occasionally. It's been working well, and anyone considering forcing purges from the server level is welcome to use whatever pieces of my code might be helpful.
One potential problem though is that when purging an image page, doing the purge POSTSEND might make the user see stale data as typically users don't have a cache busting cookie for the image server. So i guess file purges should still be PRESEND.
Part of the issue here is that curl removed support for http/1.1 pipelining which made this much slower. Edit: Seems like without pipelining it just opens multiple tcp connections at the same time, so the latency difference really shouldn't be that much
I just encountered another wiki where doing these PRESEND was the cause of a major save time latency (was taking multiple seconds to send cdn purges). I think this is a major performance hurdle for most wikis using HTTP based cache purging.
I'm pretty sure that you get a session cookie if you edit while logged out (regardless of if you have the new temporary accounts feature enabled or not), unless that has changed since 1.43. I think a reasonable approach to this issue, if WMF have concerns about using POSTSEND, is to allow third-party wikis to configure this without needing to edit the source code.
Session yes, if they're logged in, or reached Special:CreateAccount/Special:UserLogin. Anons get the ChronologyProtector cookie but that only lasts 10s, and might also often not be configured to exempt from caches on third-party setups.
Wouldn't the editor having a session prevent them from seeing stale pages?
This sounds like at least part of the reason why I haven't really tried to get my wikis working with a CDN (CloudFront since they're in AWS), concern about this kind of latency issue.
In this case, it sounds like it would run into the problem of users seeing stale pages (even without other slow deferred updates, but worse with them). I know that CDNCacheUpdates try to merge into batch updates, and we have an HTTP purge client class that does multiple URLs concurrently. Is it taking multiple seconds to purge a single URL? That seems like an operational problem.
Then it probably might be worth adding a setting so 3rd party wikis and wiki farms where purging takes longer can control whether it uses PRESEND or POSTSEND.
On WMF sites, the update just queues the purge into another service, so it's quick. We also don't want the deferred purge update to end up running after a bunch of slow POSTEND deferred updates. Since these POSTEND do not block the user, in that case, the user might have a decent chance of seeing stale data, since they can follow redirects and navigate around before the deferred purge update gets started. Our own purge queuing service is pretty quick, so that risk is minimal as a PRESEND update. We can't control how fast *other* POSTSEND updates are though.
In case its not clear, sending this PRESEND can cause significant latency if you are using traditional HTTP purging and have multiple cache servers. I think the request here is to change this to POSTSEND unless there is a compelling reason why doing that would be a bad idea.
As a test, I've done the following:
Noting T404941: {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} is not automatically updated in mobile, but updated in dekstop view, which seems quite similar to what's reported here, except that there's also a report there of a Main Page showing outdated content to logged-in users on mobile (T404941#11194701).
There is the RFC 9213 "Targeted HTTP Cache Control" published in June 2022 related to this task: the idea is to use a header CDN-Cache-Control dedicated to the reverse proxies/CDN with the same semantics as Cache-Control.
Resetting task status from "In Progress" to "Open" as this task has been "in progress" for more than one and a half years (see T380300).
I suspect this may be caused by the use of grace (akin to stale-while-revalidate). This allows pages, even those with an intentionally shortened max-age (eg 1h instead of the default wgCdnMaxAge of 14 days, and wgParserCacheExpireTime of 30 days) to be renewed via HTTP 304.
purgeList from mwscript-k8s has worked previously, so my instinct is this is an intermittent problem rather than any of the possible "we just forgot to set this up" situations.
I don't see how we can stop caching and purging the rest api urls.
This might be a reasonable pair of hypotheses for annual planning:
Note that this is decoupling the reparsing/ParserCache invalidation done by the RefreshLinksJobs (which is mandatory and must be done) from the front-end cache (CDN/PCS) invalidation (which is optional and may be skipped).
@aaron: Removing task assignee as this open task has been assigned for more than two years - See the email sent to task assignee on October 11th.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!
Declining per Krinkle. I guess we can hope that this was an isolated and Beta-only issue, until it happens again.
FWIW, I could see the issue when this task was filed, about 7 hours after the revert.
I can't reproduce this issue.
They look identical to me. In production (if the caching happens in Varnish) caching bugs might depend which of the many Varnish frontends you end up talking to (so in the end, your IP); I think we only have one Varnish server on beta so it should be deterministic. Maybe the purge was just very slow (ie. job queue lag)?