[wp-trac] [WordPress Trac] #59900: Measure performance with a persistent object cache in performance tests

[WordPress Trac]

#59900: Measure performance with a persistent object cache in performance tests
-------------------------------------+--------------------------
 Reporter:  flixos90                 |       Owner:  flixos90
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  6.5
Component:  Build/Test Tools         |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch 2nd-opinion  |     Focuses:  performance
-------------------------------------+--------------------------
Changes (by flixos90):

 * keywords:  needs-patch => needs-patch 2nd-opinion


Comment:

 So far, the different performance benchmark scenarios all simply depend on
 different configuration of the WordPress site. However, this one is
 slightly different as it ties into the server stack.

 I'm thinking of two alternative options we have here:
 * Either we set up separate environments, one with object caching and one
 without. This could for example be done by restructuring the
 `performance.yml` workflow to use a matrix, where e.g. every single
 scenario is its own entry and could be run in its own environment. That
 may be beneficial for better test separation and maintenance anyway, but
 it could also make the process slower or more costly overall.
 * Or we set up the single environment we already have with object caching
 enabled, but by default ensure the `object-cache.php` drop-in isn't placed
 in `wp-content`. That way, the object cache wouldn't be used so it
 shouldn't make a difference for all existing scenarios. We could then
 implement a way to place the file from within PHP (e.g. a REST endpoint
 just for this workflow), accompanied with a Playwright set of functions
 like `enableObjectCache()` and `disableObjectCache()`.

 I think the first one ''could'' be a bit cleaner, but it's also clearly a
 lot more work. If it's possible to place the drop-in via PHP in the GitHub
 workflow, I think that would be a much more straightforward solution not
 involving any refactoring.

 Thoughts?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59900#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform