Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Fri, 27 Sep 2024 12:41:03 -0400
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <vd6n70$q3fm$1@dont-email.me>
References: <vcv0bl$39mnj$1@dont-email.me> <vd54jp$e44c$1@dont-email.me>
 <vd6baf$o3q5$1@dont-email.me> <vd6dh4$nrif$1@dont-email.me>
 <vd6env$gfu$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 27 Sep 2024 18:41:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1c0eb99617403d5d511f3f96ce19037b";
	logging-data="855542"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ytADdFOS2FeCFDzQWEGeXthj7a/DA/9E="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:f3/rKN82emEaH+NGee6L9QH40qc=
In-Reply-To: <vd6env$gfu$1@reader1.panix.com>
Content-Language: en-US
Bytes: 4930

On 9/27/2024 10:16 AM, Dan Cross wrote:
> In article <vd6dh4$nrif$1@dont-email.me>,
> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>> On 9/27/2024 9:18 AM, Craig A. Berry wrote:
>>>          The only thing I can think of that hasn't already been mentioned
>>> is that Tomcat code is JIT-compiled, which is likely to be pretty good,
>>> optimized code, whereas Apache is probably either cross-compiled or
>>> native-compiled with an early enough field test compiler that there are
>>> no optimizations.
>>
>> That is a possible explanation.
>>
>> But the difference in numbers are crazy big.
>>
>> Apache getting a static text file with 2 bytes: 22 req/sec
>>
>> Tomcat with Quercus and PHP getting data out of a MySQL database on
>> Windows and outputting HTML: over 200 req/sec
>>
>> Tomcat using JSP (which get triple compiled) getting data out of a MySQL
>> database on Windows (with db connection pool) and outputting HTML: over
>> 600 req/sec.
>>
>> My gut feeling is that cross-compilation may contribute to but not
>> fully explain the difference.
> 
> Almost certainly not; this is an IO bound application, not CPU
> bound.

With static content yes.

With dynamic content and the volume Apache+mod_php delivers yes.

With dynamic content and high volume then CPU can matter. Tomcat
and Quercus can do over 200 req/sec, but CPU utilization fluctuate
between 150% and 250% - 4 VCPU used so not CPU bound, but could
have been if it had been just 2 VCPU.

> My strong suspicion is that what you're seeing is the result of
> a serious impedance mismatch between the multi-process model
> Apache was written to use, and its realization using the event
> signalling infrastructure on VMS.

Yes.

Or actually slightly worse.

Prefork MPM is the multi-process model used in Apache 1.x - it is still
around in Apache 2.x, but Apache 2.x on Linux use event or worker
MPM (that are a mix of processes and threads) and Apache 2.x on Windows
use winnt MPM (that is threads only).

> Again, I would try to establish a baseline.  Cut out the MPM
> stuff as much as you can;

MPM is the core of the server.

>                       ideally, see what kind of numbers you
> can get fetching your text file from a single Apache process.
> Simply adding more threads or worker processes is unlikely to
> significantly increase performance, and indeed the numbers you
> posted are typical of performance collapse one usually sees due
> to some kind of contention bottleneck.

It increases but not enough.

1 -> 0.1 req/sec
150 -> 11 req/sec
300 -> 22 req/sec

> Some things to consider: are you creating a new network
> connection for each incoming request?

Yes. Having the load test program keep connections alive
would be misleading as real world clients would be on different
systems.

>                                        It's possible that that's
> hitting a single listener, which is then trying to dispatch the
> connection to an available worker,

That is the typical web server model.

>                                     using some mechanism that is
> slow on VMS.

It is a good question how Apache on VMS is actually doing that.

All thread based solutions (OSU, Tomcat etc.) just pass a
pointer/reference in memory to the thread. Easy.

Fork create a process copy with the open socket. I am not quite
sure about the details of how it works, but it works.

If the model on VMS is:

---(HTTP)---parent---(IPC)---child

then it could explain being so slow.

I may have to read some of those bloody 3900 lines of code (in a
single file!).

>               Is there a profiler available?  If you can narrow
> down where it's spending its time, that'd provide a huge clue.

Or I take another path.

Arne