Query Monitor solved my problem
After helping a friend test drive a couple of plugins, one of my sites started behaving badly. The load time went from 2 seconds to 5, which is not acceptable. Everything worked fine, I just had this lag that I couildn’t figure out. Suspicious that one of the plugins had screwed something up and didn’t clean up after itself after I deleted it, I started looking for debug tools.
I’d head about Query Monitor, and it looked like it could be a quick hit solution-I didn’t have to run any weird database queries or the like. I installed it, did some reading, and came up with nothing. I’ll come back to this later, because I missed something, and that turned out to lead to the solution.
I started running page speed tests, which confirmed thet TTFB (time to first byte) was outrageous-4+ seconds. The big thing that was puzzling, is that this site is on a WordPress multisite, and none of the other subdomains had this same speed problem. I hadn’t installed anything recently, such as a new plugin (besides the one I was testing and had deleted). Which further convinced me it had something to do with the deleted plugins.
I looked at server latency, but eliminated that, due to the anomoly on just one subdomain. I even cloned the multisite to a test VPS to see if that would unveil anything I had overlooked. I deactivated a few possible plugins that I wasn’t using that much, but it didn’t help. I finally concluded that it had to be either a plugin or the database, and I was leaning toward the database. So, I turned to Query Monitor again, as it’s forte is determining such things. Bingo. When I looked at the Query tab, and as I paged downt the list of queries, one had a ref flag on it. Somthing to do with site 14 and autoload. Query Monitor even showed me the query I could use to investigate what could be wrong. It turned out that one of the deleted plugins had left 14 millions ‘cron’ rows in the database. Problem solved, and now I’m back to sub 2 second load time.