After the outage of {T243713} caused by {T243725}, 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:
[] [[https://performance.wikimedia.org/xhgui/run/callgraph?id=5e30a7403f3dfa0d2bf6b337|Rendering an item]]
[] {T243912}
[] Rendering a lexeme ([[https://performance.wikimedia.org/xhgui/run/view?id=5e31cce33f3dfab42d1acc21|Part I]], [[https://performance.wikimedia.org/xhgui/run/view?id=5e31cce53f3dfab22dac0d0a|Part II]])
[] Spent 52% of the time in AutoLoader::autolaod(). (Also memory-wise it's super big) PSR-4 would fix lots of issues there: {T172368}
[x] [[https://performance.wikimedia.org/xhgui/run/view?id=5e31cffb3f3dfab52dd153e9|Rendering a file page in Commons]]
- Nothing out of ordinary
[] Rendering a non-entity page in a repo (whether it uses data or not)
- [[https://performance.wikimedia.org/xhgui/run/view?id=5e31d1ba3f3dfab22d4d158a|Using lua]], [[https://performance.wikimedia.org/xhgui/run/symbol?id=5e31d1ba3f3dfab22d4d158a&symbol=WANObjectCache%3A%3AgetWithSetCallback|there's 1823 calls to memcached]] from `Wikibase\Lib\Store\CachingPropertyInfoLookup::getPropertyInfoFromWANCache` That might be something worth looking into, might not.
- For a [[https://commons.wikimedia.org/wiki/Category:Philosophers_by_century|simple page that doesn't use much data]]: `Wikibase\Lib\Formatters\SnakFormat::getFallbackChain` is being called [[https://performance.wikimedia.org/xhgui/run/symbol?id=5e31d8003f3dfab32ddd8e34&symbol=Wikibase%5CLib%5CFormatters%5CSnakFormat%3A%3AgetFallbackChain|9000 times]], that doesn't make much sense. Maybe already tracked?
- On main page of Commons, the biggest Wikibase usage comes from `Wikibase\Repo\WikibaseRepo::getDefaultEntityTypes` with 84 *micro*seconds, I guess nothing to do there.
[] Special:EntityData
- [[https://performance.wikimedia.org/xhgui/run/view?id=5e31dade3f3dfab22d97075e|JSON]]
- Spends interesting amount of time in `Site::unserialize` and `UtfNormal\Validator::cleanUp` (these are the biggest ones after reading from memcached).
- There's 300 calls to `Wikibase\Lib\Store\CachingPropertyInfoLookup::getPropertyInfoFromWANCache`. A JSON representation of an item should not need property info. Right? That's 30% of the total time to handle the request.
- [[https://performance.wikimedia.org/xhgui/run/view?id=5e31dfb93f3dfab12dff839f|RDF]]
- [[https://performance.wikimedia.org/xhgui/run/symbol?id=5e31dfb93f3dfab12dff839f&symbol=Wikibase%5CRdf%5CRdfBuilder%3A%3AresolveMentionedEntities|Tries to load 225 entities]] from the database (all of the entities being used) in `Wikibase\Rdf\RdfBuilder::resolveMentionedEntities`. The most of time and memory handling the request belong to this. (why do we load all of entities, do we need all of them for RDF????)
[] Rendering an page in client that uses Wikidata's data. ([[https://performance.wikimedia.org/xhgui/run/view?id=5e31e1103f3dfab42d8f558c | Part I]], [[https://performance.wikimedia.org/xhgui/run/view?id=5e31e1153f3dfab62d2f37db|Part II]])
- There's strange number of PropertyId and ItemId objects being created and in any of them we have EntityId::splitSerialization, PropertyId::assertValidIdFormat, EntityId::joinSerialization they sum up to a significant amount of time. If the objects could be reused, it would be a pretty low hanging fruit, `Wikibase\DataModel\Snak\PropertyValueSnak::unserialize ` creates lots of them [[https://performance.wikimedia.org/xhgui/run/symbol?id=5e31e1153f3dfab62d2f37db&symbol=Wikibase%5CDataModel%5CEntity%5CPropertyId%3A%3A__construct|an example]]
[] api.php in Wikidata
- Nothing out of ordinary.
[] load.php in Wikidata ([[https://performance.wikimedia.org/xhgui/run/view?id=5e31e64c3f3dfab52d428f61|Part I]], [[https://performance.wikimedia.org/xhgui/run/view?id=5e31e64a3f3dfab22dab7a23|Part II]])
- Nothing out of ordinary, Wikibase-side.