I’ve had some performance issues on one of my sites. In this post I discuss some of the solutions to the problems; determining the cause, then applying the pragmatic fix.
I’ve been on vacation for nearly a month. While I was away it was reported that the performance of oik-plugins.com was pretty dire; it was displaying 508 – resource limit exceeded messages to visitors.
When I got back I decided to track down and attempt to fix the problems. I probably didn’t approach the problem in the most sensible order, so it took me a while to get the system back to some semblance of normality.
This is a sanitised version of my analysis of the site’s performance from 13th to 15th March, 2015.
- Initially, having played with Interconnect IT’s wp-performance-profiler plugin on a local server, I tried running my improved version.
- But with the CPU at 100% I was getting nowhere fast.
- Nearly all transactions were taking between 10 and 20 seconds.
- And when advanced logging was enabled things got significantly worse, partly due to the overhead of the extra processing for each tick.
- Instead I decided to look at the total execution time of each transaction and compare the results with the sister site(s) oik-plugins.co.uk and oik-plugins.uk.
- Using oik-bwtrace plugin (v1.22) I enabled the logic to write a record of summary information for each completed transaction to a log file, on both oik-plugins.com and oik-plugins.co.uk
- After a while I downloaded the files and compared the results.
- I then did a bit of yak shaving, analysing a long term problem with my bw_plug shortcode.
- Having deactivated the shortcode I continued the analysis.
- Things hadn’t got any better so I decided to deactivate some plugins. Still no improvement.
- I then produced a summary of the transaction log, counting the requests to a particular URI and measuring the average response.
- The results for the top 15 most requested URIs were intriguing; nothing like the Most popular posts identified by Jetpack. The most accessed top level URI accounted for 38%. The top 15 accounted for nearly 96% of the total requests, with 6% of the requests equating to spam.
- Analysis of the access log for the same period showed that nearly all of the non-spam requests were coming from Microsoft’s bingbot
- It was time to remove bingbot from the equation.
- And given that the spam requests ended up on the 404 page, which on average was taking twice as long as a bingbot request, these needed to be dealt with as well.
- I created a number of 301 redirects. It didn’t take long for the CPU usage to drop dramatically
- I’ve finally re-stabilised the system, and can now start a proper analysis.
Summary of symptoms
|Critical||100% CPU||cPanel resource usage|
|V.high||Long running transactions||Summary trace log – summarised|
|High||Too many queries||Summary trace log – summarised|
|High||transactions not logged?||Probable misconception!|
Summary of fixes
|bingbot hogging resources||301 redirects||reduced CPU leading to improved response|
|spam requests||301 redirects||reduced CPU leading to improved response|
|data not cached||temporarily disable||reduced execution time|
|unnecessary plugins||deactivate||not yet measured|
|wp-super-cache configured incorrectly||Update configuration||not yet measured|
|longish running queries||temporarily disabled||reduced execution time|
Details for these fixes may be published in the future. Meanwhile I’m seriously considering upgrading hosting. I’m going to run head to head performance comparisons of the site using 3 different hosting solutions:
- Current hosting
- WP Engine – which I’ve been using since November 2015
- SiteGround – set up today