Bethany Chobanian Lang 4:59 pm on September 20, 2022
Tags: , , , , , ,   

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 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 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 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 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/.
  • @mxbclang: #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
  • @mxbclang: 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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

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

  • 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 WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. 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 ticketticket Created for both bug reports and feature development on the bug tracker. 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 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. (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: CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 networknetwork (versus site, blog) 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