Current PHP implementation [message #180005] |
Wed, 26 December 2012 01:51 |
SL@maxis
Messages: 2 Registered: December 2012
Karma: 0
|
Junior Member |
|
|
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.
Thanks for any info. Happy Boxing day.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
|
|
|
Re: Current PHP implementation [message #180007 is a reply to message #180005] |
Wed, 26 December 2012 02:45 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
>
>
> Thanks for any info. Happy Boxing day.
>
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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
Re: Current PHP implementation [message #180009 is a reply to message #180007] |
Wed, 26 December 2012 10:26 |
Luuk
Messages: 329 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
>>
>>
>> Thanks for any info. Happy Boxing day.
>>
>
> 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)
?
|
|
|
Re: Current PHP implementation [message #180010 is a reply to message #180009] |
Wed, 26 December 2012 10:43 |
Tim Streater
Messages: 328 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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?
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
Re: Current PHP implementation [message #180011 is a reply to message #180010] |
Wed, 26 December 2012 12:15 |
The Natural Philosoph
Messages: 993 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 26/12/12 10: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 think he means incorrect. I.e. the contention that PHP dosnt...its all
done by the server..
...and the definition of a server to be a box that serves, which
obviously contains the PHP.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
Re: Current PHP implementation [message #180012 is a reply to message #180005] |
Wed, 26 December 2012 12:40 |
Thomas 'PointedEars'
Messages: 701 Registered: October 2010
Karma: 0
|
Senior Member |
|
|
SL@maxis wrote:
^^^^^^^^
Who?
> I ask this question in 'comp.unix.programmer. It seems like it is more
> related to PHP.
It is not more related to PHP as apples are to oranges.
> I ask here to find out the current PHP implementation.
Do you know what PHP is?
> Assume at a given time 10 users send in AJAX calls; server end handled by
> '123.php'.
| AJAX call \noun\
| Term indicating that the per-
| son using it has no clue what
| they are talking about. See
| also: AJAX.
> 1. Handler (script): 123.php
>
> Does the server initiate 10 processes to handle the calls ? Which means 10
> processes are closed after processing !?
Server processes are not the domain of the compiler-interpreter of a
programming language, but of the Web server software.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>
|
|
|
Re: Current PHP implementation [message #180013 is a reply to message #180007] |
Wed, 26 December 2012 13:45 |
Denis McMahon
Messages: 634 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Tue, 25 Dec 2012 21:45:58 -0500, Jerry Stuckle wrote:
> PHP doesn't handle AJAX calls
If the client calls a php script using the client side ajax mechanism,
then the php script handles the ajax call.
However, what part of the client generates the call is irrelevant to the
php. All that the php script "knows" is that it has been invoked in an
environment that may include several predefined arrays. It has no idea
whether it was invoked from a link click, a form submission, an embedded
object or an ajax call, although it may be able to determine this from
its data environment.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
Re: Current PHP implementation [message #180014 is a reply to message #180010] |
Wed, 26 December 2012 13:55 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/26/2012 5:43 AM, 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?
>
He has no idea what he's talking about.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
Re: Current PHP implementation [message #180016 is a reply to message #180010] |
Wed, 26 December 2012 16:12 |
Luuk
Messages: 329 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
Re: Current PHP implementation [message #180018 is a reply to message #180016] |
Wed, 26 December 2012 18:30 |
Peter H. Coffin
Messages: 245 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
--
Whenever you look at a beautiful woman,
always remember that somewhere, someone is tired of her.
|
|
|
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: 0
|
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 ;)
|
|
|
Re: Current PHP implementation [message #180021 is a reply to message #180020] |
Wed, 26 December 2012 20:29 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/26/2012 2:51 PM, Luuk wrote:
> 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'
>
Which is the CORRECT answer. Point him to the correct place (note he
did NOT say which webserver he's using), and he'll get correct AND
HELPFUL answers (even Peter admitted the answer was probably not helpful).
> 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 ;)
Which is completely worthless in this case because of all the "ifs"
involved. It depends completely on the webserver and the OS it's
running on.
Often times the BEST help one can give someone is to point him at the
RIGHT place to ask his question.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
Re: Current PHP implementation [message #180022 is a reply to message #180018] |
Thu, 27 December 2012 00:54 |
Thomas 'PointedEars'
Messages: 701 Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin wrote:
> Fine. I'll do it. It will be correct, within the contexts of PHP.
And unsurprisingly, what you posted is not even close to being correct, the
PHP part included.
> 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.
No, typically (read: apache-mpm-prefork on a Linux-based system) there will
be two server processes that have 10 threads each, which will continue to
run until the server is shut down.
In any case, with PHP run by server module or FastCGI, the parent process
will like *never* exit as long as the server system is running uninterrupted
(i.e., without reboot and maintenance).
Started threads will likely exist until the Web server service is stopped.
New child processes will be created if the number of threads in a child
process exceed the specified maximum. Threads in a child process will be
created so as to meet the specified minimum and number of spare threads.
> Now, was that helpful?
No.
> Probably not.
So you figured. But you posted this utter nonsense anyway? You have way
too much time on your hands.
> […] You even made me look at a w3sc***ls page to make sure I didn't miss
> something,
There is nothing to be gained from reading a “w3sc***ls page” and much to be
lost. Most of all, clarity of thought and overall mental sanity. Of which
your posting is a good example.
> and now I feel like I need a shower.
Me too.
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
Re: Current PHP implementation [message #180025 is a reply to message #180023] |
Thu, 27 December 2012 11:39 |
Thomas 'PointedEars'
Messages: 701 Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Anders Wegge Keller wrote:
> Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> writes:
>> No, typically (read: apache-mpm-prefork on a Linux-based system)
>> there will be two server processes that have 10 threads each, which
>> will continue to run until the server is shut down.
>
> MaxRequestsPerChild?
Indeed, that is another constraint I overlooked. However, if I am not
mistaken, both the default value and default distribution configuration file
value¹ is 0, which means that those two child processes will never expire,
and AIUI neither will their threads.
<http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequestsperchild>
PointedEars
___________
¹ I was checking my /etc/apache2/apache2.conf.dpkg-old, mtime 2009-12-04.
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
|
|
|
Re: Current PHP implementation [message #180026 is a reply to message #180021] |
Thu, 27 December 2012 18:37 |
Luuk
Messages: 329 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 26-12-2012 21:29, Jerry Stuckle wrote:
> On 12/26/2012 2:51 PM, Luuk wrote:
>> On 26-12-2012 19:30, Peter H. Coffin wrote:
......
>> I whish to thank Peter for his 30 minutes ;)
>
> Which is completely worthless in this case because of all the "ifs"
> involved. It depends completely on the webserver and the OS it's
> running on.
>
> Often times the BEST help one can give someone is to point him at the
> RIGHT place to ask his question.
>
I think its more usefull than your first answer.
So, opinions differ.
Also, if you do not know the answer,
than you can also not respond,
in stead of pointing to some other newsgroup
which you did not do in this place,
Because here you tried to send OP to 'somewhere'
|
|
|
Re: Current PHP implementation [message #180027 is a reply to message #180026] |
Thu, 27 December 2012 21:10 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/27/2012 1:37 PM, Luuk wrote:
> On 26-12-2012 21:29, Jerry Stuckle wrote:
>> On 12/26/2012 2:51 PM, Luuk wrote:
>>> On 26-12-2012 19:30, Peter H. Coffin wrote:
>
> .....
>
>>> I whish to thank Peter for his 30 minutes ;)
>>
>> Which is completely worthless in this case because of all the "ifs"
>> involved. It depends completely on the webserver and the OS it's
>> running on.
>>
>> Often times the BEST help one can give someone is to point him at the
>> RIGHT place to ask his question.
>>
>
> I think its more usefull than your first answer.
> So, opinions differ.
>
> Also, if you do not know the answer,
> than you can also not respond,
> in stead of pointing to some other newsgroup
> which you did not do in this place,
> Because here you tried to send OP to 'somewhere'
>
Just because I don't know the answer doesn't mean I can't try to point
him to the right place.
You seem to think ANY answer in this newsgroup - whether related to PHP
or not - is appropriate. But then that's why there are so many crappy
answers to off-topic posts. Direct the person to where the REAL experts
for his/her question hang out is the best advice you can give.
But then I'll bet you'd ask your car mechanic what to do when you're
having a heart attack.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
Re: Current PHP implementation [message #180028 is a reply to message #180027] |
Fri, 28 December 2012 02:28 |
Twayne
Messages: 135 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:kbidfq$e8i$1(at)dont-email(dot)me,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
> On 12/27/2012 1:37 PM, Luuk wrote:
>> On 26-12-2012 21:29, Jerry Stuckle wrote:
>>> On 12/26/2012 2:51 PM, Luuk wrote:
>>>> On 26-12-2012 19:30, Peter H. Coffin wrote:
>>
>> .....
>>
....
>
> Just because I don't know the answer doesn't mean I can't
> try to point him to the right place.
Try? When you don't know, shut your trap and don't advertise your ineptness.
>
> You seem to think ANY answer in this newsgroup - whether
> related to PHP or not - is appropriate. But then that's
> why there are so many crappy answers to off-topic posts. Direct the person
> to where the REAL experts for his/her
> question hang out is the best advice you can give.
I havebn't gotten that feeliing about him at all.
>
> But then I'll bet you'd ask your car mechanic what to do
> when you're having a heart attack.
The person having the heart attack isn't going to be doing much of anything;
what do you think he should do?
If the car mech is the only one around, he just might know how to dial 911
or do CPR, or get the fastest help. That's a pretty uriney attituce on your
part and once again makes no sense. An answer for the sake of your ego. A
failure to show off and a lot more.
|
|
|
Re: Current PHP implementation [message #180029 is a reply to message #180028] |
Fri, 28 December 2012 02:34 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/27/2012 9:28 PM, Twayne wrote:
> In news:kbidfq$e8i$1(at)dont-email(dot)me,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
>> On 12/27/2012 1:37 PM, Luuk wrote:
>>> On 26-12-2012 21:29, Jerry Stuckle wrote:
>>>> On 12/26/2012 2:51 PM, Luuk wrote:
>>>> > On 26-12-2012 19:30, Peter H. Coffin wrote:
>>>
>>> .....
>>>
> ...
>>
>> Just because I don't know the answer doesn't mean I can't
>> try to point him to the right place.
>
> Try? When you don't know, shut your trap and don't advertise your ineptness.
>
Ah, the troll speaks up again. How did YOU help him? At least I TRIED
to point him in the right direction!
>>
>> You seem to think ANY answer in this newsgroup - whether
>> related to PHP or not - is appropriate. But then that's
>> why there are so many crappy answers to off-topic posts. Direct the person
>> to where the REAL experts for his/her
>> question hang out is the best advice you can give.
>
> I havebn't gotten that feeliing about him at all.
>>
>> But then I'll bet you'd ask your car mechanic what to do
>> when you're having a heart attack.
>
> The person having the heart attack isn't going to be doing much of anything;
> what do you think he should do?
> If the car mech is the only one around, he just might know how to dial 911
> or do CPR, or get the fastest help. That's a pretty uriney attituce on your
> part and once again makes no sense. An answer for the sake of your ego. A
> failure to show off and a lot more.
>
>
>
Sure, people have heart attacks all the time. A friend of mine even
drove himself to the hospital (I didn't say it was a smart thing to do).
But then you don't know the difference between a heart attack and
cardiac arrest. You don't give CPR to someone with a heart attack (his
heart has not stopped yet).
Once again you show complete ignorance of a subject.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|