Use `_prime_post_caches` for speeding up cached `get_pages` call

[david.binda]

The get_pages function uses a cache containing ID of pages matching params of a previous call.

The IDs are, on a subsequent call with the same params, inflated using the get_post function call. This works well in terms of the same request, as all the pages were previously added to the in-memory cache.

However, on a subsequent request, when the cache is hit, there are likely no pages already in the in-memory cache, and those need to be fetched from the backend cache server, one by one.

With the new wp_cache_get_multiple, sites with persistent cache backend could improve the speed in such cases, in case the code used the _prime_post_caches (which internally uses the _get_non_cached_ids function, which is taking advantage of the mentioned wp_cache_get_multiple).

But also sites without a persistent cache backend could benefit from the bulk SQL query constructed by the _prime_post_caches function, instead of fetching each page via individual SQL query.

The performance gains should be most noticeable in case a site has a lot of pages which are being requested via get_pages function.

IMHO, a _prime_post_caches( $cache, false, false ); should be used to match the behaviour of the get_pages function when the pages are obtained from the database (thus, no post meta, nor taxonomies priming).

[david.binda]

But also sites without a persistent cache backend could benefit from the bulk SQL query constructed by the _prime_post_caches function, instead of fetching each page via individual SQL query.

This does not apply, as the initial wp_cache_get on a subsequent request on a site without persistent object cache backend would not get anything.

But, IHMO, the rest of the report still applies for sites with persistent object cache backend :)

[hellofromTonya]

Next steps for this ticket (from core scrub):

Sergey will "confirm the initial issue and verify that the patch does fix it as expected."

Adding needs-testing to test for the performance gains:

From Sergey:

Would be great to confirm the performance improvements, looks good to go otherwise

Steps to test the performance improvements:

1. Use a persistent object cache (Redis or Memcached).
2. Have a site with a lot of pages.
3. Go to the the Pages screen (since it uses the get_pages() function being patched here) and measure the response time (TTFB, time to first byte).
4. Apply the patch and see if there's any improvement.

[hellofromTonya]

Tomorrow is 5.7 Beta 1. We've run out of time for this ticket in this cycle. Punting to 5.8.

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[hellofromTonya]

This ticket is flagged for performance manual testing. Comment 5 has the step-by-step process to do this testing. Marking the ticket ready for testing, i.e. via the combination of keywords: has-patch needs-testing has-testing-info

[SergeyBiryukov]

I did not get around to testing the patch per the steps in comment:5, but it looks straightforward enough and I don't see any downsides at a glance, so let's go with it :)

[SergeyBiryukov]

In 51018:

Posts, Post Types: Speed cached get_pages() calls.

This improves performance for sites with persistent cache backend having a lot of pages requested via the get_pages() function, by taking advantage of wp_cache_get_multiple()` instead of fetching each individual page from the backend cache server one by one.

It also matches the behaviour of get_pages() when the pages are retrieved from the database.

Props david.binda, hellofromTonya.
Fixes #51469.