Page MenuHomePhabricator

Move thumbnail caching from upload cluster to text
Open, In Progress, HighPublic

Description

(Idea by @BBlack. I'm mostly documenting the discussions.)

Currently, 81% of the requests to the upload cluster are to thumbnails. The proposal is to move these requests to be served from text cluster instead. Basically changing the separation from "text" vs. "upload" to "main" vs. "aux" instead.

Why?

  • Having one large cluster gives us elasticity. Meaning we will have better tolerance towards depooled hosts and spikes
  • Thumbs are by nature smaller and are being hurt by originals and large files displacing them out of memory. Meaning, moving them to text and assuming the same capacity, the cache hit ratio should go up.
  • This would increase our resilience against scrapers which by and large mostly hit originals leading to outage of all of upload cluster leading to degraded user experience.
  • Thumbs are mostly human traffic while originals is most scrapers (47% of the requests to originals have browser score of 80 or above, that number is 60% for thumbs). This allows us to rate limit originals more strictly.
  • It would also allows us to set network QoS for upload to be something lower to avoid overwhelming backhauls when originals are being scraped to death while still giving the first class experience to human traffic.

Technical implementation:

Notes:

  • Moving to thumb.wikimedia.org also allows us to move the caching to somewhere else easily if/when the need arises (for example a fully dedicated edge cluster, etc.)
  • That leaves upload with these: originals, transcodes, maps
  • We could eventually move MPEG-DASH files to text too, they are similar in nature. I have no knowledge on maps infra so I can't say anything about moving those.

Details

Related Changes in Gerrit:
SubjectAuthorRepoBranchLines +/-
Ladsgroupoperations/puppetproduction+6 -6
Krinkleoperations/puppetproduction+40 -39
Ladsgroupoperations/puppetproduction+1 -1
Ladsgroupoperations/mediawiki-configmaster+2 -3
Slyngshedeoperations/puppetproduction+58 -14
Ladsgroupoperations/mediawiki-configmaster+6 -9
Ladsgroupoperations/mediawiki-configmaster+3 -0
Ladsgroupoperations/mediawiki-configmaster+1 -0
Ladsgroupoperations/mediawiki-configmaster+1 -0
Ladsgroupoperations/mediawiki-configmaster+2 -0
Ladsgroupoperations/mediawiki-configmaster+1 -0
Ladsgroupoperations/puppetproduction+1 -1
Ladsgroupoperations/mediawiki-configmaster+3 -3
Ladsgroupoperations/mediawiki-configmaster+13 -1
Slyngshedeoperations/puppetproduction+1 -0
Slyngshedeoperations/puppetproduction+10 -0
Ladsgroupoperations/puppetproduction+11 -0
Slyngshedeoperations/puppetproduction+425 -1
Slyngshedeoperations/puppetproduction+249 -215
BCornwalloperations/puppetproduction+248 -214
CDobbinsoperations/puppetproduction+63 -0
Slyngshedeoperations/puppetproduction+12 -0
Ladsgroupoperations/dnsmaster+1 -0
Show related patches Customize query in gerrit

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change #1327175 merged by BCornwall:

[operations/puppet@production] varnish: Loosen the regex for thumbnails

https://gerrit.wikimedia.org/r/1327175

Change #1327197 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/mediawiki-config@master] Enable thumb.wikimedia.org on mediawiki.org

https://gerrit.wikimedia.org/r/1327197

Change #1327197 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable thumb.wikimedia.org on mediawiki.org

https://gerrit.wikimedia.org/r/1327197

Mentioned in SAL (#wikimedia-operations) [2026-08-19T23:08:31Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1327197|Enable thumb.wikimedia.org on mediawiki.org (T427465)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-19T23:10:56Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1327197|Enable thumb.wikimedia.org on mediawiki.org (T427465)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-19T23:19:21Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1327197|Enable thumb.wikimedia.org on mediawiki.org (T427465)]] (duration: 10m 50s)

Change #1327518 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/mediawiki-config@master] Enable thumb.wikimedia.org on cswiki and fawiki

https://gerrit.wikimedia.org/r/1327518

Change #1327518 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable thumb.wikimedia.org on cswiki and fawiki

https://gerrit.wikimedia.org/r/1327518

Mentioned in SAL (#wikimedia-operations) [2026-08-20T11:26:34Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1327518|Enable thumb.wikimedia.org on cswiki and fawiki (T427465)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-20T11:30:49Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1327518|Enable thumb.wikimedia.org on cswiki and fawiki (T427465)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-20T11:37:15Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1327518|Enable thumb.wikimedia.org on cswiki and fawiki (T427465)]] (duration: 10m 40s)

Change #1328542 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/mediawiki-config@master] Expose the new thumbnail endpoint on dewiki

https://gerrit.wikimedia.org/r/1328542

Change #1328542 merged by jenkins-bot:

[operations/mediawiki-config@master] Expose the new thumbnail endpoint on dewiki

https://gerrit.wikimedia.org/r/1328542

Mentioned in SAL (#wikimedia-operations) [2026-08-24T11:42:16Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1328542|Expose the new thumbnail endpoint on dewiki (T427465)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-24T11:48:18Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1328542|Expose the new thumbnail endpoint on dewiki (T427465)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-24T11:57:51Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1328542|Expose the new thumbnail endpoint on dewiki (T427465)]] (duration: 15m 34s)

Change #1329564 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/mediawiki-config@master] Switch eswiki to thumb.wikimedia.org

https://gerrit.wikimedia.org/r/1329564

Change #1329564 merged by jenkins-bot:

[operations/mediawiki-config@master] Switch eswiki to thumb.wikimedia.org

https://gerrit.wikimedia.org/r/1329564

Mentioned in SAL (#wikimedia-operations) [2026-08-26T14:07:44Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1329564|Switch eswiki to thumb.wikimedia.org (T427465)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-26T14:10:18Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1329564|Switch eswiki to thumb.wikimedia.org (T427465)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-26T14:17:55Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1329564|Switch eswiki to thumb.wikimedia.org (T427465)]] (duration: 10m 11s)

Proposal for next week's tech news.

URLs to thumbnails is changing. The domain of URLs is changing from upload.wikimedia.org to thumb.wikimedia.org. The old URLs will continue to work for the foreseeable future but MediaWiki will adversative the new domain instead. URLs to other types of media such as original files, videos and transcodes will still be served from upload.wikimedia.org

I'm planning to push it to all wikis except enwiki next week.

Proposal for next week's tech news.

URLs to thumbnails are changing. The domain of URLs is changing from upload.wikimedia.org to thumb.wikimedia.org. The old URLs will continue to work for the foreseeable future but MediaWiki will advertise the new domain instead. URLs to other types of media such as original files, videos and transcodes will still be served from upload.wikimedia.org

I'm planning to push it to all wikis except enwiki next week.

drive-by grammar pedantry [edited inline]

@Ladsgroup @MatthewVernon thank you, I wrote it as:

"The domain of URLs is changing from upload.wikimedia.org to thumb.wikimedia.org. The old URLs will continue to work for the foreseeable future but MediaWiki will advertise the new domain instead. URLs to other types of media such as original files, videos and transcodes will still be served from upload.wikimedia.org."

In case you want to make further changes, please edit the entry on Meta directly: https://meta.wikimedia.org/wiki/Tech/News/2026/36.

I made a tiny change to make it clear url of thumbnails are changing. Not all urls.

Also, Since we have deployed to dewiki. One gadget broke, called direct link to commons because it has a regex hard-coded for upload.wikimedia.org. I have fixed it in dewiki and eswiki (before deploying the change there). Global search says there are around 80 places that need updating, I'll work on that.

Change #1330491 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/mediawiki-config@master] Switch jawiki, zhwiki and ptwiki to thumb.wikimedia.org

https://gerrit.wikimedia.org/r/1330491

Change #1330491 merged by jenkins-bot:

[operations/mediawiki-config@master] Switch jawiki, zhwiki and ptwiki to thumb.wikimedia.org

https://gerrit.wikimedia.org/r/1330491

Mentioned in SAL (#wikimedia-operations) [2026-08-27T15:51:42Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1330491|Switch jawiki, zhwiki and ptwiki to thumb.wikimedia.org (T427465)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-27T15:55:57Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1330491|Switch jawiki, zhwiki and ptwiki to thumb.wikimedia.org (T427465)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-27T16:02:29Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1330491|Switch jawiki, zhwiki and ptwiki to thumb.wikimedia.org (T427465)]] (duration: 10m 47s)

Change #1332748 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/mediawiki-config@master] Enable thumb.wikimedia.org everywhere except enwiki

https://gerrit.wikimedia.org/r/1332748

Change #1332748 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable thumb.wikimedia.org everywhere except enwiki

https://gerrit.wikimedia.org/r/1332748

Mentioned in SAL (#wikimedia-operations) [2026-08-31T18:08:19Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1332748|Enable thumb.wikimedia.org everywhere except enwiki (T427465)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-31T18:12:52Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1332748|Enable thumb.wikimedia.org everywhere except enwiki (T427465)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-31T18:20:13Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1332748|Enable thumb.wikimedia.org everywhere except enwiki (T427465)]] (duration: 11m 53s)

Why has this change been implemented before giving enough time to the community to fix critical tools that might get broken by this switch?? The TechNews hasn't even freaking gone out yet.

Wikisource's fairly critical OCR tool appears to be broken per T436551 as a result of this.

We have done gradual roll out and given that the old urls still work, the vast majority of tools should still continue with no problem. Even with those, I have identified a couple of tools and fixed them proactively (like direct commons gadget in many wikis) before rolling out. Of course, we might miss something while checking. Is there anything beside OCR tool broken?

Looking at this T427465, it seems the cause is the thumbnail domain migration from upload.wikimedia.org to thumb.wikimedia.org which was enabled on most wikis today. The Wikimedia OCR tool only allows image URLs from upload.wikimedia.org and the beta domain so it now rejects the new thumb.wikimedia.org URLs. The fix would be to add thumb.wikimedia.org to the allowed image domains in the OCR tool.

Is there anything beside OCR tool broken?

I'll keep searching; nothing yet. As a volunteer, as a rule of thumb, I'd like to avoid having to be in "search for, report, and fix UBNs right now" mode every time something in this area of the product stack changes. I don't get why sending out a notification at least a week in advance was this hard; this pattern occurred during the thumbnail migration changes as well.

CentralNotice admins are using fixed upload.wikimedia.org thumbnail links in their banners. If I understand correctly, these will not break when you move the links to thumbnails.wikimedia.org , right? But do you want us to use thumbnails.wikimedia.org instead (e.g., for performance reasons)? (We usually copy and paste the URLs from Commons itself, where it is annoying to remove the additional paraments that were set recently.) Then a message to centralnotice-admins@lists.wikimedia.org would make sense to make CNA's aware of this change and adapt their standard processes.

CentralNotice admins are using fixed upload.wikimedia.org thumbnail links in their banners. If I understand correctly, these will not break when you move the links to thumbnails.wikimedia.org , right?

That is correct. They will continue to work.

But do you want us to use thumbnails.wikimedia.org instead (e.g., for performance reasons)?

Yeah, it's better to use thumb now but I wanted to wait a bit before that, just to allow us to expand text cluster (and shrink upload) but it's on the plan

(We usually copy and paste the URLs from Commons itself, where it is annoying to remove the additional paraments that were set recently.) Then a message to centralnotice-admins@lists.wikimedia.org would make sense to make CNA's aware of this change and adapt their standard processes.

Will do.

Hi Lads. and lads ;-)

Direct link to commons

Also, Since we have deployed to dewiki. One gadget broke, called direct link to commons because it has a regex hard-coded for upload.wikimedia.org. I have fixed it in dewiki and eswiki (before deploying the change there). Global search says there are around 80 places that need updating, I'll work on that.

I moved the Direct links gadget to meta in case someone want to replace the tens of implementation we seem to have on various wikis. (I alread replaced local impl on plwiki with mw.loader.load from meta)

What goes where exactly?

Anyway, on another topic – I was wondering if there is some rule of what is kept on //upload and what is redirected to //thumb? I seem to get mixed results.

Is everything reachable on both domains? Some images from //thumb seem not to load for me, but I'm not sure if that are some internet provider problems on my side.

Should all scaled down images eventually be served by from //thumb or just the small ones? Is there a specific size that triggers redirects?

E.g. this doesn't seem to redirect even if technically, by URL structure, it is a thumb.

obraz.png (824×215 px, 167 KB)

Example from:
https://en.wikipedia.org/wiki/Main_Page#/media/File:Laguna_Miscanti_(Antofagasta,_Chile)_03.jpg
Or is that lack of redirect just a temporary cache thing?

Hi Lads. and lads ;-)

Direct link to commons

Also, Since we have deployed to dewiki. One gadget broke, called direct link to commons because it has a regex hard-coded for upload.wikimedia.org. I have fixed it in dewiki and eswiki (before deploying the change there). Global search says there are around 80 places that need updating, I'll work on that.

I moved the Direct links gadget to meta in case someone want to replace the tens of implementation we seem to have on various wikis. (I alread replaced local impl on plwiki with mw.loader.load from meta)

Thanks!

What goes where exactly?

Anyway, on another topic – I was wondering if there is some rule of what is kept on //upload and what is redirected to //thumb? I seem to get mixed results.

All thumbnails (note the /thumb/ in the URI path) will be moved to thumb.wikimedia.org, the path stays the same but just the domain changes.

Originals (which are still images) will be still served from upload.

So https://upload.wikimedia.org/wikipedia/commons/thumb/7/7d/Laguna_Miscanti_%28Antofagasta%2C_Chile%29_03.jpg/120px-Laguna_Miscanti_%28Antofagasta%2C_Chile%29_03.jpg will switch to https://thumb.wikimedia.org/wikipedia/commons/thumb/7/7d/Laguna_Miscanti_%28Antofagasta%2C_Chile%29_03.jpg/120px-Laguna_Miscanti_%28Antofagasta%2C_Chile%29_03.jpg

But the original itself won't change: https://upload.wikimedia.org/wikipedia/commons/7/7d/Laguna_Miscanti_%28Antofagasta%2C_Chile%29_03.jpg

Is everything reachable on both domains? Some images from //thumb seem not to load for me, but I'm not sure if that are some internet provider problems on my side.

Non-thumbnails (original, videos, etc.) can't be served from the new domain, so https://thumb.wikimedia.org/wikipedia/commons/7/7d/Laguna_Miscanti_%28Antofagasta%2C_Chile%29_03.jpg won't work. But the other way around still functions (thumbnails being served from upload.wikimedia.org), we will eventually start to issue 301 redirect responses directing browsers to hit thumb.wikimedia.org but that's not for now.

Should all scaled down images eventually be served by from //thumb or just the small ones? Is there a specific size that triggers redirects?

I hope I answered your question above but the size doesn't have any say on whether it's being served from upload or thumb. We have originals that are tiny and thumbnails that are large.

E.g. this doesn't seem to redirect even if technically, by URL structure, it is a thumb.

obraz.png (824×215 px, 167 KB)

Example from:
https://en.wikipedia.org/wiki/Main_Page#/media/File:Laguna_Miscanti_(Antofagasta,_Chile)_03.jpg
Or is that lack of redirect just a temporary cache thing?

We haven't deployed to enwiki yet. That'll come next week and even if we do, it'll take a while for the caches to expire.

Change #1327104 merged by Ladsgroup:

[operations/puppet@production] swift: Also accept thumb.wikimedia.org in ensure_max_mage

https://gerrit.wikimedia.org/r/1327104

Change #1337379 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/mediawiki-config@master] Enable thumb.wikimedia.org everywhere

https://gerrit.wikimedia.org/r/1337379

Change #1337379 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable thumb.wikimedia.org everywhere

https://gerrit.wikimedia.org/r/1337379

Mentioned in SAL (#wikimedia-operations) [2026-09-07T09:42:24Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1337379|Enable thumb.wikimedia.org everywhere (T427465)]]

Mentioned in SAL (#wikimedia-operations) [2026-09-07T09:46:56Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1337379|Enable thumb.wikimedia.org everywhere (T427465)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-09-07T09:52:36Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1337379|Enable thumb.wikimedia.org everywhere (T427465)]] (duration: 10m 11s)

Just a question. The new bug from the last week that does not allow opening new versions of svg files has something to do with this task? For example, clicking on the first thumbnail at this file opens the previous image. Tried Ctrl-F5 and deleting browser cache, on many browsers and different devices. Looks dependable on the IP, somehow. There is a chance that's the problem is on my side, of course, but I couldn't check this.

I admit I didn't understand the problem very well but I purged the page which should get rid of all thumbnails and force a regeneration of them. It could be also the missing purge from CDN which is a different bug altogether: T425216: Varnish serving outdated version at original/non-thumb URL of overwritten file upload

I admit I didn't understand the problem very well but I purged the page which should get rid of all thumbnails and force a regeneration of them. It could be also the missing purge from CDN which is a different bug altogether: T425216: Varnish serving outdated version at original/non-thumb URL of overwritten file upload

Thank you. Sorry for failing to explain, this is exactly the problem.

Change #1341936 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Fix thumb.wm.o normalization to match upload.wm.o

https://gerrit.wikimedia.org/r/1341936

Change #1352896 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[operations/puppet@production] [Proposal] varnish: Tighten rate limit on upload cluster

https://gerrit.wikimedia.org/r/1352896