MySQL and WP-Cron Performance Effects Case Study

MySQL and WP-Cron performance effects are problems that can really haunt you. Every millisecond counts when you’re trying to keep your eCommerce website fast and lean. That’s important to rank high in Google search results. But how closely are you paying attention to your site’s performance? Are you aware of dangerous spikes in bad performance, particularly when you update WordPress or a plugin?

Here is an example of how important it is to watch your site performance.  Pay attention before and after any deployment of new or updated code, including plugins. These graphs are from NewRelic, which is included free in all of our Performance-level hosting plans and above.

Performance Observations for Months 1-3

This client’s site 3-month performance baseline was average for a busy site during optimization. Browser page load speeds were at about 7-8 seconds, which was not great. The visual load experience was fine. They deemed it acceptable enough to produce a good number of sales. The background AJAX code and external callouts don’t show on the front-end but still counted toward the total.

A particular plugin got an update in mid-January, a fact that will be massively important later on when considering MySQL and WP-Cron performance effects.

Performance Observations for Months 3-6

In the next 3-month window, an initially imperceptible, gradual increase in page load times occurred. A myriad of other initiatives occupied the team so they didn’t watch it as closely. The total transactions time went from between 800ms to well over 5,000ms over that span of time. The problem was that the updated plugin had some “runaway” MySQL queries. The queries were firing too often via wp-cron and were querying for too many rows.

Sales were still doing well enough. So it didn’t cause concern even though it should have if it they had watched for and detected it. Whenever a user visits the site, some PHP code in WordPress runs. It checks to see if there are any cron processes that need to start and starts them. This can result in dozens of calls per minute for a popular site and will drag performance down. An overly-generalized MySQL query also ran every 15 minutes within the problem plugin. This led to the site’s SQL queries slowing to a crawl. The front-end wasn’t suffering as much overall because of CDN-based caching. The optimized, containerized hosting also helped to isolate MySQL problems from the rest of the performance metrics.

Performance Observations for Months 3-9

They kicked off the last 3-month window with a complete deactivation of the default wp-cron process. They then changed over to an external URL cron triggering process.

As you can see, the drop in web transactions time was really steep! The site then went through some growing pains with a problematic payment provider. They had to shut off the eCommerce feature and fulfill orders in another way until they restored normal operations. That gave the client an insight into a non-eCommerce baseline for average traffic that will help gauge future performance outcomes. They also noticed that activating the plugin again still resulted in an unacceptable spike in transactions. This in spite of the fact that the vendor had claimed to have optimized it. So, they turned off the plugin off while the vendor seeks another solution.

Conclusion

MySQL and WP-Cron performance effects vary per site. It’s critically important to watch what happens each time you update your software and deploy it to the live environment. Whenever possible, do load testing and end-to-end UI transaction testing. Ensure that your users will not experience any slowness while browsing or going through a purchase process. Look at the performance of your app server (PHP), your database (MySQL), object caching (Redis). Tune all your external website callouts (PayPal, Twitter, and Facebook API calls, for example).

Make a daily habit of checking short-term, mid-term, and long-term performance. When you see something unusual occurring in the short term, investigate possible problems. But know that sometimes you have to “let it play out” into the mid-term reporting before you know whether it’s a real problem.

Most of all, turn away from cut-rate shared hosting plans that offer you nothing in terms of performance. Get a VPS or dedicated server, or, better yet, a next-generation containerized hosting solution. The monthly hosting cost may increase. But so will peace of mind knowing that you’ll have better performance out of the gate as well as advanced tools and support for when things go wrong.