[Info-vax] Apache + mod_php performance

[Arne Vajhøj]

On 9/27/2024 10:16 AM, Dan Cross wrote:
> In article <vd6dh4$nrif$1 at dont-email.me>,
> Arne Vajhøj  <arne at 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