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

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.

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.

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 :slight_smile:

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

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

On Fre 11.07.2008 01:02, Marcos N. wrote:

That looks awesome! Did you know a better tutorial then this one:
NameBright - Coming Soon
I?ll try today.

maybe this entry.

yes, my own blog.

BR

Aleks

On 7/15/08, nginx. mailinglist [email protected] 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.

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 :stuck_out_tongue:

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

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

On 7/15/08, Marcos N. [email protected] 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 ! :slight_smile:

On 7/15/08, Marcos N. [email protected] 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 ! :slight_smile:

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 C. [email protected] 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

On Tue, Jul 15, 2008 at 12:58:36PM -0700, mike wrote:

On 7/15/08, Marcos N. [email protected] 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’’ :slight_smile:

Hi,

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

On Tue, Jul 15, 2008 at 6:11 PM, Igor C. [email protected]
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

Cheers
i

Almir K. 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’’ :slight_smile:

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 P.