Unless you’re interested in the technical aspects of WordPress blogging, stop here.
I tried to get on the blog late yesterday afternoon and I kept getting Internal Server Errors and 404 Page Not Found errors. What this means is that the script processes that feed this web site’s content were running out of memory and getting canceled. This can happen during times of very heavy traffic and (I believe) when the shared server where the site is located has very heavy traffic on other sites.
This site uses WordPress caching technology (WP Super Cache, Widget Cache and Plug-in Cache) so that when the pages don’t change, the software will feed you a copy it created earlier, requiring hardly any computer resources. That’s great in theory. However, this is a heavily-commented blog meaning that every time someone leaves a comment on an article, that page has to be built again to include the new comment.
Back to yesterday. Analysis of yesterday’s site statistics shows strong activity, but not remarkably strong, and not the heaviest of the month. The peak load yesterday was about 11.5 pages a minute (which doesn’t seem all that much) from 5 pm to 6 pm. Still, generating a page with a couple hundred comments on it can take a while, and if a few requests collide they can start a jam just like cars on the highway.
This brings me, finally (!) to what this article is about. Last night at 8:20 pm I made a significant change in how the site works. It’s called FastCGI and it’s a trade off between memory and speed. In theory, it should smooth out the memory usage (albeit at a high level) and make the scripts run faster, making it less likely to jam up.
Normally FastCGI isn’t very helpful when caching is enabled, but on this blog with lots of comments, I think it might help, and perhaps help a lot. FastCGI is technically more complex leading the down side of more things potentially to go wrong.
So if you notice performance today different from yesterday (or not), leave a comment.