Performance Chat Agenda: 24 May 2022

Here is the agenda for this week’s performance team meeting scheduled for May 24, 2022, at 15:00 UTC.


This meeting happens in the #performance channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance team meeting summary 17 May 2022

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.
  • @furi3r: Add Site Health test for full page caching (advanced cache) #220 was moved to 1.2.0 is just about ready and waiting for testing

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • No updates

Feedback requested

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @shetheliving: Review the module proposal workflow and leave any feedback on the PR
    • @flixos90: We’ve been working on this to have a long-term plan for each module; want to avoid a module going into the plugin and growing stale without any iterations or next steps
    • @jeffpaul: I’ll review with an eye from the core perspective
    • @flixos90: Another benefit of this documentation is that it includes a high-level overview of how to propose a feature project for core, which isn’t really documented right now; this could be a good starting point for the future
  • @olliejones: Might be cool to have a stub performance-lab module for modification by would-be contributors
    • @flixos90: That’s a great idea, though there would be little to start with since a module can be pretty much anything. The best place to start right now is with the writing a module doc, though that’s more about the technical starting point and the new proposal doc is more about overall workflow.
  • @flixos90: Released v1.1.0 yesterday. Next release will be 1.2.0 on Monday, June 20, so we should target merge for anything for that release by about June 15.

Feedback requested

Open floor

  • @olliejones: Following up on the large site/many users work: https://core.trac.wordpress.org/ticket/55749
    • Have a new plugin to address the issues outlined there
    • Might be a candidate for a Performance Lab module
    • These issues are mostly fixable with filters and actions, but not completely
    • @adamsilverstein: Looks like a core side issue; the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. describes hte issue better. Is the issue specific to the REST endpoint or more generally about how the user query is constructed?
    • @olliejones: It’s actually central to WP_User_Query and WP_Meta_Query, but at the same time the REST endpoint’s set of parameters doesn’t allow for avoiding the query-pagination overhead

Help wanted

#core-js, #core-media, #performance, #performance-chat, #summary

Performance Chat Agenda: 17 May 2022

Here is the agenda for this week’s performance team meeting scheduled for May 17, 2022, at 15:00 UTC.


This meeting happens in the #performance channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance team meeting summary 10 May 2022

Meeting agenda here and the full chat log is available beginning here on Slack.

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein: Refreshed the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WebP patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. against trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. and started separate follow-up PRs for new featured added to the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party since then.
  • @shetheliving: Getting pretty close to wrapping up initial proposals for API to facilitate more accurate sizes #140 and Regenerate existing images #24; next steps will be more detailed design docs and core feature proposals. Research continues on Research: Impact of additional WebP images on upload #289 and Research: WebP compatibility #290 and we’ll draft a follow-up post about our findings and next steps.
  • @adamsilverstein: For Research: Impact of additional WebP images on upload #289, working on a survey for hosting providers to gather some field data about file count and size limitations
  • @eugenemanuilov: If there’s someone who has Outlook and Windows, please test if WebP is supported for Research: WebP compatibility #290
    • @codekraft: Looks like it’s supported in the most recent version
  • @adamsilverstein: Found this summary of WebP support in OG tags; looks like sites should stick with JPEG for OG tags

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.
  • @furi3r: Add Site Health test for full page caching (advanced cache) #220 is almost ready to be merged

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • No updates

Feedback requested

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Open floor

Help wanted

#core-js, #core-media, #performance, #performance-chat, #summary

Performance Chat Agenda: 10 May 2022

Here is the agenda for this week’s performance team meeting scheduled for May 10, 2022, at 15:00 UTC.


This meeting happens in the #performance channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance team meeting summary 3 May 2022

Meeting agenda here and the full chat log is available beginning here on Slack.

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.
  • @furi3r: PR for Site Health test for full page caching is still open; would love another review to get into the next release@flixos90 will take another look
  • @flixos90: Is there any update on the work to refine the two existing experimental Site Health modules to make them non-experimental and eventually merge to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.?
    • @furi3r: We should go over them again and take another look
  • @spacedmonkey: Should we use next week’s meeting to decide what we want to get merged into 6.1
    • @flixos90: Great idea, as well as looking owners for whatever we decide on

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • No updates

Feedback requested

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90: Decision has been made to follow WP core’s versioning approach for our pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party based on the vote in Define plugin versioning approach #300, so next release will be 1.1.0.
  • @flixos90: The other decision we need to make is about release cadence in Define plugin release cadence #320.
    • Before 1.0.0, we published every two weeks, which is the minimum but requires some additional maintenance and overhead, so a timeline of four weeks or more is probably better. At the same time, we don’t want to go too long and lose momentum.
    • @adamsilverstein: Monthly feels straightforward to keep track of; longer gets more difficult
    • @pbearne: A 4 week cycle feels right to me
    • @eugenemanuliov: Yes, 4 weeks seems to be most appropriate
    • @jeffpaul: 10up open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. team checks what’s releasable on the first day of the month and determines if it requires a major, minor, or no release. If there’s a release, it’s done in a subsequent week that month.
    • @flixos90: Could also do monthly, e.g. third Monday of the month. Will add to the options in the issue.
    • Vote is open here until next Monday

Feedback requested

Open floor

  • @jb510: Research: Impact of additional WebP images on upload #289 focuses on the file system impact of WebP. But when an image is uploaded to a post, there is the time it takes the original to upload, but then the user has to wait while additional image sizes are generated and the progress bar for that action completes. We should then consider the impact of WebP generation has on that already sometimes frustrating delay between generating JPEG only vs JPEG+WebP. Want to make sure this is being considered. I recommend moving this to the background.
    • @jeffpaul: Agreed, that UXUX User experience is quite painful
    • @adamsilverstein: Moving to the background would make sense, as that image generation is slow and can break if you navigate away from the editor. Related Gutenberg issue.
    • @adamsilverstein: Note that the progress bar only shows upload progress, not processing progress
    • @pbearne: Once WP has the image, we should be able to release the editor and do the processing in a new thread
    • @jb510: For scope, consider 1) measuring impact of additional processing/completion time due to WebP and 2) finding a way to move that out of blocking the user from continuing with what they wanted to be doing

Help wanted

#core-js, #core-media, #performance, #performance-chat, #summary

Performance Chat Agenda: 3 May 2022

Here is the agenda for this week’s performance team meeting scheduled for May 3, 2022, at 15:00 UTC.


This meeting happens in the #performance channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance increase for sites with large user counts (now also available on single site)

In WordPress 6.0, websites with more than 10,000 users will see improvements in handling users. Prior to changes in #38741, sites with more than 10,000 users would suffer from slow page loading time in the user and post list screens. 

The user screen was slow because a complex SQL query was run to get the number of users for each role. This sometimes resulted in page timeout or failures to load. On the post edit screen, a dropdown of authors in the quick edit option used to change the post’s author. On large sites, this results in thousands of options rendered on the page, which creates a large amount of markup and causes timeouts and slowdowns. 

Introducing large sites

The idea of a large networknetwork (versus site, blog) in multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site configurations of WordPress has existed since WordPress 3.0. A network is considered large when it has over 10,000 users. When marked as such, any real time calculation of the number of users is skipped and all counts of users are deferred to scheduled (cron) events. 

This idea of a large network has now been ported to single site installs of WordPress. Any site with more than 10,000 users is marked as large. Once this threshold is met, real time counts, such as ones noted above, no longer occur on every page load. This means that when viewing user lists, the count next to each user role will be missing. This massively improves the performance of the page page load and prevents slow database queries causing PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher timeout errors, which in turn helps ensure the user list renders every time on large sites. 

This change includes some new functions:

  • get_user_count
    Now available for both single- and multi-site installations. For sites with over 10,000 users recounting is performed twice a day by a scheduled event. 
  • wp_update_user_counts
    Perform a user count and cache the result in the user_count site option. 
  • wp_is_large_user_count
    Determines whether the site has a large number of users. The default threshold of 10,000 users can be modified using a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. of the same name.

Now that the get_user_count is available for both single and multisite, it is strongly recommended not to use the count_users function in your code. This function is not performant and is the root cause of issues noted above. Wherever possible, every instance of count_users in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has been converted to use get_user_count, which is also recommended action for pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors. 

Props to @kkautzman, @milana_cap, and @bph for review and proofreading.

#6-0, #dev-notes, #dev-notes-6-0, #performance

Caching improvements in WordPress 6.0

As part of the release of WordPress 6.0, the new Performance team has been working on several improvements to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. There are a few new additions to the WordPress Caching APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..

Batch API methods for Cache Operations (wp_cache_*_multiple)

The function wp_cache_get_multiple() was added in WordPress 5.5. This allowed for multiple cache keys to be collected in just one request. To complete this API, a full CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) was needed and has been added via the following functions:

  • wp_cache_add_multiple
  • wp_cache_set_multiple
  • wp_cache_delete_multiple

All of these functions accept an array of data to be passed so that multiple cache objects can be created, edited, or deleted in a single cache call.

In WordPress core, these are just wrappers for core functions to allow multiple keys to be passed in one function call, but this would also allow object caching drop-in developers to implement them if their back-end supports it.

Example usage of wp_cache_add_multiple( $data, $group = '', $expire = 0 )

  • $data: Array of key and value pairs to be added.
  • $group: Optional. String. Where the cache contents are grouped. Default ”.
  • $expire: Optional. Int. When to expire the cache in seconds. Default 0 (no expiration).
wp_cache_add_multiple( array( 'foo1' => 'value1', 'foo2' => 'value2' ), 'group1' );

Example usage of wp_cache_delete_multiple( $data, $group = '' )

  • $data: Array of keys to be deleted.
  • $group: Optional. String. Where the cache contents are grouped. Default ”.
wp_cache_delete_multiple( array( 'foo1', 'foo2' ), 'group1' );

Example usage of wp_cache_set_multiple( $data, $group = '', $expire = 0 )

  • $data: Array of key and value pairs to be set.
  • $group: Optional. String. Where the cache contents are grouped. Default ”.
  • $expire: Optional. Int. When to expire the cache in seconds. Default 0 (no expiration).
wp_cache_set_multiple( array( 'foo1' => 'value1', 'foo2' => 'value2' ), 'group1' );

With these additions, some additional core refactoring has been done to utilize these new functions. See more details in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. #55029.

Allow runtime cache to be flushed (wp_cache_flush_runtime)

As discussed in the Performance issue #81 and Trac #55080, Core needed a way to allow users to flush the runtime (in-memory) cache without flushing the entire persistent cache.

This feature was often requested for instances where long-running processes such as Action Scheduler or WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ are run.

Example usage of  wp_cache_flush_runtime()

$counter = 0;
foreach ( $posts as $post ) {
	wp_insert_post( $post );
	if ( 100 === $counter ) {
		wp_cache_flush_runtime();
		$counter = 0;
	} 
	$counter++;
}

The above example would reset the runtime cache after 100 posts are inserted into the database.

Thanks to @shetheliving, @milana_cap, @costdev, @webcommsat, and @spacedmonkey for peer review.

#6-0, #cache, #dev-notes, #dev-notes-6-0, #performance

Taxonomy performance improvements in WordPress 6.0

As part of the 6.0 release of WordPress, the new performance team has been hard at work to improve the performance of term queries. There are many term queries on the average page load and improving these improves the performance of WordPress in general. 

Improvement to term query caching. 

Queries run by WP_Term_Query have been cached since 4.6. The way these caches are primed and handled has been improved in WordPress 6.0.

Removing to cache limit

Prior to WordPress 6.0, term query caches were limited to a 24-hour period for those using persistent object caching. This limitation is now removed, so if caches are not invalidated, it means that term query should cache much longer. For inactive sites or overnight, caches should remain primed, which should improve site performance. 

For more information, see #54511.

Term query cache only caches the term ID

Term query caches have been changed so that instead of caching the whole term object, now only the term IDs are cached. This means that the value stored in cache will be much smaller (in terms of memory) and will not fill up memory in session or persistent object cache.

Once all the IDs for the terms are loaded, the _prime_term_cache function is called. This loads into memory terms that are not already in cache. If the term is already in memory, then it is not loaded again, which is a performance benefit. On an average page load, a term may be requested multiple times, like the case of a tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) archive page. Early in the page load, get_term_by, will prime the term cache and all other calls, such as get_the_terms, will have the term already primed in page memory. This results, in most cases in fewer and smaller queries that are run against the term table. 

For more information, see #37189.

Improved term query cache key generation

Previously, similar term queries that have similar cache keys would result in basically the same query being run twice on a single page load. Because all queries now only get the term ID and store it in cache (see above), the cache exactly the same. For example, you create a call to get_terms where you request all categories and return only the field slug. If you do the same query and request only the name, then this would hit the same cache.

Another improvement is the handling of parameters that can be passed to WP_Term_Query that can be ambiguous. Fields like slug that can be either a string or an array are now converted to always be an array, meaning that the likelihood of reusing a cache is higher as the cache key is the same, no matter which type of parameter is passed. 

For more information, see #55352.

Improve performance for navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. items

Convert wp_get_nav_menu_items to use a taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. query

This replaces usage of get_objects_in_term function with a simple taxonomy query. This replacement converts the use of two queries to get the menu items to use one simple query. This saves one query for each menu requested and adds consistency. 

For more information, see #55372.

Prime all term and posts caches in wp_get_nav_menu_items

The wp_get_nav_menu_items function now calls _prime_term_cache and _prime_post_cache for all objects linked to menu items. If a menu contains a list of categories and pages, all the related objects are now primed in two cache calls (one for terms and one for posts). This will result in far fewer requests to the database and cache.

For more information, see #55428.

Convert term_exists to use get_terms

The function term_exists has now been converted to use get_terms ( WP_Term_Query ) internally replacing raw uncached database queries. This function was one of the last places to perform raw queries to the terms table in the database. Using the get_terms function has a number of key benefits, including: 

  • Consistency with other coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functions like get_term_by
  • The ability to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. the results.
  • Results of get_terms are cached 

term_exists is designed for back-end use and is mostly used in core functions designed to write data to the term table. However, term_exists can and is used by some theme and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers. This results in raw uncachable and unfilterable queries to be run on the front-end of a site. 

Now that term_exists is cached, custom import / migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. tools may need to check if they correctly cache invalidation terms. If your importation code is using core functions like wp_insert_term, then there is no need to do anything, as core does its own cache invalidation for you. However, if you are writing data to the term table manually, then you may need to call the clean_term_cache function. 

For those that need to ensure that term_exists is getting an uncached result, there are two ways to do this:

  1. Using the new term_exists_default_query_args filter 
$callback = function ( $args ) {
   $args['cache_domain'] = microtime();
};
add_filter( 'term_exists_default_query_args',  $callback );
$check = term_exists( 123, 'category' );
remove_filter( 'term_exists_default_query_args',  $callback );
  1. Using wp_suspend_cache_invalidation
wp_suspend_cache_invalidation( true );
$check = term_exists( 123, 'category' );
wp_suspend_cache_invalidation( false );

For more information, see #36949.

Add a limit to taxonomy queries

The ​​WP_Tax_Query class is used in WP_Query to limit queries by term. Under the hood, ​​WP_Tax_Query uses ​​WP_Term_Query, which means that ​​WP_Tax_Query will get the benefits of the cache improvements documented above. The ​​WP_Tax_Query run, which transforms term slugs / names into term IDs to be queried, now has a limit added to it. This query limit improves the performance of the query, as well as improves the likelihood of an existing cache query to continue to exist in the object cache. For example, a standard tag archive calls get_term_by and primes the cache. By the time it gets to the ​​WP_Tax_Query, that query is being loaded from cache. This removes one query per tag archive page. 

For more information, see #55360.

Props to @milana_cap, @shetheliving, @flixos90 for peer review.

#6-0, #dev-notes, #dev-notes-6-0, #performance, #users