WordPress: PHP CGI Vs PHP FCGI
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.
21 Comments
Shane
Nice article; your explanation between the two was good 🙂
Paul Robinson
Thanks Shane, I thought it might end up a little complicated, but I guess it didn’t. 😉
Huge thanks to my host (DreamHost) who helped me a lot with discovering this problem.
Alex
A niche article indeed, but thanks for writing it…I needed to decide which way to go (CGI or FastCGI) and your experiences helped me in making that decision!
Paul Robinson
No problem. Glad my experiences with this have helped.
I would have replied earlier but my GFX card died on me. 🙁
Justin Germino
I just switched to a new VPS hosting from Shared Hosting and having a lot of http 500 and 504 gateway timeouts when hitting my site or trying to upload live writer posts, I wasn’t having the same problem on my shared hosting but remembered that I was using PHP as CGI and not FASTCGI on shared hosting so this may be the problem.
Paul Robinson
Hi Justin,
Sorry I haven’t replied to you comment sooner. I was having server problems & never got an email to tell me about your comment.
Like I said below I’ve just moved to VPS hosting & by setting PHP to CGI and setting up WP-SuperCache correctly I’ve reduced memory usage from over 100-130MB to just under 60MB and when under heavy load it doesn’t increase much at all.
Haneez Haroon
I recently moved to dedicated hosting and it just took all my memory away and i was worried about the situation.
Thanks a lot for sharing your experience.
Paul Robinson
Hi Haneez,
No problem. I have just moved this site to a VPS as it has outgrown shared hosting & while it is running much faster I have just tweaked it further by installing WP-SuperCache & setting PHP to CGI mode.
It seems to have dropped PHP usage to nearly 0 as the server only needs to use Apache processes until a cached page needs to be refreshed.
Wine Dine
Thanks for the info, the cache renewal might just be what I should look at to make http://winedinedaily.com run faster..
Paul Robinson
Hi,
While you aren’t running WordPress, from what I can see, the principles are the same.
I do have to stress that it all depends on your server setup though, there isn’t a one size fits all solution unfortunately.
When running on a VPS it’s important to note that you may be better off running with PHP in FCGI mode with Nginx. While it seems like it eats all of your memory instantly, it’s actually kept in cache and ready to use. Again though when it comes to web servers one size doesn’t fit all.
Jay Versluis
Paul,
wonderful article – I had huge troubles getting FastCGI to work properly on my setup running into the same problems as you did. The Apache Module seemed to work fine but that caused other issues. I never thought of trying good ol’ fashioned CGI – which works without memory issues.
Thank you so much for sharing – it’s going into my list of links to keep 😉
Paul Robinson
Hi Jay,
No problem. I’m happy you found the article helpful.
The irony is that I now run Nginx (check via FireBug’s headers if you like) which forces me to run FastCGI and my site (minus a few configuration hiccups) has never been faster. Beats me. 🙂
Jared
Ugh, sounds like I may have to go to support instead of fastcgi. With 6 wordpress sites, I’m using up 2gb of memory. It still seems like a lot for only 6 sites…
Paul Robinson
Jared,
That is a huge amount of memory.
I have 5 websites on this VPS. 4 are WordPress, 1 is a Codeigniter project I custom built. They run on a total of 360MB of RAM. I use Nginx (instead of Apache), PHP FCGI, Xcache, and heavy file caching on all sites. I even custom built a file caching system for the CI project.
I’m a stickler for getting as much as I can out of the server before admitting defeat & increasing the RAM. Sometimes it’s better to save your sanity & just pay the extra, but in my opinion 2GB for 6 sites is quite large.
If you need any tips I would look at Nginx if possible, heavy caching such as W3 Total Cache & XCache if possible.
Akash (a.k.a Sky)
i know a bit of jquery, html and css. All three of them. But i dont even know full form of php. Can U guide me what to and how to and if possible where to start learning php ? Thanks in advance. 🙂
Paul Robinson
Hi Akash,
I keep meaning to write some ‘Starting with PHP’ style tutorials, but never get round too it.
My best advise, although a total cliché, is to read a PHP book. This one, for example, was my first PHP book. I did learn before that using the PHP website & playing around, but honestly there is not substitute for a book.
Ron
I use virtualmin/webmin on a VPS with 512 ram hosting 10 domains. Switching from fcgi to cgi reduced the memory in use from 350mb to 85mb. That’s pretty amazing.