Re: Apache + mod_php performance

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