[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vdjpps$fk2$2 at reader1.panix.com>,
Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>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.

Let's dig a little deeper here and show that Arne's pro blem
is not specific to VMS.  Indeed, I can replicate something more
or less like the results he showed on FreeBSD.

I'm using "seige", which is another testing tool; here, I can
force HTTP/1.1 and also enable keep-alive via options in its
configuration file.  With 25 worker threads 1000 queries each,
I easily saturate the number of workers and hang waiting for
timeouts, tanking throughput.

So...Not a VMS problem at all.

	- Dan C.