[wp-trac] [WordPress Trac] #48838: Consider "caching" embedded REST API requests

[WordPress Trac]

#48838: Consider "caching" embedded REST API requests
---------------------------------------------+-----------------------------
 Reporter:  TimothyBlynJacobs                |       Owner:
                                             |  TimothyBlynJacobs
     Type:  enhancement                      |      Status:  assigned
 Priority:  normal                           |   Milestone:  Awaiting
                                             |  Review
Component:  REST API                         |     Version:  4.4
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch has-unit-tests commit  |     Focuses:  performance
---------------------------------------------+-----------------------------
Changes (by kadamwhite):

 * keywords:  has-patch has-unit-tests 2nd-opinion => has-patch has-unit-
     tests commit


Comment:

 This didn't show much benefit on a site with little data, but I tested
 this by setting up a staging environment with 10k posts and it quicky
 began to yield significant benefits. Methodology:

 - `wp post generate --count=10000 --post_author=admin`
 - Run 20 REST requests for `/wp-json/wp/v2/posts?per_page=100&_embed` and
 record response time

 This yielded an average response time of 8.738s on master, and 5.174s with
 this patch: a **40% improvement**.

 The likelihood of an enterprise-scale site only having posts by one user
 is low, so this should be seen as a hypothetical upper-boundary of
 performance gain this patch could yield. The reason for the variance is
 that on a vanilla WordPress site the only embeddable resource with a
 consistent-per-linked-resource link href is author; resources like terms
 will have a link specific to the post, such as `/wp-
 json/wp/v2/categories?post=7240`, which would miss our cache.

 However, in discussion with @TimothyBlynJacobs he mentioned that he's seen
 plugins use links which would have consistent href's but could be
 potentially costly to re-compute, as plugins usually make less consistent
 use of internal object caching and other best practices we try to follow
 in core. This implies that this patch would both benefit the long-tail of
 WP sites with little content but many plugins, as well as the smaller set
 of enterprise-scale sites with thousands of posts or users.

 Marking as `commit` as this appears to yield a real benefit in some
 situations, with no obvious downsides. Thanks Timothy!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48838#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform