Sam made a graph to show API utilisation https://grafana.wikimedia.org/dashboard/db/reading-web-page-previews?refresh=1m&orgId=1&panelId=15&fullscreen
We should probably abort these requests, in the client...right?
Note: Any optimizations we might do to the timeouts, we need to do without impacting time to preview. The pane https://grafana.wikimedia.org/dashboard/db/reading-web-page-previews?refresh=1m&panelId=6&fullscreen&orgId=1&from=now-2d&to=now
needs to stay around 700ms (see the other panes with TTP percentiles for more details).
Questions to answer
- Is the delay on page previews working as expected?
Yes, the delay works perfectly right, the AJAX requests to the summary endpoint are fired after 150ms.
- Are there any circumstances where an API query is occurring when it should not be?
We fire the AJAX call after each time a user dwells on the link. When a user leaves the link and no popup is shown we should abandon the request immediately. When the user leaves the link we wait for ABANDON_END_DELAY (which is currently 300ms) and then reset the state. The problem is that the FETCH_DELAY_START is smaller (only 150ms) - what usually happens, when PagePreviews are in state ABANDON_START (which means user left the link, do not show the popup) we still send the AJAX call, even if a user is already pointing on the other link.
- Is there any value in aborting requests?
Yes, there is always a value in aborting requests:
- from the user side - fewer data sent to the user
- from the service side - there is some value, but it will not make any considerable difference. 99% of summary requests are stored in varnish and never reach restbase. But for remaining 1% aborting request will reduce the server load (first restbase checks Cassandra cache, and if the summary is not present it calls MCS).
As a result of this SPIKE I created the T197700