User talk:Mike Peel

MediaWiki message delivery 18:51, 9 March 2026 (UTC)

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we talk about the revamp of the composition language on Wikifunctions, with its potential for further improvements.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 16:18, 12 March 2026 (UTC)

This is the 4th issue of our monthly newsletter! The next issue will be published in April 2026.

• Team communication update: Since November, our small and newly formed team has been developing our approach to sharing our work with the community and incorporating feedback. Migrating Wikidata Query Service’s infrastructure is a large and complex undertaking that serves many different audiences. Our goal has been to find the right mix of channels, engagement levels, and response times that allows us to reach the broadest possible audience with the resources we have.

Now that we have more of this structure in place, we are sharing project updates through regular newsletters and publishing reports and learnings on-wiki, where discussion pages are open for questions and comments. Our Phabricator board is available for flagging bugs or engaging in ongoing tasks. We also host regular office hours as a shared space for community members to raise questions and topics that may be relevant to others as well (next is in April). Questions added to the Etherpad will be addressed during those sessions.

The team reviews feedback shared through these channels and incorporates it where it helps advance our migration goals. While we aim to respond to questions within about a week when possible, we may not be able to reply to every individual point.

• Label and MWApi service migration : We’ve completed an analysis of the wikibase:label and wikibase:mwapi services. One or both of these services are used in more than half of the requests sent to the Wikidata main graph. Preserving the functionality of these features is a core requirement of our backend migration away from Blazegraph. Full results of this investigation can be found on Wikitech.
• Rate limits: Global rate limits for Wikimedia Foundation APIs were announced on March 2 and will be rolled out over the next month. These limits do not currently apply to WDQS, as we are still evaluating appropriate rate limits for our platform as part of our backend migration (ETA: July ‘26). In the interim, to protect against service interruptions like the ones observed during the week of February 23 following an increase in request volume and complexity, we have rate-limited a handful of identified users whose requests gridlocked our system. While details regarding specific actors have not been publicly disclosed (PII is involved) Wikimedia SRE deployed a workaround to a known Blazegraph bug that manifests under traffic spikes (T242453). While this does not solve the root cause of the problem, we expect it to increase WDQS reliability in the short term. We will continue to implement these spot fixes as needed until a more scalable solution is determined.
• Work in progress: traffic analytics and operations: In the February sprint, we dedicated time to improving analytics on traffic and query behavior, with a particular focus on query latency classes and volumes by user-agent. This work provides two main benefits: 1) it informs different access patterns and latency-bound quality-of-service considerations, and 2) it led to short-term improvements in the real-time metrics we use to operate WDQS. We introduced new panels in Grafana, as well as internal-facing analytics tools, to report error rates and latency buckets, as well as new alerts that trigger on trends indicating timeouts. This approach allows us, on one hand, to proactively react to traffic spikes before an outage impacts end users, and on the other hand, to define the observability requirements that our new target backend will need to meet.
• Work in progress: development and test infrastructure: In our previous newsletter, we published exploratory benchmarking that identified two candidate systems for Blazegraph replacement that met minimum requirements. The purpose was to gain experience with open source triple store implementations as we embark on the migration. Building on these learnings, one of our goals this quarter is to deploy test instances of Virtuoso and QLever on internal eqiad infrastructure, to gain experience operating both systems and supporting internal development efforts (T414443). We have now 4 hosts that serve main and scholarly data via QLever and Virtuoso (respectively). This work informed improvement ideas for our data infrastructure, and allowed us to refine our understanding of indexing times on graph splits. As part of this work, we modified the real-time index updater code base to remove hard dependencies on Blazegraph. While this is a work in progress, we can now update both QLever and Virtuoso indexes in real-time while reusing existing WDQS infrastructure (T414447). This allows us to experiment and load test traffic on infrastructure similar to Blazegraph-based WDQS, and is a milestone towards exposing a new backend to public traffic later this year. If you have experience operating Wikidata triple stores at scale, we would like to get in touch and exchange learnings.

Udehb-WMF (talk) 17:07, 12 March 2026 (UTC)