Sujet : Re: Apache + mod_php performance
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.os.vmsDate : 27. Sep 2024, 20:16:31
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vd70af$hov$1@reader1.panix.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
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.