Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Wed, 2 Oct 2024 16:25:08 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vdjs54$rdp$1@reader1.panix.com>
References: <vcv0bl$39mnj$1@dont-email.me> <vdjocl$37f8p$3@dont-email.me> <vdjoui$37f8q$4@dont-email.me> <vdjpps$fk2$2@reader1.panix.com>
Injection-Date: Wed, 2 Oct 2024 16:25:08 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="28089"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 3618
Lines: 73

In article <vdjpps$fk2$2@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <vdjoui$37f8q$4@dont-email.me>,
>Arne Vajhøj  <arne@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@dont-email.me>,
>>>> Arne Vajhøj  <arne@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.