| Re: Current PHP implementation [message #180020 is a reply to message #180018] |
Wed, 26 December 2012 19:51   |
Luuk
Messages: 329
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 26-12-2012 19:30, Peter H. Coffin wrote:
> On Wed, 26 Dec 2012 17:12:48 +0100, Luuk wrote:
>> On 26-12-2012 11:43, Tim Streater wrote:
>>> In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
>>> wrote:
>>>
>>>> On 26-12-2012 03:45, Jerry Stuckle wrote:
>>>> > On 12/25/2012 8:51 PM, SL@maxis wrote:
>>>> >>
>>>> >> I ask this question in 'comp.unix.programmer. It seems like it is more
>>>> >> related to PHP.
>>>> >>
>>>> >> I ask here to find out the current PHP implementation.
>>>> >>
>>>> >> Assume at a given time 10 users send in AJAX calls; server end handled
>>>> >> by '123.php'.
>>>> >>
>>>> >> 1. Handler (script): 123.php
>>>> >>
>>>> >> Does the server initiate 10 processes to handle the calls ? Which
>>>> means
>>>> >> 10 processes are closed after processing !?
>>>> >>
>>>> >> 2. Handler (daemon): 123.php
>>>> >>
>>>> >> Is the daemon/server creating 10 threads to handle requests ? Which
>>>> >> means the daemon is always running. Please ignore the memory
>>>> problem of
>>>> >> PHP.
>>>
>>>> > PHP doesn't handle AJAX calls, nor does PHP start any processes. That
>>>> > is all done by the web server. You need to be asking in a newsgroup
>>>> > for the webserver you are using.
>>>
>>>> ants fucker
>>>>
>>>> What about the answer to this question,
>>>>
>>>> (after replacing the 'improper' described handling of PHP)
>>>
>>> Anyone understand what Luuk's reply means?
>>>
>>
>> I was asking for the correct answer to OP's question
>>
>> The OP seems to want to learn something.
>>
>> I think so, because he's asking here, and claims to have done the asking
>> elsewhere ("I ask this question in ....")
>>
>> And the answer is:
>> "You need to be asking in a newsgroup ...."
>>
>> But the name of this newsgroup is NOT alt.where.should.questions.be.asked
>
> Fine. I'll do it. It will be correct, within the contexts of PHP.
>
> 1. It depends on how the webserver processes things. Typically there
> will be ten processes spawned. Then processes will exist so long as they
> have work to do, then exit when they are done or the process timer
> expires.
>
> 2. Daemon version will depend 100% on how you write daemon.
> Typically, though, PHP is not written with threading in mind. The only
> mostly-developed process control is essentially a wrapper to fork, works
> only on unix-like operating systems, and requires PHP to be built as CGI
> or CLI, not webserver modules. Your daemon may have to spawn a separate
> process for each connection, as the way to handle multiple connections
> involves polling sockets to see if any are active and have anything
> ready for processing, which means any call made that blocks execution to
> wait for results will hold up processing of all the rest of the sockets,
> and PHP, not being written for this kind of thing, has a LOT of blocking
> calls. So, you probably want to spawn a process for every connection, so
> that none of them are waiting on the others. So, typically, you will
> have 11 process. Your actual daemon, plus all the subprocesses spawned
> to handle the work of the connection. You will need to clean these up
> yourself, either by having each exit as it completes one connection (like
> the webserver version does) or your daemon controller will have to send
> the subprocesses signals to exit.
>
> Now, was that helpful? Probably not. There's too many things outside PHP
> managing parts of doing this to describe what's going to happen
> reliably, and the reason that there's too many things outside of PHP is
> because PHP's not written with the expectation of doing this in a robust
> manner, so there's not exactly a big body of work establishing a
> best-practice. What there is tends to be of the first sort: single-task
> handlers that are spawned and managed by the webserver in whatever
> manner the webserver manages the processes. Funny, this is 30 minutes
> of research, analysis, and typing to come up with what's nothing but a
> long-winded verson of what Jerry said. You even made me look at a
> w3sc***ls page to make sure I didn't miss something, and now I feel like
> I need a shower.
>
But this is an answer, and Jerry only told the OP to check a newsgroup
'for the webserver you are using'
There's a big difference between:
1) Describing (as done here) why this has more to do with the
configuration of your webserver
or
2) Not giving a clue, and pointing to clueless.some.webserver
I whish to thank Peter for his 30 minutes ;)
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]