11/10/2013: After the nasty surprise I got Friday – this blog got suspended for excessive CPU utilization – I had to make some changes to get reinstated.  If you’re a regular visitor to the USWildflowers Journal, you probably noticed the appearance change.  Here is the reason it’s changed, in much more detail than most of you care about.  Let’s call it “documentation” rather than “he’s talking to himself, again.”

I didn’t even know it was “suspended” – my hosting provider blocked all IP addresses except the ones I’ve used to access the control panel for the account, so when I hit the site all seemed good.  I was gone most of the day, and noticed when I got back noticed the hit count for the Journal was low, but I chalked it up to being a Friday after the end of the wildflower season (USWildflowers.com traffic is HIGHLY seasonal.)

The first thing I did was disable a few plugins that I don’t use, as well as one that I was using – NextGEN Gallery.  Disabling that means several of the photo albums on the site no longer work, but NextGEN has had some problems with recent releases, and I thought maybe high CPU utilization was among them.  When I let my Hostgator know what I’d done, and promised I’d work further on it, they reinstated it, and it was operational again around 4 AM Saturday morning.

While CPU seemed to be under control, I continued to be a bit concerned about the utilization as it started climbing around 07:00 Saturday, so I disabled WP-Cron from running with each post access, and instead used cron to schedule it to run twice an hour.  This could potentially wind up with some scheduled posts showing up a little late, but should reduce CPU load a bit.

This morning, still not satisfied with the CPU utilization, I decided to switch WordPress themes.  I liked the theme I had been using – Gear – but it had not received any updates since early in 2010, so I figured it was possible there were some incompatibilities with optimized routines of newer releases of WordPress.  I figured after 4 years maybe it was time for a bit of a change in the look of the blog anyway, so around 6:15 AM this morning I implemented the Twenty Twelve theme (after backing up my database and files!)  Shortly thereafter I grabbed a strip out of a photo of Autumn Sneezeweed, and added that as the header image.  I’ll probably trade that out every once in a while, but it gives a cheery look to the page for now.   I needed to tweak it a bit – the Twenty Twelve theme didn’t have a search option on the page, nor did it have the RSS feed icon, but those are back in place now – well, back, but in a different place…

Unfortunately, that didn’t result in any dramatic drop in CPU usage that I couldn’t attribute to normal traffic flow changes, so I started pondering another step that I’ve been trying to avoid for a couple of years, due to fear that it wouldn’t be compatible with how I use this blog – that is, implementing a caching plugin.  When all of a sudden I saw an hour with a CPU utilization spike nearly of nearly 3 times the usage as any other hour in the past 24, I knew I needed to pull the trigger on that.

So, based on the recommendation of Hostgator, and following their configuration recommendations, I implemented the WP Super Cache plugin.  Turns out it required that I use permalinks, another WordPress option I’d been avoiding, so I implemented that, and then completed the configuration of WP Super Cache.  Turns out my fears of both permalinks and implementing a caching engine were unfounded; it was fairly painless, and everything seems to be working.  (I do still have a concern on the permalinks – I change the published date/time on NPOD posts that I reuse, and I wonder what will happen to the old permalink when I publish it under a new date – guess I’ve got some testing to do, and maybe some process changes are needed.)

So, now that I’ve implemented this caching engine, I’m kicking myself for not having done it long ago.  The response time for cached pages are SO much better.  Downside is that changes that I make to the theme / layout don’t show up on the cached pages until they age out (haven’t tried updating a page,) but that is pretty easy to live with, and I can delete individual cached pages if I need to force an update earlier.

But the question remains – will all these changes address the CPU utilization issues?  If it doesn’t, my next step will be looking at the database.  The database for this WordPress implementation is around 250MB, and Hostgator says they have some known performance issues with databases over 100MB, so maybe we’ll have to pursue that thread if the high utilization continues.  Unfortunately early returns are not showing any dramatic CPU reductions.  Time will tell.

UPDATE 11/11/2013:  While CPU didn’t seem to run wild overnight, it wasn’t as low as I’d hoped, so I decided to dig into the DB size issue.  Turns out the wp_options table was 108 megabytes with over 500,000 entries.  I see people complaining that theirs is 2MB with 1200 entries.  I find 366,172 rows with _transient% – sounds like a target.  Research implies these are temporary caching of items that *should* get cleaned up but apparently frequently don’t.  I also find 183,052 rows with “displayed_galleries” – sounds like NextGEN also was not doing proper cleanup.  I ran the following two SQL queries, resulting in the DB going to 412 rows with a size of 137KB.  Site seems OK after deleting the rows; time will tell on CPU usage.

DELETE FROM `wp_options` WHERE `option_name` LIKE (‘_transient_%’);

DELETE FROM `wp_options` WHERE `option_name` LIKE (‘displayed_galleries%’);”

By the way, while the backup showed 108MB for the wp_options table, and about 250MB for the entire database, the CPanel MySQL databases panel showed the WordPress DB at over 400MB – even after I deleted the 500,000 rows in the wp_options table, reducing it to under 137KB (backup).  After running the PHPMyAdmin “optimize” operation on the table, the database now shows up in CPanel at just over 16MB!   Clearly WordPress needs manual intervention from time to time to keep its database properly tuned (and I’m not sure I’m entirely there yet.)  [Early returns:  For the first full hour after completing all the above DB work, including optimization, the CPU utilization is the lowest it has been in 48 hours, while unique post views so far today are up above where they have been at this time of day for quite some time.  It’s quite possible some viewers left before they viewed the page (and kicked off the counter script) due to the slower response time in the past.]  [Later returns: This appears to have done the trick.  The highest hour of CPU since I did the wp_options cleanup is lower than the lowest hour for the prior couple of days.