Page MenuHomePhabricator

[Caching] Does Wikibase Suite require different caching setting?
Open, MediumPublicSpike

Description

Current Situation:

Use case: When creating a new property it will not be displayed on the list of properties instantly - only after two hours (Wikidata default value for caching)

We have identified that wikibase suite has the same cache config as wikidata i.e. conservative in the sense that Wikidata is a huge system (very technical and concrete term, I am aware). Basically the changes in some values take an hour to be recached so that the users won't see some of the changes they make until after an hour. That can lead to confusion and a lot of frustration for our users.

The installation of our users' are usually smaller than wikidata and need more responsiveness. We need to rethink which are the more concrete cache needs of our users and adapt the wikibase suite to those. Without having a lot more information we could easily start working with the assumption that wbSuite needs a faster cache, which is surely true in any case, and adapt it already. The config we set can be a try - then we ask our users whether other changes are needed.

Cache setting: https://github.com/wmde/wikibase-release-pipeline/blob/2546eda71809c6ebb504182ea9b7046f4a67245b/test/suites/repo/LocalSettings.php#L6

Goal:

  • wbSuite cache config is adapted to our users' needs

Acceptance Criteria:

  • Questions:
  • What are the dependencies when changing the cache setting?

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptNov 8 2023, 11:12 AM

Among other considerations look into the setting for $wgWBRepoSettings['sharedCacheDuration'] in LocalSettings.php as per https://phabricator.wikimedia.org/T349718 and https://github.com/wmde/wikibase-release-pipeline/pull/493

I don't think this is a duplicate of anything here, @Pytagora222 maybe this was tagged by mistake?

hey @roti_WMDE (and/or whomever else would like to reply) two questions:

  1. I'm wondering about whether this can be solved by making the config more accessible? then we could take a bet on a sensible cache but trust users to config it to their own needs.
  1. in terms of informing people's needs I'm wondering about doing a benchmark of the performance implications of different cache settings. thoughts on how much work that might be?
Leif_WMDE renamed this task from Does Wikibase Suite need similar performance optimizations as Wikidata? to [Caching] Does Wikibase Suite require different caching setting?.Aug 15 2025, 10:00 AM
Leif_WMDE triaged this task as Medium priority.
Leif_WMDE updated the task description. (Show Details)

Just a thought, as I see this moving around.

Indeed this is based on the shared cache key value, https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/WikibaseRepo.ServiceWiring.php#L1661
as it comes from the property info store https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/includes/Specials/SpecialListProperties.php#L238-L248

Interestingly wikibase.cloud actually just has this cache disabled by default
https://github.com/wbstack/mediawiki/blob/171b4509d050e2ab99a850bcecd5aaf2939ea8a0/dist-persist/wbstack/src/Settings/LocalSettings.php#L615-L616

Wikidata has this set to 1 day https://github.com/wikimedia/operations-mediawiki-config/blob/f08c3f6781d9d637be0c3533d325d51788b2ba27/wmf-config/Wikibase.php#L175

So, the same issue arises for all wikibases, not just suite.
I wonder what the desired behaviour would be from the user side?

This has been a topic for some time, and T285653: Provide information about Wikibase caches for external identifiers & formatter property URLs touched on documenting the status of this for all wikibase users. (Though I'm not sure if T289342: Add cache info to Advanced Config doc ever actually put that info somewhere...
This ultimately is the same caching issue as T364744: "formatter url" feature does not work for all properties on Wikibase, despite mapping set. And in the early days this was surfaced multiple times on Wikibase Cloud /wbstack
This also strongly relates to T112081: [Story] purge cached renderings of IDs when the formatter URL changes which would likely change this caching behavior in order to fix it