PHP, Apache, Mongrel cluster

I have a server that is running a couple of PHP applications where I
also want to run a couple of Rails apps via mongrel cluster. I was
thinking that I would run Apache on a separate port, say 9000, then use
nginx as the primary web server and handler of virtual hosts. The
nginx virt hosts would point to Apache for all of the PHP requests (as
opposed to fastcgi PHP). Has anyone had any experience with this type
of stack? Bad idea? Good idea?

On Wed, 2008-01-16 at 19:38 +0100, Lance D. wrote:

I have a server that is running a couple of PHP applications where I
also want to run a couple of Rails apps via mongrel cluster. I was
thinking that I would run Apache on a separate port, say 9000, then use
nginx as the primary web server and handler of virtual hosts. The
nginx virt hosts would point to Apache for all of the PHP requests (as
opposed to fastcgi PHP). Has anyone had any experience with this type
of stack? Bad idea? Good idea?

Why not just use PHP+FCGI? Apache adds a lot of overhead with little
apparent gain in this configuration.

Cliff

On Wed, 16 Jan 2008 19:38:16 +0100
Lance D. [email protected] wrote:

Has anyone had any experience with this type of stack? Bad idea? Good idea?

Actually I have one such setup at my previous job that I havent touched
for more than a year and it just works.

Nginx talks to apache on the same machine on 127.0.0.1, that apache runs
mod_backhand to talk to 5 other apache servers in HA manner.

Jure Pečar

Lance D. wrote:

Cliff W. wrote:

Why not just use PHP+FCGI? Apache adds a lot of overhead with little
apparent gain in this configuration.

Cliff

The Rails apps still use PHP for a couple of tasks (file uploads) and
there are 3-4 PHP/static sites. My understanding (perhaps I’m wrong)
is that I would need a PHP/Fastcgi instance for each site/app, which
would presumably be more overhead than the single Apache instance. Is
this not the case? Thanks for the response!

actually as far as i have seen it in my config, the nginx/php/apache
proxy would work good, only when you have few php applications, and a
lot of static content. so let’s say 2 3 php pages, that are being
accessed once in a while, and you can work it out with apache.

but, in the case of using constantly php, i would suggest going for
php-fastcgi/nginx. why ? it makes pretty much no sense in my opinion
having nginx sending the php to apache, then serving it, when it could
do it all by itself.

one note though, when using php-fastcgi, i would suggest using
lighthttpd’s spawn-fcgi program. i had issues with the init scripts
found for php-fascgi.

so yeah it took me a few, but i got nginx/php-fastcgi running. with
lighty spawn-fcgi. everything looks pretty cool/fast.

On Thu, 2008-01-17 at 14:06 +0100, Lance D. wrote:

there are 3-4 PHP/static sites. My understanding (perhaps I’m wrong)
is that I would need a PHP/Fastcgi instance for each site/app, which
would presumably be more overhead than the single Apache instance. Is
this not the case? Thanks for the response!

Apache + PHP is going to use far more resources than FCGI+PHP.
Unless you need some esoteric feature of Apache (say, mod_svn), it’s
really best to run only Nginx.

Regards,
Cliff

Cliff W. wrote:

Why not just use PHP+FCGI? Apache adds a lot of overhead with little
apparent gain in this configuration.

Cliff

The Rails apps still use PHP for a couple of tasks (file uploads) and
there are 3-4 PHP/static sites. My understanding (perhaps I’m wrong)
is that I would need a PHP/Fastcgi instance for each site/app, which
would presumably be more overhead than the single Apache instance. Is
this not the case? Thanks for the response!

On Thu, 2008-01-17 at 16:48 +0100, Stefanita rares Dumitrescu wrote:

one note though, when using php-fastcgi, i would suggest using
lighthttpd’s spawn-fcgi program. i had issues with the init scripts
found for php-fascgi.

I concur. The spawn-fcgi program from Lighttpd is how I run PHP as
well.

Cliff

Lance D. wrote:

Cliff W. wrote:

On Thu, 2008-01-17 at 16:48 +0100, Stefanita rares Dumitrescu wrote:

one note though, when using php-fastcgi, i would suggest using
lighthttpd’s spawn-fcgi program. i had issues with the init scripts
found for php-fascgi.

I concur. The spawn-fcgi program from Lighttpd is how I run PHP as
well.

Cliff

Thanks for all of the responses … just to clarify: will I need a
separate PHP-fastcgi instance for each virtual host?

not at all there will be 1 single daemon to listen for all connections
made to it. you can proxy all requests to it.

Cliff W. wrote:

On Thu, 2008-01-17 at 16:48 +0100, Stefanita rares Dumitrescu wrote:

one note though, when using php-fastcgi, i would suggest using
lighthttpd’s spawn-fcgi program. i had issues with the init scripts
found for php-fascgi.

I concur. The spawn-fcgi program from Lighttpd is how I run PHP as
well.

Cliff

Thanks for all of the responses … just to clarify: will I need a
separate PHP-fastcgi instance for each virtual host?

Cliff W. wrote:

If you combine spawn-fcgi (from lighttpd) with daemontools, you get an
indestructible php-fcgi, simply killall -9 php-cgi (or your distro’s
equivalent) and php will automatically be restarted :wink:

The benefit here is that if php craps out, daemontools will notice and
restart it.

sample ‘run’ file:
#!/bin/sh

CHILDREN=“25”

FCGI_HOST=127.0.0.1
FCGI_USER=php
FCGI_GROUP=php
FCGI_BIN=/usr/bin/php-cgi
FCGI_PORT=1705

test -x $FCGI_BIN || { echo “$FCGI_BIN not installed”;
if [ “$1” = “stop” ]; then exit 0;
else exit 5; fi; }

export SHELL="/bin/bash"
exec /usr/bin/spawn-fcgi -n
-f $FCGI_BIN
-a $FCGI_HOST
-p $FCGI_PORT
-u $FCGI_USER
-g $FCGI_GROUP
-C $CHILDREN

Erik VanBruken wrote:

Hello,

You are saying that it is better to follow this documentation page:
http://wiki.codemongers.com/NginxFcgiExample

Than this one:
http://blog.kovyrin.net/2006/05/30/nginx-php-fastcgi-howto/

i tried both of them .

running the daemon listed there, did not get me so excited, as after a
number of requests it went down, and not restarted.

i did not want to spend more time with it, so i chose the lighttpd
alternative, which was fast to do, and worked nice.

Hello,

You are saying that it is better to follow this documentation page:
http://wiki.codemongers.com/NginxFcgiExample

Than this one:
http://blog.kovyrin.net/2006/05/30/nginx-php-fastcgi-howto/

In Ubtuntu there is a problem installing daemontools, there is no
/etc/inittab…

On Jan 24, 2008 3:23 PM, Stefanita rares Dumitrescu

I have found a workaround concerning /etc/inittab not being used in
Ubuntu, here it is: http://www.froyn.net/blosxom/blosxom.cgi/2007/1/12

Allen, can you make a quick tutorial on how daemontools works? Where
should your run file go and with which ownership and permission?

Best regards,

nginx + spawn-fcgi + daemontools are now running. spawn-fcgi is
invincible, I kept killing it, and it always came back!

Thanks Allen and Igor for the tips.

On 25 Jan 2008, at 12:02, Thomas wrote:

I have found a workaround concerning /etc/inittab not being used in
Ubuntu, here it is: http://www.froyn.net/blosxom/blosxom.cgi/2007/1/12

Allen, can you make a quick tutorial on how daemontools works? Where
should your run file go and with which ownership and permission?

There’s good info about daemontools at DJB’s site:

http://cr.yp.to/daemontools/faq.html

Thomas wrote:

nginx + spawn-fcgi + daemontools are now running. spawn-fcgi is
invincible, I kept killing it, and it always came back!

Thanks Allen and Igor for the tips.

im gonna try getting daemontools running as well :slight_smile: can you share the
config for that please?

Basically here are the steps:

  1. Install daemontools, using this documentation:
    http://cr.yp.to/daemontools/install.html. Follow exactly the steps and
    use sudo when you think it is needed. It took me a few tries before
    correctly installing it. In Ubuntu, the daemontools-installer didn’t
    work for me.

  2. See if svscan is started, if not follow the link I posted for
    ubuntu, and replace the dashes in the runlevels with spaces. Now
    reboot computer or use: sudo start svscan

  3. Then create a directory inside /service I called mine spawn-fcgi,
    and inside that directory create a file called run, and use Allen’s
    template to suit your needs. Make the run file executable.

Then, spawn-fcgi will be automatically started and monitored by
daemontools. Try killing it, and enjoy :slight_smile:

On Jan 25, 2008 4:30 PM, Stefanita rares Dumitrescu

Hi,

In my PHP+nginx combo, I have a little problem.

Let’s say I have phpmyadmin installed in /var/www/phpmyadmin,

in nginx.conf I must specify fastcgi_param SCRIPT_FILENAME
/var/www/phpmyadmin$fastcgi_script_name;

I tried using fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;

but it doesn’t work. In the browser I get a “no input file specified”.

How to solve this issue. I know it’s meaningless, but it’s annoying to
have to remember to change the SCRIPT_FILENAME each time I move or
rename my php apps directory.

Thomas wrote:

Basically here are the steps:

  1. Install daemontools, using this documentation:
    http://cr.yp.to/daemontools/install.html. Follow exactly the steps and
    use sudo when you think it is needed. It took me a few tries before
    correctly installing it. In Ubuntu, the daemontools-installer didn’t
    work for me.

  2. See if svscan is started, if not follow the link I posted for
    ubuntu, and replace the dashes in the runlevels with spaces. Now
    reboot computer or use: sudo start svscan

  3. Then create a directory inside /service I called mine spawn-fcgi,
    and inside that directory create a file called run, and use Allen’s
    template to suit your needs. Make the run file executable.

Then, spawn-fcgi will be automatically started and monitored by
daemontools. Try killing it, and enjoy :slight_smile:

On Jan 25, 2008 4:30 PM, Stefanita rares Dumitrescu

uber cool. i remember i already did the daemontools thingie on a qmail
server. but i forgot what was it’s purpose for :smiley: thanks. rocks

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs