In order to be able to decide how well mobileapps performs and decide how we move forward we need a baseline of metrics to compare the RESTBase based setup and the architecture without RESTBase
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T324931 Clean up open RESTBase related tickets | |||
| In Progress | None | T262315 <CORE TECHNOLOGY> API Migration & RESTbase Sunset | |||
| Stalled | Dbrant | T328943 Replace PCS lazy-loading logic with standard "loading=lazy" attribute | |||
| Open | None | T314025 [EPIC] Migrate PCS service away from restbase | |||
| Resolved | Jgiannelos | T314768 [spike] Performance benchmarking of mobileapps without RESTBase | |||
| Resolved | Jgiannelos | T314781 Perfomance baseline metrics for mobileapps |
Event Timeline
Comment Actions
We gathered some metrics of various different scenarios here:
https://miro.com/app/board/uXjVOhJ1adw=/?moveToWidget=3458764533207672741&cot=14
Some key takeaways are the following:
- Parsoid latency served via core page html endpoint is in the same order of magnitude compared to parsoid latency when served via restbase
- That assumes that parsercache is hot enough when corepage html serves content
- Parsoid core page html latency is around 2x the latency of parsoid on restbase
- We know the overhead of serving API endpoints from core and some known mitigations
- eg. Having a maintenance script pooling connections to serve faster responses without the overhead of loading mw on each request
- PCS is designed with storage/caching/pregeneration in mind which means that API responses are slow (p90 > 2s)
Comment Actions
There are some more related metrics extracted from the cache level here:
https://phabricator.wikimedia.org/T319365#8285517