Page MenuHomePhabricator

Retrieve page HTML directly from RESTbase
Closed, ResolvedPublic8 Estimated Story Points

Description

Retrieving the page HTML via api.php is probably inefficient. We've observed that the time to first byte is very high (over a second, sometimes two) and the time spent transmitting data very low (a few hundred milliseconds). Additionally, the API wraps the page HTML in a JSON blob which we then have to decode.

Instead, we should send two separate requests, one for the page HTML directly to RESTbase, and one for a JSON blob of auxiliary information to api.php.

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

Catrope claimed this task.
Catrope raised the priority of this task from to Needs Triage.
Catrope updated the task description. (Show Details)
Catrope added subscribers: GWicke, ori.

Blocked on RESTbase being fully deployed and reliable. We can't use parsoid-lb.eqiad.wikimedia.org for this in its current form because it doesn't serve CORS headers and appears to have no or nonfunctional caching (responses have X-Varnish headers, but they're always misses).

Catrope edited a custom field.

Do we have a restbase instance in labs to write code against?

Jdforrester-WMF moved this task from To Triage to Bug Fixes on the VisualEditor board.

@Krenair, see https://rest.wikimedia.org/en.wikipedia.org/v1/?doc. This went alpha-live on Friday & needs a little bit more testing, but will be officially ready this week.

See also:

Change 196720 had a related patch set uploaded (by Catrope):
[WIP] Send requests to RESTbase directly when so configured

https://gerrit.wikimedia.org/r/196720

Before we merge this we should have RESTbase in beta to test against, and preferably group1 wikis (which we've managed to skip deploying RESTbase config to, somehow). Probably needs separate tasks.

Before we merge this we should have RESTbase in beta to test against, and preferably group1 wikis (which we've managed to skip deploying RESTbase config to, somehow). Probably needs separate tasks.

T91102 is in the works, should be completed pretty soon.

Before we merge this we should have RESTbase in beta to test against, and preferably group1 wikis (which we've managed to skip deploying RESTbase config to, somehow). Probably needs separate tasks.

Group 1 deploy is tracked in T93452. There is a puppet patch for it already.

Change 196720 merged by jenkins-bot:
Send requests to RESTbase directly when so configured

https://gerrit.wikimedia.org/r/196720

Change 200098 had a related patch set uploaded (by Jforrester):
[WIP] Make VisualEditor access RESTbase directly

https://gerrit.wikimedia.org/r/200098

Change 200105 had a related patch set uploaded (by Jforrester):
Make VisualEditor access RESTbase directly on enwiki

https://gerrit.wikimedia.org/r/200105

Change 200106 had a related patch set uploaded (by Jforrester):
Make VisualEditor access RESTbase directly on Wikipedias

https://gerrit.wikimedia.org/r/200106

Change 200107 had a related patch set uploaded (by Jforrester):
Make VisualEditor access RESTbase directly on all wikis

https://gerrit.wikimedia.org/r/200107

Change 200098 merged by jenkins-bot:
Make VisualEditor access RESTbase directly in group0

https://gerrit.wikimedia.org/r/200098

Change 200105 merged by jenkins-bot:
Make VisualEditor access RESTbase directly on enwiki

https://gerrit.wikimedia.org/r/200105

Change 200105 merged by jenkins-bot:
Make VisualEditor access RESTbase directly on enwiki

https://gerrit.wikimedia.org/r/200105

yipikaye!

Change 200106 merged by jenkins-bot:
Make VisualEditor access RESTbase directly on Wikipedias

https://gerrit.wikimedia.org/r/200106

Request latency on enwiki looked great, but was really bad on other wikis. We rolled back the all-wikipedia change for this reason. See https://phabricator.wikimedia.org/T95229#1192818 for the details.