Page MenuHomePhabricator

Performance audit of Wikibase/Wikidata, Jan 2020
Closed, ResolvedPublic

Description

After the outage of T243713: Time-out error; Babel/WikibaseRepo being somehow uncached, overloading the API, and causing general outage caused by T243725: HtmlPageLinkRendererBeginHookHandler creates a LanguageFallbackChain when it may not be needed, it would be a good to audit common bits of Wikibase/Wikidata to find some more performance bottlenecks avoiding issues in the future.

Some common parts are:

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Non-Wikibase bits that look weird:

  • After each purge or edit, EventBus does two MultiHttpClient::runMultiCurl (an example). This is the longest part of most of these requests: https://performance.wikimedia.org/xhgui/run/view?id=5e31d1b03f3dfaaf2d6bf636
  • The biggest memory hog in parsing a page with lots of lua is not the lua or the parser, it's Liuggio\StatsdClient\StatsdClient::doReduce. One example says 86MB (77% of total memory usage)
  • A lot of rendering pages in client is loading the sites table, here's an example. I guess T113034 and migrating the sites to a better cache would help.
  • Extensions Registry is really slow. Specially trying to call redis.
  • AtEase could be used and make things faster specially in DB Queries.
  • API responses spend interesting amount of time in Site::unserialize and UtfNormal\Validator::cleanUp

I think everything in the description really needs to be split into a sub ticket so that conversation in here doesn't get very messy.

I think everything in the description really needs to be split into a sub ticket so that conversation in here doesn't get very messy.

Done

Addshore claimed this task.

Should we call this done?

Yes, lets.
Leaving the subtasks open though that were created as a result of this