Re: Apache + mod_php performance

In article <66fd7bc6$0$715$14726298@news.sunsite.dk>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

On 10/2/2024 12:25 PM, Dan Cross wrote:

[snip]
So...Not a VMS problem at all.

>
The basic mechanism is not VMS specific at all.

That's odd, because in <vdjjl2$37f8q$1@dont-email.me> you wrote:

Or taking code designed for a different OS and expecting
it to work on another OS.

But that's clearly not the case here.

I assume that it is inherent in prefork MPM on all
platforms and other servers that use a similar
worker process model.
>
As I have noted a couple of times then back when
prefork MPM was common (20 years ago) then the question
about whether to have keep alive on or off was
often discussed.

I wonder if you forget that you had done that until today?

The problem does not seem to impact newer designs
using threads. They obviously still need to keep
the connection open, but I guess they do some
select/poll/epoll/whatever to detect when there is a
new request to keep resource usage minimal.
>
But the mechanism hits VMS harder than other platforms.

Nah.  The issue is pretty much the same.

The *nix fork is way more efficient than SYS$CREPRC for
creating those hundreds or thousands of worker processes.

This may be true, and it certainly is the common wisdom, but it
would be useful to provide an actual profile showing it to be
the case.

We can have fewer worker processes on VMS and it creates
longer delay to start them up.
>
As described above.

The real failure here is in mismatched expectations vis how the
protocol works and the server configuration.  If you wanted to
do this in a real shop, one would hope you'd have some sort of
caching load balancer in front of your apache servers.  Then
again, Apache is pretty long in the tooth for this kind of
thing.


- Dan C.