In WordPress 6.4, the Performance team has introduced several enhancements centered around object caching, leading to better handling of filters, reduced database queries, and improved overall system efficiency.
Change the position of notoptions lookup in get_option()
In the get_option() function, a cache lookup for the notoptions key is performed; this stores an array of keys for options known to not exist. This optimization prevents repeated database queries when certain options are requested. However, the cache lookup for notoptions was conducted before checking if the requested option exists in the cache. Given that it’s more likely that the option does exist, a change has been made to reorder the checks to first verify the option’s existence in the cache before confirming its absence. This adjustment reduces redundant queries and also eliminates an unnecessary cache lookup, improving overall performance.
Please refer to #58277 for additional details on these changes.
Improvements to WP_Query caching
Forcing split queries when object caching is enabled
WordPress introduced the ability to perform split queries starting from version 3.1. A split query occurs when the main query in WP_Query is executed to retrieve post IDs only, rather than retrieving the entire post objects. To populate the post objects, the function _prime_post_caches() is invoked, fetching the complete post information if it is not already loaded into local memory.
Before this change, split queries were restricted to posts numbering less than 500. However, this restriction has been eliminated when persistent/external object caching is enabled. This enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. becomes even more significant with the introduction of wp_cache_get_multiple() in WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. With this function, object caches can retrieve multiple objects in a single request, offering several benefits.
Benefits of Split Queries and Object Caching:
- Performance Improvement: Object caches, which store frequently accessed data in memory, are substantially faster than traditional database queries. By using split queries, WordPress can fetch post IDs more efficiently, reducing the load time for your website.
- Database Offloading: The implementation of split queries alleviates the strain on the database. With only the essential post IDs selected, less data needs to be retrieved from the database, and fewer database queries are executed.
- Primery Key Loading: The primary key for loading the post object is the focus, ensuring that the necessary data is efficiently fetched from the object cache.
In summary, the ability to perform split queries, combined with object caching, enhances WordPress’s performance and reduces the load on your database. By opting for split queries, you can enjoy faster loading times and a smoother user experience for your WordPress website.
Please refer to #57296 for additional details on these changes.
Fix caching behavior if filters are used in WP_Query
The WP_Query class in WordPress allows developers to customize queries using various filters such as posts_fields_request, posts_request, and the_posts. These filters are instrumental in modifying both the queried fields and retrieved post objects. However, there have been cases where the use of these filters could result in incomplete or invalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. post objects, lacking essential data. To address this issue and ensure data consistency and integrity, a change has been introduced.
In scenarios where the posts_fields_request, posts_request, or the_posts filters are active during a query, the get_posts() method now avoids caching post objects with the usual update_post_caches() function call. Instead, it opts for a call to _prime_post_caches(). This change is designed to prevent the caching of invalid post objects, prioritizing data consistency and integrity in filtered query scenarios.
While this enhancement ensures that invalid post objects are not cached, it may occasionally trigger new database queries to prime the post data cache. Developers should be aware that this might result in slightly increased database load in specific cases.
Please refer to #58599 for additional details on these changes.
Improved performance for WP_Query for id=>parents
In WordPress 6.2, a change was made to the WP_Query class (as documented in commit [53941]) which brought forth an unforeseen issue when querying to return fields id=>parent. This issue specifically affected websites with object caching enabled, especially when dealing with a substantial number of pages. During the second execution of this query, the _prime_post_caches() function for an id=>parent query was inadvertently triggered. This led to the unnecessary priming of post, meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., and term caches, even when the query only requested ID and parent information.
To address this problem and optimize query performance, a new function, _prime_post_parent_ids_caches(), has been introduced. This function is responsible for priming a dedicated cache for post parents during the initial query execution. Subsequently, the wp_cache_get_multiple() function is utilized to retrieve all post parent data in a single object cache request, ensuring a significant performance improvement. Post parent caches are invalidated when the clean_post_caches() function is called. If you are updating a post in the database, please ensure that this function is called after making this update.
Please refer to #59188 for additional details on these changes.
Improvements to WP_Term_Query caching
New cache_results parameter in WP_Term_Query
The cache_results parameter has been introduced in WordPress to provide developers with more control over the caching behavior in WP_Term_Query queries. It allows you to determine whether or not to load results from the query cache, enabling you to obtain a complete uncached result when set to false.
The cache_results parameter is a boolean parameter, and it accepts the following values:
- true (default): Load results from the query cache (cached results).
- false: Retrieve a complete uncached result.
This parameter is primarily designed for developers who are working on highly custom solutions and need to bypass caching mechanisms for specific queries. In most cases, it is recommended to keep the cache_results parameter enabled (set to true) in production environments. Caching is an essential performance optimization in WordPress, and disabling it may lead to slower query execution times.
In the example above, the cache_results parameter is set to false, ensuring that the query results are retrieved without using the cache.
$args = array(
'taxonomy' => 'category',
'cache_results' => false, // This will fetch uncached results
);
$term_query = new WP_Term_Query($args);
The cache_results parameter in WP_Term_Query offers flexibility for developers working on specialized projects. While it can be useful in certain scenarios, exercise caution when disabling caching, as it may impact performance in a production environment. Always consider the specific requirements of your project before deciding to disable query caching.
Please refer to #52710 for additional details on these changes.
Fix caching behavior if term_clauses filters are used
When utilizing the terms_clauses or get_terms_fields filters within WP_Term_Query and the selected fields are modified, the entire term object is now cached. This change was necessary because filters can broaden the selected fields beyond just the term ID. Fields linked to the term object, such as the count or parent, may undergo modifications when queried. Caching the complete object ensures the accurate storage of these modified fields within the cache.
Please refer to #58116 for additional details on these changes.
Props to @spacedmonkey for writing, @westonruter for editing.
Props to @joemcgill, @tillkruss, @flixos90 @webcommsat for review and proofreading.
#6-4, #dev-notes, #dev-notes-6-4, #performance
You must be logged in to post a comment.