Wikimedia recently started to show "Error creating thumbnail"

[HikeAndMap]

https://wiki.openstreetmap.org/wiki/Road_signs_in_the_Philippines/sign_lookup_table

I haven't seen this for many years, it's only recently this starts to come up..

[tomhughes]

Yes we know that there are issues with our crazy overuse of wikimedia commons images causing us to get rate limited and we are workign to resolve it - there are probably already ticket(s) for it.

[HikeAndMap]

Thank you

[1ec5]

I purged the page four times over four minutes until all the images showed up. Each time I purged the page, about 40 more images showed up and none regressed. I’ve heard mixed messages about whether this is a durable workaround and about whether it would have any adverse effects. Even after #1340, these images contribute to our server’s quota, but whether that’s a problem would depend whether our cache is working as intended. The Wikimedia Foundation’s SREs think it isn’t.

Long-term, I’d encourage the Philippine community to break up the page by sign category, maybe even more granularly than that. Each page could provide tagging details like what’s on “Road signs in the Philippines”. As the Philippine sign system is roughly based on the U.S. system, you can use the MUTCD pages as a model. (We probably need to break up some of those pages even further.)

Otherwise, a simple gallery of sign diagrams and their codes would be more relevant to Wikimedia Commons. Mappers in other countries are maintaining such galleries directly in the main namespace of Commons. Even there, your browser might get throttled as you request the images on the page, but that rate limit isn’t as severe. You can always ask your browser to load failed images individually, something you can’t do when server-to-server communication fails.

[HikeAndMap]

How about I host the images on my google drive? Is that workable?

[HikeAndMap]

German community clearly has the same issue

[1ec5]

I think this user is mistaken. This table includes both images, one after the other. As of writing, both of them are loading fine, probably because someone purged the page or made an edit at some point.

[julcnx]

I purged the page four times over four minutes until all the images showed up.
Long-term, I'd encourage the Philippine community to break up the page by sign category

Purging did not work for me either after multiple attempts, and splitting is not viable at this scale, a search for "Error creating thumbnail" on the OSM wiki returns over 15,000 affected pages:
https://wiki.openstreetmap.org/w/index.php?search=Error+creating+thumbnail%3A&title=Special%3ASearch&profile=default&fulltext=1

yes we know that there are issues with our crazy overuse of wikimedia commons images causing us to get rate limited and we are workign to resolve it - there are probably already ticket(s) for it.

Looking at the chef config for QuickInstantCommons.

Description and metadata cache expiry are set to 30 days but apiThumbCacheExpiry does not appear to be explicitly set. According to the MediaWiki docs, setting apiThumbCacheExpiry to a higher value reduces API call frequency on cache misses.

Has tuning that been considered as a way to reduce the rate limiting exposure?

[1ec5]

apiThumbCacheExpiry is set to 1 day by default. We used to set it to the same as descriptionCacheExpiry from openstreetmap/chef@e1d1e10 until we migrated to QuickInstantCommons in openstreetmap/chef@925707a. Might be worth a try. However, I’m not sure if this would cause errors to persist longer.

[1ec5]

openstreetmap/chef@6d6f47c