Increasing Script Efficiency #2
Late last year, the blog came under attack and required that I work with my host’s support team to implement additional site security. And then, while we were at it, improve efficiency of the scripts. Fortunately, there has been no further attacks. Or at least; none that were able to penetrate the security measures detailed in the prior post.
But as the blog has grown in various ways, CPU utilisation has once again crept ever nearer to the thresholds my entry level plan allows. Those being, no more than 2,000 CPU seconds in any given 2 hour window. No more than 10,000 CPU seconds total over any given 24 hour window.
So it was time to relook at the various plugins I use and start making some tough calls. Something had to go.
Where we’re going, we don’t need no ‘statistics’
First on the chopping block was WP Statistics. It’s a plugin which provides — as the name might suggest — far better statistics recording than the Jetpack solution. The main thing I liked from it was the ability to show where people were landing from search engines. Even if the search terms themselves were not available. It also provided a view of hits for assets such as your images / screenshots even if they were not being loaded via post or page.
These were neat pieces of information to have, no doubt. But at the cost of upgrading to the next tier of plan? … Yeah, I can live without.
I deactivated the plugin the other night to see what sort of impact on CPU time it might have.
Unfortunately; on it’s own — it’s not enough to completely put me in the clear, but it is enough to warrant a further move from deactivated to deleted. *sigh* You shall be missed WP Statistics!
This is the one I was most worried about.
I talked recently about the addition of the Blapril 2020 page, in which I also talked about the WP RSS Aggregator plugin. For a quick refresher though: It’s the plugin that allows a WordPress blog to replicate the dynamic updating blogroll feature that otherwise makes us envious of Blogger bloggers.
It comes at a cost though. A CPU cost. It must, every so often, scan the RSS feeds of the blogs you add it to, checking for updates and adjusting the blogroll output accordingly.
The main change I’d made with the Blapril 2020 page was, of course, to add a number of entirely new blogs to my already rather large list.
I was pushing the line for utilisation before, and this was enough to cross over.
I was beginning to fear that I might have to cut back on the number of blogs I include in the dynamic blogroll, and keep most in a more typical (for WordPress) static list. I still might, but I’m trying a few things first to ward off this requirement.
Namely, one of the things you can do is adjust the interval at which you scan for an update. Back when I was starting out and had fewer blogs, I could get away with a default scan time of 1 hour. Now… not so much. I moved the default up to a 2 hourly update interval at the time of the first attack and efficiency enhancements.
What I’ve done today is attempt to assess each blog and give them a custom update interval depending on their post schedule. Some are sitting on a 2- or 4-hourly check, with the other end of the spectrum sitting at once a day or even once a week updates if their posting schedule is measured more on a monthly time scale than days.
I also had to segregate the updates between the on the hour and the on the half hour cron job triggers I’ve set, to further minimise the number of updates running at the same time.
I think this will do the trick; but I won’t really know for another 24 hour cycle of so due a combination of how the hosts reporting updates and the fact that triggering config changes to the update schedule forces an update then and there, too. So I’ve ended up massively exceeding the daily CPU second count for the current 24 hour reporting period. The two hourly updates have looked good since I’ve completed this work though!
I might still have to consider more drastic cuts, but I’m really hoping not to. That the work done today will be sufficient. I did entertain the notion of upgrading to the next plan… But for a hobby blog I think the cost would just be a tad excessive. …Right? Right. …Right? ;)
This was a post for Blapril 2020, the annual blogging event (albeit usually as Blaugust), brought forward to help bring a sense of community during the challenging time of COVID-19. Blaugust is an event aiming to welcome new blogger blood into the fold and revitalise those who’ve been at it a little longer.
The Blaugust Discord is still available to join in, year round!