You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 24, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 24, 2018. It is now read-only.
Increasing per_page scales poorly due to WP_REST_Posts_Controller::get_item_schema calls #2558
Whilst profiling our application, I found that as you increase per_page on a posts request there is a subsequent rise in get_item_schema calls. These calls are quite intensive (particularly if there is extra schema being added in a custom post type).
Here are some stats from kcachegrind showing that the inclusive cost of get_item_schema() calls trends upwards without caching, but with caching the inclusive cost is lower, and trends sharply downwards as per_page increases. The effect of caching is also significant increase in the speed of the overall HTTP request.
without schema caching:
per_page incl self called (overall time to run 5x http requests as reported by curl)
10 24.74 6.67 278 (3.577)
20 31.15 8.65 528 (5.701)
30 33.23 9.51 778 (7.199)
40 34.70 10.61 1028 (8.671)
100 37.85 10.80 2528 (18.925)
with schema caching:
per_page incl self called (overall time to run 5x http requests as reported by curl)
10 2.57 0.22 278 (2.899)
20 1.39 0.18 528 (3.946)
30 0.87 0.13 778 (4.887)
40 0.17 0.10 1028 (6.239)
100 0.28 0.04 2538 (12.072)
Here is the code that did the caching from a subclass:
private $schema;
public function get_item_schema() {
if ($this->schema) {
return $this->schema;
}
$this->schema = parent::get_item_schema();
return $this->schema;
}
Hi,
Whilst profiling our application, I found that as you increase per_page on a posts request there is a subsequent rise in get_item_schema calls. These calls are quite intensive (particularly if there is extra schema being added in a custom post type).
Here are some stats from kcachegrind showing that the inclusive cost of get_item_schema() calls trends upwards without caching, but with caching the inclusive cost is lower, and trends sharply downwards as per_page increases. The effect of caching is also significant increase in the speed of the overall HTTP request.
Here is the code that did the caching from a subclass: