Recently, I was engaged to work with a sometime client to help determine what might be eating up all the memory at her website and bringing the whole server (including another of her websites) down for 6 hours at a time. She had been working with her hosting company for a week on it and they had not discovered what it might be. Suspecting that the memory consumption might be due to a plugin with unoptimized reads on the database, they asked me to take a look.
The website ranks in the top 93K in the US, receives 7K visits per day, is built on Genesis framework, has 78 pages and about 600 posts, and recently switched over to CloudFlare CDN implementation. Several people work on the website, of varying degrees of familiarity with hosting servers and WordPress.
WordPress Plugin Inventory
I took inventory and learned there were 29 plugins. Most I recognized. Three that were inactive, I deleted right away. There was one plugin that monitors the Cron jobs, so, I thought that would be a good candidate, and another that monitors for bot activity and I thought that would be a good candidate as well.
WordPress Diagnostic Tools
I searched around the web and found P3 the Plugin Performance Profiler plugin and Query Monitor. With P3, I did manual and automatic testing. P3 reveals the results of testing (traversing from page to page for a sample session) in a pie chart.
P3 revealed that the Ninja Forms plugin was making (on average) 67 interactions with the database on each page/post. There is only one page with a short, standard form the website, so that was curious behavior to observe. The other resource consumer was the bot monitor (BotDetect Captcha), followed by WPTouch, the mobile-friendly plugin. One of my initial suspects, the Cron job monitor barely showed up as using any resources.
Query Monitor displays multiple views of the interactions with the WordPress database on each individual page and post as you are on that page/post. One of those views, Query by Component, consistently concurred with the P3 plugin about which plugins were consuming all the resources.
It turned out that the problem was related to the hosting situation and DDS attacks – but – I was glad to learn about and use these two plugins. The resource hogs were revealed, and because of that, I was still able to help this client. We learned that 65% of a pages’ load time was consumed by the plugins, and that Ninja Forms, WPtouch (mobile-friendly plugin), and BotDetect Captcha were the three biggest resource consumers.
Today we removed Ninja Forms and, replaced it with a simple lite form plugin that has a little over 100K active installs. It actually displays a more pleasant form and was so much more simple to set up. It’s use on resources thus far is negligible. The client and I have a verbal agreement to do continuous improvement based on the results of using these two plugins in the upcoming months.
Even though I am a novice with the Plugin Performance Profiler and Query Monitor plugins, I highly recommend them as helpful WordPress plugins.