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

1) 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?

2) 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

Search Discussions

  • Rasmus Lerdorf at Sep 15, 2010 at 6:21 pm

    On 9/15/10 10:57 AM, J Ravi Menon wrote:
    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.
    2) 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
  • J Ravi Menon at Sep 15, 2010 at 7:40 pm

    On Wed, Sep 15, 2010 at 11:21 AM, Rasmus Lerdorf wrote:
    On 9/15/10 10:57 AM, J Ravi Menon wrote:
    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.

    2) 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
  • J Ravi Menon at Sep 16, 2010 at 2:13 am

    On Wed, Sep 15, 2010 at 12:40 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 11:21 AM, Rasmus Lerdorf wrote:
    On 9/15/10 10:57 AM, J Ravi Menon wrote:
    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



    2) 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
  • Rasmus Lerdorf at Sep 16, 2010 at 2:37 am

    On 9/15/10 7:13 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 12:40 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 11:21 AM, Rasmus Lerdorf wrote:
    On 9/15/10 10:57 AM, J Ravi Menon wrote:
    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
  • J Ravi Menon at Sep 16, 2010 at 3:13 am

    On Wed, Sep 15, 2010 at 7:37 PM, Rasmus Lerdorf wrote:
    On 9/15/10 7:13 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 12:40 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 11:21 AM, Rasmus Lerdorf wrote:
    On 9/15/10 10:57 AM, J Ravi Menon wrote:
    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
  • Rasmus Lerdorf at Sep 16, 2010 at 4:16 am

    On 9/15/10 8:13 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 7:37 PM, Rasmus Lerdorf wrote:
    On 9/15/10 7:13 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 12:40 PM, J Ravi Menon wrote:
    On Wed, Sep 15, 2010 at 11:21 AM, Rasmus Lerdorf wrote:
    On 9/15/10 10:57 AM, J Ravi Menon wrote:
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedSep 15, '10 at 5:57p
activeSep 16, '10 at 4:16a
posts7
users2
websitephp.net

2 users in discussion

J Ravi Menon: 4 posts Rasmus Lerdorf: 3 posts

People

Translate

site design / logo © 2022 Grokbase