Yesterday, the Cheltenham WordPress Meetup was a series of Show and Tell talks. Along the lines of Lightning talks, these are talks of approximately 10 minutes, where individuals share something they’ve been working on. There were 7 talks planned:
- Richard Bell @Rich Bell demoed Ray and Background WordPress processing,
- Mark Wilkinson @wpmark demoed his Just In Time CSS,
- Elliott Richmond @erichmond showed us how to run Xdebug using Visual Code Studio, setting breakpoints, watching variables and changing values on the fly,
- Ross Wintle @magicroundabout demoed his new CSS and PHP based spam pixel plugin to block spam bots
- Keith Devon @keithdevon showed us his work on CSS grid for block based themes
- We ran out of time before @Jonnyauk had a chance to show his latest work with template parts ( PHP version not FSE ).
- and somewhere in the middle of it I talked about 3 plugins I’ve written to help visualise my server side performance: oik-bwtrace sb-chart-block and slog.
This post is the annotated version of the slides.
There should be a Slideshare embed here.
Slide 1 – Show and tell – what’s going on?
Do you know what your web server is doing?
What’s happening, what’s happening?
Moley Mole asks Musky Muskrat in Deputy Dawg ( 1962 – 1963 )
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.
- Do you know what it’s being asked to do?
- Do you know how long it takes to do it?
- Do you know how each plugin affects your server performance?
Slide 2 – oik-bwtrace – debug trace
To find out what’s going on I wrote a trace routine. It logs output to trace files. 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`. Also a plain text file, in CSV format, that can be browsed or analysed programmatically.
Slide 3 – What else might be useful?
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, such as Xdebug, you can get this at run time.
But debuggers slow the system down. So does tracing for that matter. Don’t forget to disable tracing when running performance tests; just leave the daily trace summary enabled.
Slide 4 – sb-chart-block
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 I merged the output from multiple logs and 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.
Slide 5 – Slog: Reports
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.
Slide 6 – Slog: Driver
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. Type in the URL, the number of requests to run and select Run requests.
The more requests run the better the results. That’s assuming response times are acceptable… that’s below 0.6 seconds. See Time To First Byte .
Slide 7 – Slog: Compare
These are the results of running 100 requests to the home URL having activated each of the top 12 plugins; one by one, not cumulatively.
In this chart we can see that Jetpack, WooCommerce and Elementor are the most resource hungry.
That’s in the Slideshare, not below. Alternatively, see Slog bloat for the interactive version.
And for the latest summary of top 12 plugins see Top 10 WordPress plugins.
Slide 8 – Slog: Today’s results
Here’s the Blue Peter version of some tests that I ran on cwiccer.com with Yoast SEO, JetPack, WooCommerce and combinations.
- I was visiting the home URL of cwiccer.com, which displays latest posts.
- Vanilla shows the results for the Twenty Twenty theme with 3 active plugins: oik-bwtrace, sb-chart-block and slog.
- Jetpack (in orange) was with Jetpack activated but not actually connected.
- Jetpack-site-accel is with the Acceleration toggled on.
Hint: Some plugins are serious bloatware.
Slide 9 - For reference
- Oik-bwtrace is on wordpress.org
- sb-chart-block was submitted yesterday – as a single block plugin.
- But slog is only on GitHub and oik-plugins
For my lightning talk on oik-bwtrace see the slides, originally uploaded to WP-Pompey, or watch the video on YouTube.