Exact Oliver,
I have the exact same issue, have you managed to solve the problem?
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed a
Filip Hajny a écrit :
> Yes, well, my point was... if you care about shared memory, then
> constrain mod_fcgid to a single PHP process only, let the PHP process
> fork its own children and hope they will be able to process all
> requests before mod_fcgid considers the single process busy and
On 28.2.2009, at 17:27, Olivier B. wrote:
> my first question was about that : it seems that fcgid will _never_
> use
> this concurrent PHP instances. If there is 2 concurrent access, fcgid
> will spawn an other "group" of PHP to handle that, it will not use the
> first group of php instance whi
my first question was about that : it seems that fcgid will _never_ use
this concurrent PHP instances. If there is 2 concurrent access, fcgid
will spawn an other "group" of PHP to handle that, it will not use the
first group of php instance which have idled children. So in this groups
of PHP, there
On 28.2.2009, at 17:05, Olivier B. wrote:
> Yes I was thinking that but what is the interest to share memory
> between
> processes which never run simultaneously ?
>
They do. If you let PHP spawn them, they all start right away, and
keep running until you kill them. They are not killed when i
Yes I was thinking that but what is the interest to share memory between
processes which never run simultaneously ?
Olivier
Filip Hajny a écrit :
> On 28.2.2009, at 15:24, Olivier B. wrote:
>
>
>> So, I simply read the file sapi/cgi/README.FastCGI in the PHP source.
>> If I well understand, t
On 28.2.2009, at 15:24, Olivier B. wrote:
> So, I simply read the file sapi/cgi/README.FastCGI in the PHP source.
> If I well understand, this feature is usefull when you run directly
> PHP
> as the fcgi daemon.
>
It's also useful when you want memory shared among the PHP processes
(e.g. for
So, I simply read the file sapi/cgi/README.FastCGI in the PHP source.
If I well understand, this feature is usefull when you run directly PHP
as the fcgi daemon.
I have the end of my explanation, thanks and sorry for noise ;)
Olivier
Olivier B. a écrit :
> Max Dittrich a écrit :
>
>> AFAIK (
Max Dittrich a écrit :
> AFAIK (?) mod_fcgid can't multiplex multiple request on one fcgi-socket.
> The fcgi-connection is 1:1 (http request <--> fcgi connection) and can't
> be shared across childs/threads of apache.
>
> .max
>
Ok, it is what I see too. Thanks.
Filip Hajny a écrit :
> PHP for
On 28.2.2009, at 12:10, Max Dittrich wrote:
> Olivier B. wrote:
>> Yes, but in that case why PHP forks ? children will never be used !?
>
> AFAIK (?) mod_fcgid can't multiplex multiple request on one fcgi-
> socket.
> The fcgi-connection is 1:1 (http request <--> fcgi connection) and
> can't
>
Olivier B. wrote:
> Yes, but in that case why PHP forks ? children will never be used !?
AFAIK (?) mod_fcgid can't multiplex multiple request on one fcgi-socket.
The fcgi-connection is 1:1 (http request <--> fcgi connection) and can't
be shared across childs/threads of apache.
.max
Yes, but in that case why PHP forks ? children will never be used !?
Olivier
Ivan Voras a écrit :
> 2009/2/27 Olivier B. :
>
>
>> The DefaultMaxClassProcessCount is reached, but why fcgid try have
>> launched 4 process ? Just one or two should be sufficient in the case of
>> five concurrent us
2009/2/27 Olivier B. :
> The DefaultMaxClassProcessCount is reached, but why fcgid try have
> launched 4 process ? Just one or two should be sufficient in the case of
> five concurrent users, since each PHP process can handle 5 of them. No ?
> Or maybe I misunderstood this fork feature of PHP, and
13 matches
Mail list logo
