Performance team meeting summary 20 September 2022

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

Announcements

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein: WebP feature was reverted following Matt’s post. Still trying to determine what a canonical plugin is and if it would work for WebP by default. Still have some fixes to land for 6.1 around image quality when WebPs are output via Performance Lab plugin.
  • @spacedmonkey: Next steps for Dominant color feature
    • We’ve run out of time to merge before Beta 1 cutoff
    • Feedback process was a lot slower than we thought it would be
    • Should continue to work on this and try to get it in for 6.2
    • @pbearne: Version with theme flag could be merged
    • @spacedmonkey: Merging now doesn’t feel great as there are still unanswered questions. Code is ready, but not sure what feedback will push this across the line. May need to push early in 6.2 cycle and see what happens.
    • @flixos90: Feels like another merge proposal post with a concrete timeline on a merge date could be good to put out right after 6.1, so people can provide any additional feedback. Should also note the new theme support flag approach.

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 ping in Slack
  • @shetheliving: #56040 and #56041 (two Site Health checks from Performance Lab) have been merged for 6.1 and dev notes are in progress
  • @mukesh27: PR #543 for adding can-load.php to these Health Checks is ready for review

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
  • @shetheliving: Reminder about the performance testing environment work started back in March: https://make.wordpress.org/core/2022/03/22/performance-team-meeting-summary-22-march-2022/. This has stalled out since then; if anyone is interested in picking it back up, let us know.
  • @flixos90: Working on a proposal to integrate the Server Timing API into Performance Lab. We have a lack of awareness for how WP is performing server-side and this simple piece of infrastructure would allow us to measure specific features/modules of the plugin to see who they are affecting PHP performance. Should an open an issue this week or next.
  • @mehulkaklotar: Continuing to work on a proposal for the plugin performance checker tool

Feedback requested

JavaScript

@aristath @sergiomdgomes

GitHub project

  • N/A

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Discussion: Module proposal: Optimized autoloaded options

@markjaquith

  • Options are autoloaded by default, and most options stay autoloaded even after the plugin or theme that uses them has been deactivated
  • This autoloading has a cost in terms of the performance of the query that loads autoloaded options, and also because the values of these options are kept in memory
  • Discussed a lot of ways of addressing this at WordCamp US, and the most promising path that would have the most benefit for the most users (and fits in with this group’s philosophy on focusing on automated fixes instead of introducing new APIs) is to dynamically move options in and out of the “autoload” pool based on usage
  • Options that are used *and* are not past a certain size cutoff should be autoloaded, but large options and options that are not used, should not be autoloaded
  • Proof of concept is linked in the ticket and we’re looking for additional feedback
  • @pbearne already brought up the issue of options that are queried BEFORE a module could start “listening” for them to be called, but there are undoubtedly other gotchas and opportunities here
  • Especially useful would be help in developing a strategy for measuring the performance of this fix for various sizes of autoloaded options
    • @flixos90: Could leverage the Server Timing API (noted above) to measure the time the autoloaded options query takes, for example
  • @pbearne: Think that both @markjaquith‘s and my fixes can be used as they work best for different configurations
  • @spacedmonkey: Could we start adding a limit to the number of autoloaded options, say 250 rows? Or is the issue size in terms of memory?
    • @pbearne: If we can load just what we need, the SQL time is less
    • @markjaquith: We do this to avoid hundreds of individual queries
  • @rickjames: Is “autoloading” the thing that PHP can do for include files? I thought it was so slow as to be better to always include everything
    • @markjaquith: No, this is about quering the wp_options table for autoload = 'yes'
  • @rickjames: That gets to the lack of adequate indexes for the wp_options table; a simple change can speed up SELECTs
    • @markjaquith: There’s already an index, it’s more about the volume of data being transferred
  • @eugenemanuilov: Think we should move from defining which option is autoload-able in the database table to the option registration in WP, so a plugin/theme owner will need to register an option similarly to how settings are registered with register_setting and define whether an option is autoload-able there
  • @flixos90: Both proposals at a high level have the idea of querying what is needed, but the newer proposal does it globally while still keeping a single place of storage while the latter was aimed at having different “options lists” per template/page. The latter would be great, but it comes with heavy storage implications, so the newer proposal is probably the best place to start since it has no additional storage implications.
  • @markjaquith: Do think that the issue is data, not rows – evicting autoloaded options could help wtih both
  • @rmccue: Have run into performance problems with pulling autoloaded options from object cache, so agreed that this is an issue
  • @markjaquith: Also issue with memcache’s default config being size-limited
  • @spacedmonkey: Could we use register_settings to define if an option should be autoloaded?
  • @rmccue: Core problem is that autoload is true by default, which is what causes issues
  • @markjaquith: Two approaches – @pbearne optimized for “literally just what this page needs”; my POC was for “never autoload things that aren’t used”
  • @spacedmonkey: So will we store an array of used options in options table?
    • @markjaquith: Current implementation only stores timestamp of last calibration, but with some additional storage we could minimize dynamic re-adding of autoloaded options
  • @rmccue: Autoloading options should minimize DB/cache calls, but not necessarily replace them. The heuristic of what should be autoloaded is key to this proposal.
    • @markjaquith: To me, it’s “things that are used and aren’t unreasonably large.” Can also honor autoload='no' while not honoring autoload='yes' as chosen by developers.
  • @spacedmonkey: Don’t love the idea of storing an array of keys. How do you generate the array? What is the average page load?
  • @rmccue: To move forward, we need a concrete proposal for how the heuristic works. Will look into the network saturation problems we’ve run into get an idea of what “unreasonable” might lok like.
  • Next steps: @markjaquith will work on detailing the heuristic further in #526 and when it’s ready, we’ll schedule another discussion for a future chat

Our next chat will be held on Tuesday, September 27, 2022 at 11am EDT in the #core-performance channel in Slack.

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

#meta

Leave a Reply

Your email address will not be published.