Hi,
[Note: I am new to this list and I don't actively work on php
internals. I have been occasionally glancing at some php internals
here n there for interest and better understanding.]
I raised this question on php-general and was recommended to try out
the internals list:
(tried to search the archives but couldn't do so)
http://news.php.net/php.general/308097
My specific doubts are:
- In the fast-cgi setup with php-fpm, it seems the app developer is
responsible for resource mgmt? Currently we use apache+mod_php (apache
2.2, php 5.2.x series on linux 2.6), and we rely on mod_php cleaning
up various resources (non-persistent socket connections to memcached,
mysqld, and other services via curl).
So my guess is, if we do php-fpm approach, we have to do all these
cleanups manually? Or are there simpler solutions or hook-ups that
does it automatically at the end of the request cycle?
- My other concern is the extra ipc overhead between
nginx<---->php-fpm servers even on unix sockets. To me in theory
apache+mod_php ( + apc with stat off) should be as efficient as you
can get. Granted nginx might be more efficient in its socket mgmt
(non-blocking event-driven i/o), but can it really outperform the
apache approach given the issues in (1) are resolved?
I hope to run some tests myself with our typical (and non-trivial) php
app, but any insights you already have would be beneficial.
thx,
Ravi
So my guess is, if we do php-fpm approach, we have to do all these
cleanups manually? Or are there simpler solutions or hook-ups that
does it automatically at the end of the request cycle?
No, fastcgi doesn't change this model at all. You have the same
end-of-requests cleanups as with mod_php.
- My other concern is the extra ipc overhead between
nginx<---->php-fpm servers even on unix sockets. To me in theory
apache+mod_php ( + apc with stat off) should be as efficient as you
can get. Granted nginx might be more efficient in its socket mgmt
(non-blocking event-driven i/o), but can it really outperform the
apache approach given the issues in (1) are resolved?
In theory that extra ipc should make the nginx case slower, true. From
what I have been able to measure, that is rarely a factor though.
You can take a look at this slide from a recent talk of mine:
http://talks.php.net/show/drupalconcph/11
That's testing a vanilla Drupal setup on Apache, PHP-FPM-nginx and
PHP-FPM-lighttpd. The dashed lines show the latency, the solid lines
the requests/sec.
-Rasmus
So my guess is, if we do php-fpm approach, we have to do all these
cleanups manually? Or are there simpler solutions or hook-ups that
does it automatically at the end of the request cycle?No, fastcgi doesn't change this model at all. You have the same
end-of-requests cleanups as with mod_php.
Ah good to know.
- My other concern is the extra ipc overhead between
nginx<---->php-fpm servers even on unix sockets. To me in theory
apache+mod_php ( + apc with stat off) should be as efficient as you
can get. Granted nginx might be more efficient in its socket mgmt
(non-blocking event-driven i/o), but can it really outperform the
apache approach given the issues in (1) are resolved?In theory that extra ipc should make the nginx case slower, true. From
what I have been able to measure, that is rarely a factor though.You can take a look at this slide from a recent talk of mine:
http://talks.php.net/show/drupalconcph/11
That's testing a vanilla Drupal setup on Apache, PHP-FPM-nginx and
PHP-FPM-lighttpd. The dashed lines show the latency, the solid lines
the requests/sec.
A lot here will depend upon the typical payload size. If compression
is done at the fcgi server end, I can see why it may not matter much.
Thx,
Ravi
-Rasmus
So my guess is, if we do php-fpm approach, we have to do all these
cleanups manually? Or are there simpler solutions or hook-ups that
does it automatically at the end of the request cycle?No, fastcgi doesn't change this model at all. You have the same
end-of-requests cleanups as with mod_php.Ah good to know.
So with this mod_php like behavior, do we also need to have apc
enabled in this setup for the opcode cache? As a cli daemon, I am
assuming this is not necessary?
thx,
Ravi
- My other concern is the extra ipc overhead between
nginx<---->php-fpm servers even on unix sockets. To me in theory
apache+mod_php ( + apc with stat off) should be as efficient as you
can get. Granted nginx might be more efficient in its socket mgmt
(non-blocking event-driven i/o), but can it really outperform the
apache approach given the issues in (1) are resolved?In theory that extra ipc should make the nginx case slower, true. From
what I have been able to measure, that is rarely a factor though.You can take a look at this slide from a recent talk of mine:
http://talks.php.net/show/drupalconcph/11
That's testing a vanilla Drupal setup on Apache, PHP-FPM-nginx and
PHP-FPM-lighttpd. The dashed lines show the latency, the solid lines
the requests/sec.A lot here will depend upon the typical payload size. If compression
is done at the fcgi server end, I can see why it may not matter much.Thx,
Ravi-Rasmus
So my guess is, if we do php-fpm approach, we have to do all these
cleanups manually? Or are there simpler solutions or hook-ups that
does it automatically at the end of the request cycle?No, fastcgi doesn't change this model at all. You have the same
end-of-requests cleanups as with mod_php.Ah good to know.
So with this mod_php like behavior, do we also need to have apc
enabled in this setup for the opcode cache? As a cli daemon, I am
assuming this is not necessary?
APC works perfectly out of the box with this setup. It is no different
from something like Apache where you have a root process that creates
the mmap segment which then forks children that inherit the pointer to
that segment.
-Rasmus
So my guess is, if we do php-fpm approach, we have to do all these
cleanups manually? Or are there simpler solutions or hook-ups that
does it automatically at the end of the request cycle?No, fastcgi doesn't change this model at all. You have the same
end-of-requests cleanups as with mod_php.Ah good to know.
So with this mod_php like behavior, do we also need to have apc
enabled in this setup for the opcode cache? As a cli daemon, I am
assuming this is not necessary?APC works perfectly out of the box with this setup. It is no different
from something like Apache where you have a root process that creates
the mmap segment which then forks children that inherit the pointer to
that segment.
Sorry I meant to ask if the opcode cache is necessary to avoid the
compilation step even if the same php-fcgi daemon has seen the same
script before? My guess is that these fcgi hooks emulate a basic
mod_php behavior without apc?
Ravi
-Rasmus
So my guess is, if we do php-fpm approach, we have to do all these
cleanups manually? Or are there simpler solutions or hook-ups that
does it automatically at the end of the request cycle?No, fastcgi doesn't change this model at all. You have the same
end-of-requests cleanups as with mod_php.Ah good to know.
So with this mod_php like behavior, do we also need to have apc
enabled in this setup for the opcode cache? As a cli daemon, I am
assuming this is not necessary?APC works perfectly out of the box with this setup. It is no different
from something like Apache where you have a root process that creates
the mmap segment which then forks children that inherit the pointer to
that segment.Sorry I meant to ask if the opcode cache is necessary to avoid the
compilation step even if the same php-fcgi daemon has seen the same
script before? My guess is that these fcgi hooks emulate a basic
mod_php behavior without apc?
An opcode cache is still necessary, yes. fcgi doesn't persist the
compiled opcodes.
-Rasmus