[Resolved] php support: fastcgi or apache module?
I am setting up hosting for a multisite install (goal: about 1000 small sites) on a vps and I have the option of setting up “php support” as either an apache module or fastgci. Does experienced folks on here have a preference? What are the benefits of one over the other with WordPress?
I am not super savvy with all the ins and outs of hosting environments and issues. I tried searching on here, but didnt see anything one way or the other.
The difference I’ve been able to find is this:
If you want speed, use the Apache PHP module. It’ll eat resources like a pig, but it’ll be fast.
If you want resource conscious PHP processes, use FastCGI.
Either one works (I currently have a 300+ site install using FastCGI, but have had other install using mod_php).
I’m glad this thread is not closed and I sure how other jump in.
Assuming that the fundamentals of using updated code, eliminating bad plugins and activating a good caching system, I need to know from the gurus which PHP interpreter works better with WordPress sites on shared hosting.
I’ve been going back and forth between regular PHP5 (mod_suphp) and PHP5 (FastCGI) (mod_fastcgi) on my bluehost shared hosting account. There are many users/wannabe techs that say that FastCGI is obviously better, but my recent experience says the opposite! For me, the regular PHP is far more stable and better performing than FastCGI. When I had FastCGI running, I would randomly get 10 near-zombie FastCGI processes running for several minutes while visitors were getting 500 errors or garbled pages. The last bluehost tech I talked to on the phone during one of these spikes switch me back to regular PHP and said “WordPress doesn’t need FastCGI” (or doesn’t work well with it or something similar).
Here are a couple of relevant links for discussion:
SuPHP = Higher CPU but Low Memory Usage
FastCGI = Lower CPU But High Memory Usage
WordPress has an abundance of tiny database queries, multiple file/image loads and PHP is interpreted, so I think that means WordPress is already CPU intensive.
And bjourne says here:
The only problem with fcgi is that it is slightly more complicated and error prone than plain old cgi. For example, if there is a memory leak in the process that serves requests it will cause instability on the server as it slowly eats more and more memory. Memory leaks in cgi won’t be noticeable because the processes are restarted all the time. You also need a watch dog process that can restart crashed fcgi processes. Usually, the web server comes with those features builtin, but it is not always the case.
These both indicate to me that FastCGI would be better IF it was configured right.. .right?
So what say you?
I’m in the middle of researching and documenting what works for us (since it is really important to me), so even if no one responds here, I have an article started on allza.info (to be posted later this week).
FastCGI = Lower CPU But High Memory Usage
That’s why I use suPHP personally. Stupid memory limits.
So – if I have a site already configured – how do I change from fastcgi to regular cgi? I’ve reinstalled PHP using just CGI . . . and of course my site doesn’t come up
the error: The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.
What should the handler mapping be?
bloofrog, I really only have experience with bluehost. But somewhere on your account admin front end (cPanel?) there should be an option called “PHP Config” under Software/Services. Click it and then select the option for:
PHP5 – All files with the extension .php will be handled by the PHP5 engine. Current, most reliable and best performing version of PHP
That will use mod_suphp as a php interpreter.
It may take a minute or two to become fully active, but should tell you that your config change was made. If you’ve made changes to your php.ini file (in your public_html/ folder), you can replace it with a clean, default “master” copy that your host has somewhere, and then delete all other copies in your sub-directories. That should put you back to the default configuration.
I have this install on our in-house servers so I have access to the server directly not through a cpanel and such . . . I’ll do some digging . . .
think we’re on the same mission here – I too would like to know what’s the better option in WordPress. Here’s what I know:
Apart from speed, if you run PHP as FastCGI (or CGI) the advantage is user isolation. Let me explain:
Often enough you have to tweak file permissions because WordPress runs as the Apache user instead of the user who owns the files on your install. So a quick 777 will fix it – but that’s no good for security.
The other option is to have files and folders owned by Apache, but that makes finding an exploit more difficult because 1000 sites could be owned (and compromised) by the same user i.e. Apache. In fact, if WordPress needs a new folder it will be created as owned by Apache, if you run PHP as Apache Module.
So if you run PHP as FastCGI then it’ll be created as the “your user” rather than Apache. It also means WordPress has write permissions to all files because it’s executed as “you user” rather than Apache. All that together means FastCGI – on paper – sounds like the dream solution.
However, the drawbacks are in fact your (and my) observations if you do that. I also get numerous spurious 500 Internal Server errors, and I’m experience upload problems with files larger than 300kB (despite how high my PHP memory limit is). I’m using Plesk 10.4.4 instead of cPanel on a dedicated server.
I’ve written a post about my initial observations here: http://wpguru.co.uk/2012/02/the-problem-with-running-php-as-fastcgi-application/
Food for thought. To make things work smoothly, I’m currently using the Apache Module option – but I FastCGI would make my life so much easier.
If you have a virtual host with WHM, you can enable FastCGI like this:
1. Main >> Service Configuration >> Configure PHP and SuExec
2. set PHP 5 Handler to: fcgi
3. set Apache suEXEC to: on
4. press the “Save New Configuration” button
Now, to overcome 500 errors (Internal Server Error) when uploading themes, large images, etc. do this:
1. Main >> Service Configuration >> Apache Configuration >> Include Editor
2. under “Post VirtualHost Include” select “All Versions”
3. put this code in the textarea: FcgidMaxRequestLen 52428800
NOTE: the default value is only: 131072
4. press the “Update” button
5. press the “Restart Apache” button
Thanks for sharing, Luke! You’ve hit the nail on the head: the default value for FcgidMaxRequestLen is the culprit, it’s just too low by default for many applications and hence those upload errors.
Adding something larger like you suggested solves these issues. For servers without such a nice control panel, this value can be changed in httpd.conf (the Apache configuration file). On CentOS this is in /etc/httpd/conf/httpd.conf.
Once tweaked, restart Apache with ‘service httpd restart’ from the shh prompt.
Good point, Jay.
For those who aren’t familiar with the command line, the following tips may help.
As an alternative to using WHM control panel mentioned above, you can also overcome the 500 errors at the command line doing this:
1. log in through SSH (typically PuTTY.exe on the client side)
2. enter your credentials (UID & PWD)
3. now: cd /etc/httpd/conf/
4. now: pico httpd.conf
5. include the following near the top of the file (after the other <IfModules’s and before any “automatically generated” sections):
6. exit by pressing: CTRL+x
7. save by pressing: y
8. press enter to confirm writing to HTTPD.CONF
9. now: service httpd restart
This works for most servers.
However, some servers put mod_fcgid settings in a separate file, ie, /etc/httpd/conf.d/fcgid.conf. In this case, simply add the following below all of the other lines that start with “Fcgid”:
… and this my friends is one of the most comprehensive guides you’ll find on the web about this extremely complex topic.
Loving your work, Luke 😉
Thanks Jay. Ditto.
I generally learn by necessity and time is valuable, so I take detailed notes in case a situation is encountered again. The steps above are from some of those notes.
FastCGI serves my needs nicely. And, if you have high CPU usage issues, it’s a must. It does tend to use more memory (than CGI and suPHP); but, with WP, a good cache plugin can compensate if needed.
- The topic ‘[Resolved] php support: fastcgi or apache module?’ is closed to new replies.