[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