Ruby Forum NGINX > php fastcgi support - how do u do it?

hi, folks, I'm thinking of using nginx (quite obviously!!!) for one of 
my
deployments with php. Now since nginx doesnt do cgi, the only way to do
nginx with php is using fastcgi. The question now is, how, and in what 
way?
I'd like to gather some feedback from the list - if you use nginx with
fastcgi php, how do you implement your fastcgi? Using the fastcgi script 
as
provided by php, or using lighttpd's script, or?

-jf

--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not
help."
-- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228

use php-fpm. it's a patch to php source. it's the best way to manage
fastcgi pools/engines.

anything else is hokey and some don't even work properly.

Could you highlight some advantages/disadvantages of php-fpm vs
lighttpd_spaw_fcgi ?
Now, I�m using lighttpd_spaw_fcgi, but I�m looking for a good reason
to change to php-fpm

spawn-fcgi did not work properly for me. i've mentioned it in the past.

it didn't properly recycle engines or honor the PHP_FCGI_MAX_REQUESTS
and it still required something to trigger it.

php-fpm is built-in to PHP, it matures PHPs fastcgi implementation,
fixes some bugs, has some acceleration features built in, makes
managing multiple fastcgi pools a breeze, it has proper execution
timeouts, honors child request counts, gracefully reloads engines,
allows for overrides of ini settings, seems just like nginx with its
multiple restart/reload options, i could go on and on. a better
website/comparison/etc needs to be done, but i can tell you i've tried
them all and php-fpm is the -best- and i consider -only- proper way
now to do php fcgi management, period.

That looks awesome! Did you know a better tutorial then this one:
http://blog.sonnoprofondo.com/2008/04/30/nginx-php-php-fpm-on-debian-etch-40/
I�ll try today.

honestly, i looked for a couple things and it looks like he's got it
covered. you may want to customize your php ./configure thing but as
long as you patch it you'll have php-fpm support :)

The path does not works with php 5.3, but works fine with 5.2.6
Did you have any tip for optimizing php to low RAM env like VPS?
Even if I start only 1 child, it eats 25MB of virtual memory (a lot
more than lighttpd spaw fcgi)
I�ll see what more can I do.

you might ask on the php-fpm group for tips. i wouldn't think it adds
any additional memory usage, maybe the parent process presents the
total number of children somehow weird, i don't know.

either way, spawn-fcgi for me did not recycle engines so any php
memory leaks will continue to occur - without PHP_FCGI_MAX_REQUESTS in
action.

http://groups.google.com/group/highload-php-en  is the english group for 
php-fpm

On Fre 11.07.2008 01:02, Marcos Neves wrote:
>That looks awesome! Did you know a better tutorial then this one:
>http://blog.sonnoprofondo.com/2008/04/30/nginx-php-php-fpm-on-debian-etch-40/
>I?ll try today.

maybe this entry.

http://alword.wordpress.com/2008/06/19/high-performance-php/

yes, my own blog.

BR

Aleks

Just my +1 for php-fpm, although I haven't got round to using it in
production yet.

I've been running PHP/FCGI using a home-made set of scripts, based
around my version of Alexey Kovyrin�s PHP�FCGI spawn script, along
with some init/chkconfig tools. It worked fine, and although there was
never a graceful restart, I never had any major problems with it.

I read on this list about php-fpm and intended to try it out, but
because what I had worked, I only did so yesterday. When I did, I was
delighted to see how much more neatly it does everything I'd done in
my scripts, as well as providing excellent additions such as signal
support for useful functions and a fix for the "blank 200 page" problem.

Given how well it apparently runs in much more heavily-loaded
environments than mine, I'm going to try this out on the next
available project, and I suspect I'll be using it from now on. Thanks
to Andrei for writing it, and to everyone who championed it. Shame I
didn't get round to it earlier.

Best wishes,
Igor

Another vote up for php-fpm here

I converted slowly over last 2 weeks by patching php5.2.6 and using it 
with
nginx0.6.31

But yea documentation is kinda short but not really required as such, I 
know
russian as is so wasnt too bad :p


My experience is very positive

Previous Setup:
*3x servers with lighttpd1.4.19 for php
*25x servers with nginx0.6.31 for file downloads via x-sendfile and file
uploads via lighttpd1.5+mod_uploadprogress (im waiting for the nginx
uploadprogress module to be more stable)
New setup
 *3x servers with nginx0.6.31 and php-fpm patch for php5.2.6
*25x servers remain same


Before the php processes used to go gaga resulting in http 500 errors, 
also
when i tryied killing them via "killall lighttpd && killall php-cgi" 
some of
the php processes would stick around and i had to manually kill -9 them. 
now
php-fpm takes care of all that, so reliabilty improved markedly

What can i say i am very happy with this patch! and i hope it ends up in 
the
default php setup


Regards

On 7/15/08, nginx. mailinglist <nginx.mailinglist@xinio.info> wrote:

> What can i say i am very happy with this patch! and i hope it ends up in the
> default php setup

Andrei has said once he considers it "ready" and feature complete he
will change the license to be PHP core compliant so it can be put into
PHP core (assuming they allow it...)

There's already a "bug"/feature request in PHP's system for it, but it
was closed/put on hold due to the license incompatibility.

I am pretty sure they'll put it in, as he's already patched at least
one FastCGI/PHP bug in PHP core in the past that I've seen in the
changelog. But here's how to help: tell everyone in the world to use
it, and when the time comes, put pressure on the PHP team to get it in
to the core. If they realize not only that it works well but tons of
people actually use it and want it, I can't see any reason they
wouldn't.

Everyone I've told about php-fpm who has tried it loves it. I've
converted every server I maintain at work and at home to using it too.

For a shared hosting, what are the advantages of php-fpm over mod_php?

On 7/15/08, Marcos Neves <marcos.neves@gmail.com> wrote:
> For a shared hosting, what are the advantages of php-fpm over mod_php?

You can setup a separate fastcgi pool for each user. That way if their
scripts get exploited, the only files they'll be able to mess with are
that user.

No more "www-data" or the webserver user owning every uploaded file on
the system.

Also, you'll be using FastCGI, not mod_php, which is tied in to the
webserver. From the looks of it, based on Lighty, nginx, Zeus, etc...
most people consider FastCGI the better method, since it does not tie
up the webserver threads/processes/whatever with processing PHP. It
should be more scalable. I think Litespeed's mod_php might work well
too, but again - unless you can define a different uid/gid for each
vhost and configure suEXEC how you want, different FastCGI pools is
still the way to go.

I'd say php-fpm is even more useful for shared hosting since you can
easily define multiple pools (one for each user for instance) - that's
how I use it right now. The other key benefit (apache-style process
spawning) is coming soon, not quite finished yet. Between both of
those, that takes care of my two key desires.

When you say "You can setup a separate fastcgi pool for each user", you 
mean
system user?
Or is it possible with virtual users or something easier to manager like
virtualusers from pure-ftpd?
Using open_basedir for each user wouldn´t be enought?

Have PHP proccess runing outside the webserver is really a nice thing,
cause if it had any problem, only the php scripts will be affected ! :)

On 7/15/08, Marcos Neves <marcos.neves@gmail.com> wrote:
> When you say "You can setup a separate fastcgi pool for each user", you mean
> system user?
> Or is it possible with virtual users or something easier to manager like
> virtualusers from pure-ftpd?
> Using open_basedir for each user wouldn´t be enought?
>
> Have PHP proccess runing outside the webserver is really a nice thing,
> cause if it had any problem, only the php scripts will be affected ! :)

System user.

Although you might be able to use something like nss-mysql to manage
users in a mysql database and not physically in /etc/passwd and such.
As long as the system understands the getpwnam() and all those calls
(which I believe is what the nss library provides) I think you should
be cool.

On Tue, Jul 15, 2008 at 6:11 PM, Igor Clark <igor@pokelondon.com> wrote:

>
> When I did, I was delighted to see how much more neatly it does everything
> I'd done in my scripts, as well as providing excellent additions such as
> signal support for useful functions and a fix for the "blank 200 page"
> problem.
>

sorry - got more info on these (signal support for useful functions)? 
and
what's that "blank 200 page problem" that you mention about?

-jf

--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not
help."
-- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228

Hi,

On 16 Jul 2008, at 03:23, Jeffrey 'jf' Lim wrote:

> On Tue, Jul 15, 2008 at 6:11 PM, Igor Clark <igor@pokelondon.com>  
> wrote:
>
> When I did, I was delighted to see how much more neatly it does  
> everything I'd done in my scripts, as well as providing excellent  
> additions such as signal support for useful functions and a fix for  
> the "blank 200 page" problem.
>
> sorry - got more info on these (signal support for useful functions)?


 From http://php-fpm.anight.org/docs.html

"Master process understands signals:

SIGINT, SIGTERM - immediate termination

SIGQUIT - graceful stop

SIGUSR1 - re-open log file

SIGUSR2 - graceful reload of all workers + reload of fpm conf/binary"

> and what's that "blank 200 page problem" that you mention about?


Sometimes PHP running in the built-in FastCGI mode, rather than
returning a 500 on error condition, just throws a 200 and a blank
page. It can be frustrating and make things difficult to debug,
because you can't initially see where the error's happening. php-fpm
adds the php.ini option fastcgi.error_header which means you can force
your own HTTP status code and message, as per the example on the php-
fpm site:

fastcgi.error_header = "HTTP/1.0 550 Server Made Big Boo"

More details at 
http://php-fpm.anight.org/extra_features.html#error_header
  - or Google English translation here: 
http://66.102.9.104/translate_c?hl=en&sl=ru&tl=en&u=http://php-fpm.anight.org/extra_features.html&usg=ALkJrhi7P2ZW5JySwTqZE2TLMLx2AJRE3w#error_header

Cheers
i

On Tue, Jul 15, 2008 at 12:58:36PM -0700, mike wrote:
> On 7/15/08, Marcos Neves <marcos.neves@gmail.com> wrote:
> > For a shared hosting, what are the advantages of php-fpm over mod_php?
> 
> You can setup a separate fastcgi pool for each user. That way if their
> scripts get exploited, the only files they'll be able to mess with are
> that user.

mod_suphp can do that as well.

> I'd say php-fpm is even more useful for shared hosting since you can
> easily define multiple pools (one for each user for instance) - that's
> how I use it right now. The other key benefit (apache-style process
> spawning) is coming soon, not quite finished yet. Between both of
> those, that takes care of my two key desires.

but is apache style process spawning really a good idea? i mean i'm
replacing apache with nginx because the idea of apache's scaling is
''thread/fork as much as you can, as soon as you can and not a
thread/process less'' :-)

Almir Karic ha scritto:
>> easily define multiple pools (one for each user for instance) - that's
>> how I use it right now. The other key benefit (apache-style process
>> spawning) is coming soon, not quite finished yet. Between both of
>> those, that takes care of my two key desires.
> 
> but is apache style process spawning really a good idea? i mean i'm
> replacing apache with nginx because the idea of apache's scaling is
> ''thread/fork as much as you can, as soon as you can and not a
> thread/process less'' :-)
> 

There are no other solutions if you want to serve generic "slow"
applications.
With some application, it is even better if you fork for each request,
instead of preforking.

Make sure you have a decent hardware and an application that is as much
restful it can, so that you can scale it without problems.



Manlio Perillo

On 7/16/08, Almir Karic <almir@kiberpipa.org> wrote:

> mod_suphp can do that as well.

I ran suphp for a bit. it could not handle the load on my servers. it
looks like it essentially runs an actual php cgi process to handle
each request. That's hardly scalable. Oh yeah - it requires Apache.
Puke.

> but is apache style process spawning really a good idea? i mean i'm
> replacing apache with nginx because the idea of apache's scaling is
> ''thread/fork as much as you can, as soon as you can and not a
> thread/process less'' :-)

Andrei calls it apache style. Basically I think it's just a basic
"Have $x number of engines at start, have max of $y engines, keep $z
engines idle" etc...

It's not really a straight apples to apples comparison of apache vs.
nginx style of handling processes... that's just the title he's given
it on how you define the threshholds, I believe.

> thread/process less'' :-)
>
>   
I think your objection to this is basically because of apache problems,
not really problems with process spawning. Apache process spawning is
problematic because of apache itself. Each process is taking up system
resources, doing very little or nothing at all (especially true with
keep-alive connections). Since apache is a memory hog, this causes
problems, I've had problems with machines going into swap because of
this. If you don't have fastcgi in Apache, the problem is much more
noticable, since each process takes up much more memory with mod_php
instead of using fastcgi in the backend.

P.s. doesnt lighttpd already have "apache" style process spawning for
fastcgi? The config options for fastcgi include min-procs, max-procs.
This should be an equivalent with apaches MinSpareServers,
MaxSpareServers, MaxClients but relevant only to fastcgi (albeit
smaller, 1-8 is something reasonable).

On 7/16/08, Tit Petric <black@scene-si.org> wrote:

> P.s. doesnt lighttpd already have "apache" style process spawning for
> fastcgi? The config options for fastcgi include min-procs, max-procs. This
> should be an equivalent with apaches MinSpareServers, MaxSpareServers,
> MaxClients but relevant only to fastcgi (albeit smaller, 1-8 is something
> reasonable).

yes, in 1.4.x - in 1.5.x adaptive process spawning has been
removed/not included.

also, i believe it is considered "broken" by the lighty community, so
it's not very useful to begin with.

php-fpm to me is the right type of tool for the job. originally i had
a "wishlist" item for something that would have been a fastcgi proxy
layer - essentially everything php-fpm provides... so php-fpm to me is
a godsend, as soon as Andrei finishes the process spawning work, it
will make my life so much more enjoyable - no more wasting resources
trying to determine manually how many engines to have sitting around,
etc...