A few days ago I started to realize that my stats said I was getting a huge amount of errors. By errors I mean HTTP status codes such as 500 (Internal Server) errors. Obviously that’s something you don’t want to happen, especially on a site about coding, the irony of it would be clearly abundant.
What Was Causing The Internal Server Errors?
As mentioned on my previous post about optimizing WordPress for shared servers, WordPress can actually use a fair amount of memory. One of the ways my host deals with over stepping your memory limit is to cut the process that pushed your *nix user over the limit. If it was a PHP process then the person browsing the site will end up receiving an error (such as a 500) instead of the page.
Since I was running WP Super Cache I couldn’t understand why I was having so many problems, I was also using the Timthumb Mod Rewrite mod (also mentioned it the previous post). Both of these should have resulted in PHP not running until a cache file needed to be renewed, but it didn’t. Turns out that the problem was caused by the type of PHP I was running.
CGI Vs FastCGI
My host allows PHP to be ran as CGI or FastCGI (FCGI). The latter creates as many processes as instructed & uses them to process as much as possible, even keeping them alive after they have finished their commands. PHP as CGI however creates a process to complete 1 instruction & then kills it.
It turns out that when running under FastCGI (which my host automatically picks) needing to create a new cache file would create a new FastCGI based PHP process to serve the page as normal, however after it was finished it would stick around and wait for other connections. I also run another site on the same server & under the same user account, this also seemed to create a FCGI PHP process, but being a forum it always runs PHP. These two processes running together & staying active easily combined (at certain times) to step over my 90MB memory limit.
To help combat this I changed my domain running WordPress to CGI. This meant that when a cache renewal was needed it would be created & the PHP process would die. Now there would only be the FastCGI process created by the forum. WordPress’ wouldn’t hang around and cause me to go over my memory limit. Why? Well because when the CGI process creates a cache page & dies it won’t be around very long. That reduces the chance of the combined total being over 90MB from all the time to only times when a cache page is being created & that isn’t very often.
At first I wasn’t convinced all this would work, but since I have swapped over to CGI & working in tandem with Super Cache I can say I have never ever seen my blog run so fast. Also I have seen a dramatic reduction in HTTP 500 status codes.
There may be some of you thinking that FastCGI is faster. Yes, that’s (likely) true since it doesn’t have to initialize PHP every time a request is made. However on a low memory environment, when running WordPress with Super Cache, CGI seems to be a better combination.
Maybe this has been of some help & maybe it hasn’t, but I just wanted to share my little adventure into CGI/FCGI in case someone found it useful. Also I must admit I tend to stick to coding so I’m not the most experienced in this area. If anyone has any tips or anything I’d love to hear them. I’ll be back to posting tutorials, as normal, tomorrow so don’t worry.