Performance team meeting summary 30 August 2022

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

Announcements

  • @flixos90: multiple announcements
    • Team Rep nominations reminder
    • If you are contributing to the WordPress/performance GitHub repository (or any WordPress GitHub repository FWIW), please link your WordPress.org and GitHub accounts if you haven’t done so. You can do so at https://profiles.wordpress.org/profile/profile/edit/group/1/
    • If you have been contributing to the team’s efforts (e.g. GitHub, discussions, conversations in this chat, …) but don’t have the “Performance Contributor” badge on your profile, you may request to have it added by requesting to join the group at https://profiles.wordpress.org/associations/performance-contributor/
    • If you are contributing to the WordPress/performance GitHub repository, please be aware of a new rule to avoid naming your regular temporary coding branches something like feature/. That feature/ prefix will be reserved for special protected feature branches going forward
      • @adamsilverstein: other than the ‘feature/’ prefix, are there any other conventions we want to follow / is that documented somewhere?
      • @flixos90: Only feature/ and release/ must not be used for regular coding branches (a pull request to document this has since been opened)

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein: we have been working on responding to feedback on the WebP ticket (#55443) and conducting research around the potential usefulness of a “threshold” size above which jpegs would be generated instead of WebPs.  The research used WP-CLI to run many images through WordPress image compression with WebP quality set at 82, 84 & 86 to investigate how often WebP images are larger than the JPEG equivalent, at what image dimensions, and by how much. I will be summarizing the research in my response on the ticket shortly
    • there seems to be strong agreement that we should only output a single mime type. The main question now is if the mult-mime support is worth keeping – the code adds a good bit of complexity to media, and isn’t strictly required for the approach we are considering now… so we are trying to weigh the pros and cons of keeping it. It might make sense to revert and re-introduce when we have support for async media generation (something we are already working on)
  • @joegrainger: Working on creating sub-issues with implementation details for Regenerate existing images and core patch for Update core functions to support multiple mime types
  • @mukesh27: Working on WebP core follow-up patch https://github.com/WordPress/wordpress-develop/pull/3036 and Core Trac ticket with performance focus
  • @wpgurudev: Basic regenerate-existing-images module PR has been merged, follow-up PR for background job taxonomy up for final review; background job class PR is ready, waiting for taxonomy PR to get merged, so that tests can be added
  • @pbearne: Dominant color is getting pushback; would like to suggest that we put it behind a theme feature flag (show-dominant-color) and we add it to the media library in wp-admin
    • @flixos90: We should evaluate that pushback closely. Can you elaborate why it should be controlled by the theme instead?
    • @pbearne: The push back seems to have the theme of “we like this but themes should control the look and feel”
    • @flixos90: So it would mean the data is still added to every image upload, but the theme decides how to use that color information? Sounds reasonable
    • @flixos90: discussing this further will be made a dedicated agenda item next week

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • @tillkruess: focus had one core merge last week (see PR / changeset), with great results already (see chart from wordpress.org below, shared by @dd32)
MySQL throughput dropping from roughly 1.5M to pretty much half following the commit

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
  • @furi3r: persistent object cache Site Health PR was merged (see changeset / ticket), what is left for the full page cache PR (see ticket)?
    • @flixos90: haven’t re-reviewed it yet since last week, but if all the feedback from then has been addressed and the merge conflicts are fixed, this should be good to go
  • @furi3r: can try to get a Draft for the dev notes by next week, I’ll be on holiday after that, so maybe someone can take over if not ready/published

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
  • @mehulkaklotar: working on proposal for Plugin Check plugin

Feedback requested

JavaScript

@aristath @sergiomdgomes

GitHub project

  • @pushpakpop: we have started research around the approach for the JavaScript orchestration project

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @mukesh27: PR to fix unexpected input Warning message during release build/test process ready for re-review

Feedback requested

Open Floor

  • @olliejones: Database Performance Health Checks module proposal (continued from last week)
    • @olliejones: Is DBMS server performance part of the mission of this group?
      • @flixos90: Absolutely! Every aspect of performance is relevant to the team’s mission
    • @olliejones revised this health-check module proposal to simplify the output (see https://github.com/WordPress/performance/issues/475 and please look at the “Other” section), agrees with last week’s conversation about excess complexity; we’ll do all the checks and only report the trouble spots
      • @flixos90: In that case I’d argue there is still a lot of complexity. Implementing each of these tests in a reliable way is probably not trivial. To clarify, I’m not saying we shouldn’t do it. I’m only suggesting we start with only one of them for the first version and add the others in additional iterations
      • @olliejones: FWIW I have a prototype I’ve been testing against old versions of DBMS software as well as new versions. The tests were designed to cope with missing RDBMS features in the old versions. Yeah, complex, for sure. But doable.
    • @flixos90: Does anybody have objections against this module proposal?
      • Quick survey of thumbs up / thumbs down resulted in 9 thumbs up and 0 thumbs down
      • @olliejones will start a pull request introducing the module; if it shows that some bits there are too complex to get through in a reasonable time, we can still re-assess if we want to narrow down the scope

Our next chat will be held on Tuesday, September 6, 2022 at 15:00 UTC in the #core-performance channel in Slack.

#performance, #performance-chat, #summary

Leave a Reply

Your email address will not be published.