Title: php support: fastcgi or apache module?
Last modified: August 19, 2016

---

# php support: fastcgi or apache module?

 *  Resolved [coloradocolin](https://wordpress.org/support/users/coloradocolin/)
 * (@coloradocolin)
 * [15 years, 1 month ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/)
 * Hi,
 * 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.

Viewing 13 replies - 1 through 13 (of 13 total)

 *  [Tim Moore](https://wordpress.org/support/users/tmoorewp/)
 * (@tmoorewp)
 * [15 years, 1 month ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2022881)
 * 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).
 *  [Ron Strilaeff](https://wordpress.org/support/users/ronstrilaeff/)
 * (@ronstrilaeff)
 * [14 years, 4 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023192)
 * 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:
 * [Jacob Tirey says here](http://boomshadow.net/tech/php-handlers/):
 * > 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](http://www.webhostingtalk.com/showthread.php?t=958588):
 * > 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](http://allza.info/?p=783)(
   to be posted later this week).
 * Thanks, Ron
 *  Moderator [Ipstenu (Mika Epstein)](https://wordpress.org/support/users/ipstenu/)
 * (@ipstenu)
 * 🏳️‍🌈 Advisor and Activist
 * [14 years, 4 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023193)
 * > FastCGI = Lower CPU But High Memory Usage
 * That’s why I use suPHP personally. Stupid memory limits.
 *  [bloofrog](https://wordpress.org/support/users/bloofrog/)
 * (@bloofrog)
 * [14 years, 4 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023194)
 * 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?
 *  [Ron Strilaeff](https://wordpress.org/support/users/ronstrilaeff/)
 * (@ronstrilaeff)
 * [14 years, 4 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023195)
 * 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.
 *  [bloofrog](https://wordpress.org/support/users/bloofrog/)
 * (@bloofrog)
 * [14 years, 4 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023196)
 * Thanks Ron
    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 . . .
 *  [Jay Versluis](https://wordpress.org/support/users/versluis/)
 * (@versluis)
 * [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023198)
 * Hi Ron,
 * 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/](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.
 *  [Luke America](https://wordpress.org/support/users/lukeamerica2020/)
 * (@lukeamerica2020)
 * [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023199)
 * **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
 *  [Jay Versluis](https://wordpress.org/support/users/versluis/)
 * (@versluis)
 * [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023200)
 * 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.
 *  [Luke America](https://wordpress.org/support/users/lukeamerica2020/)
 * (@lukeamerica2020)
 * [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023201)
 * 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): <IfModule fcgid_module> FcgidMaxRequestLen
   52428800 </IfModule> 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”:
    FcgidMaxRequestLen 52428800
 *  [Jay Versluis](https://wordpress.org/support/users/versluis/)
 * (@versluis)
 * [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023202)
 * … 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 😉
 *  [Luke America](https://wordpress.org/support/users/lukeamerica2020/)
 * (@lukeamerica2020)
 * [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023203)
 * 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.
 *  [Luke America](https://wordpress.org/support/users/lukeamerica2020/)
 * (@lukeamerica2020)
 * [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023204)
 * Also, here’s a good article describing some PHP handler options with regard to
   WP.
 * [Php Handlers](http://boomshadow.net/tech/php-handlers/)

Viewing 13 replies - 1 through 13 (of 13 total)

The topic ‘php support: fastcgi or apache module?’ is closed to new replies.

## Tags

 * [BluHost](https://wordpress.org/support/topic-tag/bluhost/)
 * [fastcgi](https://wordpress.org/support/topic-tag/fastcgi/)

 * In: [Networking WordPress](https://wordpress.org/support/forum/multisite/)
 * 13 replies
 * 7 participants
 * Last reply from: [Luke America](https://wordpress.org/support/users/lukeamerica2020/)
 * Last activity: [14 years, 2 months ago](https://wordpress.org/support/topic/php-support-fastcgi-or-apache-module/#post-2023204)
 * Status: resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics