Launching Kinsta APM with deliberately broken WordPress sites

Set up two sites that looked like customers’ sites

I set up the store first, on Astra with WooCommerce 4.7.1 and a cart abandonment plugin. A store with a checkout has more places to go wrong than a blog does.

Then I set up the membership site on LearnDash, with courses behind a login. It got a set of test members, so the emailer had someone to write to.

Write five plugins that fail in five different places

Each plugin did one thing badly. payment-api called slow.payment-api.com from a function named update_card_payment every time a customer added a product to the cart.

snail-admin-refresh-notice ran snail_admin_refresh on every admin page load and fetched suspicious-link.com while it was at it.

For the product pages I injected a slow database statement into woocommerce-related-products, the extension that builds the related-products slider under every product.

On the membership site, course-views-counter called courses.salrav-external.com on every restricted page. Mass Member Emailer sent mail to every member through the web server at a fixed time each day.

That’s an external call, admin PHP, a MySQL query, an external call plus PHP on the front end, and a scheduled job. Five layers, so the articles could show the tool reading each one.

The admin plugin also put a hideous notice at the top of the WordPress dashboard, just like some popular plugins do.

Make the slowdowns happen while the tool was recording

For each demo I enabled the tool, waited at least 5 minutes, and used the site the way its owner would.

For the admin demo I waited 15 minutes and worked in the WooCommerce dashboard the whole time. For the emailer demo I waited for 22:30, when the plugin was set to send.

Take the screenshots in the order a reader would click

Every demo has the same sequence of screenshots, from the overall transaction chart down to the stack trace. The eight stops are listed under the results.

I took 25 for the WooCommerce guide and 20 for the membership guide. That count includes the site screenshots that show the notice, the slider, and the emailer’s settings page.

I’m going through all of this because the articles skip it. A reader sees a trace and a stack trace. Two sites and five plugins are what put them there, plus the waiting.

Check every draft with the product team and Support

I was Kinsta’s Technical Editor, so the editorial sign-off was mine. That made the product review matter more, since the person checking the prose was also the person who wrote it. The product team read every draft for unsupported claims, and Support helped me debug the demos.

Some of the work never made the text. I read the product team’s internal documentation and their chats. I worked on the pre-release build before customers had it, which made me one of its early testers. I also worked on the knowledge base article and the product page, and I checked the launch video scripts.

The Content team planned the wider campaign. Matteo Duò published a roundup of APM tools on October 14, 2020, a month before my explainer. Kinsta’s launch announcement and its year in review then linked the three articles as a set, and the documentation still does.

The use-case idea, the briefs, the sites, the plugins, the screenshots, and the three articles were mine.

Publish the three times the tool missed

I wrote the admin demo to show Kinsta APM highlighting the problem spans in red. It didn’t.

The two slow spans, snail_admin_refresh at over 10 seconds and the suspicious-link.com GET, were in the timeline with no highlight on them. I found them by reading the durations. I left that in. The article says the tool highlights the problem spans in most cases, and that this was one of the other cases.

In the emailer demo, the first span the tool highlighted was mass_member_emailer at 1,269.68 ms, which was 15.5% of the sample. The one that mattered was further down the timeline.

Mass_Member_Emailer->send_emails took 5,070.85 ms, or 61.92% of the same sample. The article walks the reader past the first span to the second, because that’s the order the timeline shows them in.

In the payment demo, the symptom was a slow add-to-cart button. The slowest transaction in the table was /single-product. WooCommerce posts the cart action to the product page, so the article had to explain the transaction name before it could explain the trace.

All three stayed in. Each one cost a paragraph, and each paragraph is still on the page.