Path: ...!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: Fri, 27 Sep 2024 19:16:31 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vd70af$hov$1@reader1.panix.com>
References: <vcv0bl$39mnj$1@dont-email.me> <vd1u8j$3qqpg$1@dont-email.me> <vd3vhj$849$1@reader1.panix.com> <vd6l5h$pmt5$1@dont-email.me>
Injection-Date: Fri, 27 Sep 2024 19:16:31 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="18207"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 3169
Lines: 60

In article <vd6l5h$pmt5$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>On 9/26/2024 11:44 AM, Dan Cross wrote:
>> In article <vd1u8j$3qqpg$1@dont-email.me>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> It must be Apache.
>>>
>>> Apache on VMS is prefork MPM. Yuck.
>>>
>>> MaxSpareServers 10 -> 50
>>> MaxClients 150 -> 300
>>>
>>> actually did improve performance - double from 11 to 22
>>> req/sec.
>>>
>>> But the system did not like further increases. And besides
>>> these numbers are absurd high to handle a simulator doing requests
>>> from just 20 threads.
>>>
>>> But not sure what else I can change.
>> 
>> My guess is that communications overhead is slowing things down.
>> What happens if you set these super low, ideally so there's a
>> single process handling requests, then see what sort of QPS
>> numbers you get for your trivial text file.
>
>I set it down to 1.
>
>0.1 req/sec

So a single request takes 10 seconds?  Or you can only make one
request every 10 seconds, but the time taken to process that
request is relatively small?

>Note that even if it had performed great then it would not
>have been a solution because the real thing the PHP scripts
>has significant latency when interacting with external database
>so parallelization is a must.

We're not at the point of discussing solutions.  You still don't
understand what the actual problem is; we're trying to figure
that out right now.

Again, it's about understanding the baseline performance
characteristics first.  Your goal right now ought to be figure
out why requests for a simple static resource, like a text file,
are so slow; the point by trying something simple is to reduce
noise due to confounding variables.

The fact that this is as slow as it is tells you something.  Had
this performed better, that would tell you something as well,
but in this case, you know that there's some sort of basic slow
down even in the simplest cases.  If you can figure out why that
is, and address it, _then_ you move on to re-evaluating your
actual use case, and if necessary, investigate other slow downs.
But right now, there's little point in doing that: you know you
see a non-linear slowdown as you increase threads (you _did_
notice that, right?).

	- Dan C.