On Wed, Sep 15, 2010 at 12:40 PM, J Ravi Menon <jravime...@gmail.com> wrote: > On Wed, Sep 15, 2010 at 11:21 AM, Rasmus Lerdorf <ras...@lerdorf.com> 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 >> >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
