[wp-trac] [WordPress Trac] #45140: REST API: Increase upper bound allowed on per_page argument

[WordPress Trac]

#45140: REST API: Increase upper bound allowed on per_page argument
------------------------------------------+--------------------------
 Reporter:  danielbachhuber               |       Owner:  (none)
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  5.0
Component:  REST API                      |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  performance
------------------------------------------+--------------------------
Description changed by danielbachhuber:

Old description:

> In contexts where a REST API client needs to fetch ''all'' entries for a
> resource, it would be more practical to fetch entries in sets of 200,
> 300, or 400, instead of sets of 100. Fetching entries in sets of 100 can
> cause excessive memory usage because WordPress is loaded over and over
> again. Increasing the limit will provide a better balance between memory
> consumption in a single request vs. total memory consumption across all
> requests.
>
> The original `per_page=100` limit was [https://github.com/WP-API/WP-
> API/issues/1609#issuecomment-177169125 somewhat arbitrary]; if I recall
> correctly, we picked `100` as a nice round number that was reasonably
> certain not to cause performance issues.
>
> Before we pick `per_page=200` vs. `per_page=300` vs. `per_page=400`, we
> should:
>
> 1. Profile memory consumption of each.
> 2. Identify what amount of memory we can reasonably expect on shared
> hosting these days.
>
> After we've done this, we can pick the best available option.
>
> Notably, we can't go above `500` as we'll hit `split_the_query` which has
> negative performance implications.

New description:

 In contexts where a REST API client needs to fetch ''all'' entries for a
 resource, it would be more practical to fetch entries in sets of 200, 300,
 or 400, instead of sets of 100. Fetching entries in sets of 100 can cause
 excessive memory usage because WordPress is loaded over and over again.
 Increasing the limit will provide a better balance between memory
 consumption in a single request vs. total memory consumption across all
 requests.

 The original `per_page=100` limit was [https://github.com/WP-API/WP-
 API/issues/1609#issuecomment-177169125 somewhat arbitrary]; if I recall
 correctly, we picked `100` as a nice round number that was reasonably
 certain not to cause performance issues.

 Before we pick `per_page=200` vs. `per_page=300` vs. `per_page=400`, we
 should:

 1. Profile memory consumption of each.
 2. Identify what amount of memory we can reasonably expect on shared
 hosting these days.

 After we've done this, we can pick the best available option.

 Notably, we can't go above `500` as we'll hit `split_the_query` which has
 negative performance implications.

 Previously https://github.com/WordPress/gutenberg/issues/6694

--

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