[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vdjoui$37f8q$4 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 10/2/2024 11:20 AM, Arne Vajhøj wrote:
>> On 10/2/2024 11:07 AM, Dan Cross wrote:
>>> In article <vdjmq4$37f8q$3 at dont-email.me>,
>>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>>> On 10/2/2024 10:47 AM, Dan Cross wrote:
>>>>> [snip]
>>>>> You do not seem to understand how this is qualitatively
>>>>> different from your test program not sending `Connection: close`
>>>>> with its single request per connection, and then blocking until
>>>>> the server times it out.
>>>>
>>>> It is qualitative different from what you are imaging.
>>>>
>>>> The client does not block until the server times out.
>>>
>>> So what, exactly, does it do?
>> 
>> It moves on to next request.
>> 
>> That request will block if the server can't serve it
>> because all processes are busy.
>> 
>>  >Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  And what is the "problem" that
>>  > you are imagining here?  Please be specific.
>> 
>> Go back to the first post in the thread.
>> 
>> The numbers for Apache are low. Much lower than
>> for other servers.
>
>And the numbers are low due to keep alive.
>
>Basically Apache on VMS keep an entire process around for
>a kept alive connection.
>
>When Apache configuration does not allow more
>processes to start then new requests get queued
>until keep alive starts to timeout and processes
>free up.
>
>And one can not just increase number of processes
>allowed because they use 25 MB each. The system
>runs out of memory/pagefile fast.
>
>An it does not help that if Apache kills some
>processes then it is expensive to start a new one again,
>which means that either the large number of memory
>consuming processes are kept around or Apache
>will be slow to adjust to increasing load.

These are all claims not supported by the _actual_ evidence that
you've posted here.  While your argument is plausible on the
face of it, how did you arrive at this conclusion?

Post more details about your setup and experiments.

	- Dan C.