Ever since I started developing plugins for WordPress I’ve wanted to know what’s going on under the covers and how I could improve it. Here’s a chart that visualizes some results. I’ll try to explain them in later slides. There’s some clues in the questions.
To find out what’s going on I wrote a trace routine. It logs output to trace file. It’s not just a var_dump(). There’s an awful lot of contextual information. It’s similar to query-monitor; it traces front-end, admin, scheduled requests, AJAX requests, REST requests and command line stuff. The main difference is that it produces plain text files you can browse at your leisure. The output is NOT intermingled with the real results. Oik-bwtrace also produces a “Daily Trace Summary” report, showing each request’s relevant(?) statistics at `shutdown`.
To understand any data echoed from a system it’s good to have context. Quite a lot of it. You never know when it’ll come in handy. In a debugger you can get this at run time. But debuggers slow the system down. So does tracing for that matter. Don’t remember to disable tracing when running performance tests.
5 years ago I wrote a post processing routine (Slog for Server Log) to summarise the requests in the Daily Trace Summary files grouping by elapsed time then merged the output from multiple logs and then manually produced a chart to display the results in Excel. It was a convoluted process. Recently I decided to invest some time to develop a Chart block which I could use to display the results immediately.
Using the server side rendering for the Chart block I was then able to start to visualize the WordPress web server’s processing. The Reports tab is used to analyse a Daily Trace Summary file. Each Report shows the results of a grouping of data by selected values ( eg request type, URI, elapsed time IP address). It displays the results in a chart and table. The chart can show Count, Elapsed, Average, Percent count, Percent average, Cumulative percent count and Cumulative percent average. The table shows all columns. Requests can be automatically filtered by request type.
Again 5 years ago, when running tests to evaluate the effect of activating a plugin or configuration option I used a batch driver to perform a variety of requests closely matching real activity. For the Driver tab I just use one URL. The more requests run the better the results. That’s assuming response times are acceptable.
These are the results of running 100 requests to the home URL having activated each of the top 12 plugins. See my website for an interactive version of the chart. For the latest summary of top 12 plugins see https://top-10-wp-plugins.com/. In this chart we can see that Jetpack, WooCommerce and Elementor are the most resource hungry.
Here’s the Blue Peter version of some tests that I ran today on cwiccer.com with Yoast SEO, JetPack, WooCommerce and combinations. Jetpack in orange was with Jetpack activated but not connected. Jetpack-site-accel is with the Acceleration toggled on. I was visiting the home URL of cwiccer.com which displays latest posts. Vanilla is Twenty Twenty with 3 plugins: oik-bwtrace, sb-chart-block and slog. You can draw your own conclusions.
For more information about these plugins see my GitHub account: bobbingwide, or visit oik-plugins.com. Oik-bwtrace is on wordpress.org, sb-chart-block was submitted yesterday – as a single block plugin. For my lightning talk on oik-bwtrace see the slides on WP-Pompey or watch the video on YouTube.