[prev in list] [next in list] [prev in thread] [next in thread]
List: php-internals
Subject: Re: [PHP-DEV] nginx+php-fpm question
From: Rasmus Lerdorf <rasmus () lerdorf ! com>
Date: 2010-09-16 4:16:06
Message-ID: 4C919A06.50804 () lerdorf ! com
[Download RAW message or body]
On 9/15/10 8:13 PM, J Ravi Menon wrote:
> On Wed, Sep 15, 2010 at 7:37 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>> On 9/15/10 7:13 PM, J Ravi Menon wrote:
>>> On Wed, Sep 15, 2010 at 12:40 PM, J Ravi Menon <jravimenon@gmail.com> wrote:
>>>> On Wed, Sep 15, 2010 at 11:21 AM, Rasmus Lerdorf <rasmus@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?
>>
>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic