Talk:PHP FastCGI

There are user comments in the article. Please limit user conversation and opinion to talk pages. -- Scjessey 16:30, 16 Jul 2006 (PDT)


 * User Comment
 * "/dh/" is an alias for "/usr/local/dh" (at least on my login server, cupcake)
 * When I left this as "/dh/cgi-system/php5.cgi" my MediaWiki site broke.
 * When I changed the above path to "/usr/local/dh/cgi-system/php5.cgi" it worked fine - and sped up appreciably. YMMV though, "/dh/" might link to a different place on your server
 * Also, something (apache? CGI?) seemed to have some trouble with the blank lines (I got error messages for Lines 2 and 4 exactly as entered above), so I'd recommend using the following for your php5-wrapper.fcgi (exactly as entered):

export PHP_FCGI_CHILDREN=3 exec /usr/local/dh/cgi-system/php5.cgi
 * 1) !/bin/sh
 * End User CommentFungiblename 05:59, 18 Jul 2006 (PDT)

I actually found that using the above caused about four php5.cgi instances to spawn on every request and they would stay active for about an hour or so - each new request on my wiki would spawn a new instance and slow things down, which is exactly what this is supposed to avoid. I just deleted the "Children", and got a single persistent process:

exec /usr/local/dh/cgi-system/php5.cgi
 * 1) !/bin/sh

Then things sped up quite nicely. 12:39, 7 Aug 2006 (PDT)

Make sure there are no CRLFs in php5-wrapper.fcgi!
I was getting "comm with (dynamic) server abort" error when there were CRLFs in php5-wrapper.fcgi followed by the infamous "incomplete headers" error.

--Darren996 01:12, 26 Jan 2007 (PST)

Account may be disabled when using FastCGI with a custom php.ini
Use a custom php.ini is allowed. But if it hurts the server, that's not good and your account will be disabled. Jcisio 09:40, 27 June 2007 (PDT)
 * Uhmm.. no? That's completely wrong and unfounded information. Why do you say it "hurts" the server? In most cases it does the complete opposite. I'd say the only reason an account would be disabled for using fcgi and a custom php.ini, is when the user attempts to increase the maximum execution time for a script, essentially consuming well beyond the CPU cycles they should be. Memory limits are not an issue, as we're limited to 100megs anyways. Neither of which however "hurts" the server, but they do (or could) ultimately affect other users on it. Perhaps that's what you meant?
 * Right. I use FastCGI with a custom php.ini all the time.  Actually what I do is use the DreamHost supplied binary (not mine) and redirect it to readout my own php.ini.  This php.ini is actually designed to be more secured by implementing a couple of suggestions that I would like seen done server wide and is usable on my own server and I also added a few extensions.  Suhosin is one extension that is on the suggestions list but it is already running on my site.  It causes no side-effects from what I've seen.  Anyways using the Dreamhost binary has the major advantage that your site will always use the newest binary available.  Granted you still have to manage your extensions and re-build as necessary.  There is always going to be some cost of self-manage here.

Not Reliable
In my experience on Dreamhost, FastCGI isn't reliable. I don't use it any more. Usually my Mediawiki & Wordpress run ok, and I notice pages loads that are 1-2 seconds faster. But sometimes the page loads hang forever :-(. If it works for you, I'd love to hear it. I use:

.htaccess Options +ExecCGI AddHandler fastcgi-script fcg fcgi fpl AddHandler php5-fastcgi .php Action php5-fastcgi /php5-wrapper.fcgi

php5-wrapper.fcgi export PHP_FCGI_CHILDREN=3 exec /usr/local/dh/cgi-system/php5.cgi --Gadlen 04:47, 2 January 2010 (UTC)
 * 1) !/bin/sh