Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=PtAT2nzBPgExFPTuSwYfac5r/nxU3TMzHqjWpyIf/w9ztViSjKa4TA1of7oszBPahk
         cY6lu6a/ux0tmKuN/173Uw6SvZp0B1UWmVxDzddmlgTwrhByd9cn6OT18zrU7Z5wp5uE
         zZcjAoGsVrrYlRVnGMKRdlXk0qeKz2KsyxeF0=
MIME-Version: 1.0
Date: Wed, 15 Sep 2010 10:57:34 -0700
Message-ID: <AANLkTinF=ZctV7e5jzGERJ_mZYn4R75fq1szsXJ4-25M@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: nginx+php-fpm question
From: jravimenon@gmail.com (J Ravi Menon)

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