[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <66fd7bc6$0$715$14726298 at news.sunsite.dk>,
Arne Vajhøj  <arne at 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 at 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.