[wp-trac] [WordPress Trac] #49634: Performance Benchmarks for REST API
WordPress Trac
noreply at wordpress.org
Thu Apr 9 20:33:13 UTC 2020
#49634: Performance Benchmarks for REST API
-----------------------------+------------------------------
Reporter: mnelson4 | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting Review
Component: REST API | Version: 5.4
Severity: normal | Resolution:
Keywords: dev-feedback | Focuses: performance
-----------------------------+------------------------------
Comment (by mnelson4):
In slack @kadamwhite said
> The two options I was considering were, either something that we could
run manually, perhaps against a VM or a designated testing target site
each cycle; or, more interesting although certainly more overhead,
something that would actually run in CI for more consistency
> I think the landscape of tools that you turned up matches what I was
looking at
> I’d say maybe let’s start with the first option, and build a list of
requests that we can run in a somewhat Manual fashion against a local VM
target; a series of those runs can be averaged to get a metric for a given
release cycle. Building something with puppeteer or Node that would run
within CI can then be built on top of that, once we have a base set of
cases we think are valid and representative
> I am also hoping to run some flame graph tests in the next few days
using some new features in our Altis virtual environments to get
additional metrics
But either way the next step is to build a set of representative requests,
like “100 posts,” “10 posts with embedded data,” etc and figure out how to
get rough coverage across the API
> I would think, anyway. Happy to be challenged, as you noted it’s
annoying there’s so weirdly little prior art :)
Then I asked if we’d want to setup a server and send actual Http requesrts
to it, or just run tests in PHP like PHPUnit, he said
> since we'd need a database to be able to fulfill most requests I think
standing up a container or VM and sending real requests had been my
instinct. It'd conflate our results with the WP initialization cycle, but
that's more realistic
So I’m thinking of actually trying to piggy back off Gutenberg team’s
performance tests, but instead point them to the REST API endpoints...
we’ll see how that goes...
--
Ticket URL: <https://core.trac.wordpress.org/ticket/49634#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list