Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Thu, 3 Oct 2024 23:30:49 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vdn9f9$gut$1@reader1.panix.com>
References: <vcv0bl$39mnj$1@dont-email.me> <vdmokf$3r6ke$1@dont-email.me> <vdmvg1$onj$1@reader1.panix.com> <vdn1tr$3sh36$1@dont-email.me>
Injection-Date: Thu, 3 Oct 2024 23:30:49 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="17373"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 3051
Lines: 45

In article <vdn1tr$3sh36$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
>On 10/3/24 3:40 PM, Dan Cross wrote:
>
>> The issue here is that a browser may open a connection to the
>> server and the user may wander away; if that connection is
>> persistent, then it's going to tie up an Apache instance, since
>> the user has gone to get a cup of coffee or whatever and isn't
>> actively using it.
>> 
>> Of course, this isn't specific to VMS, or a function of how VSI
>> ported it or whatever else Arne initially thought. 
>
>What's specific to VMS is that pre-fork MPM is the only game in town if
>you want to use Apache.  Whether the other mechanisms in use on other
>platforms and designed specifically to address the problem Arne
>encountered could be made to work on VMS is an open question, but not
>something anyone outside VSI could try without the sources.  I think
>event is out because there is no kqueue or epoll.  The worker model
>might be possible.  Or a custom one using ASTs instead of pthreads.

Apache is open source, it would be possible for someone outside
of VSI to mount a porting effort and do a threads backend.  But
I do take your point that that would be a bit of work, versus
modifying what VSI has already done.

It strikes me that `select` is surely available; this could be
used to increase scalability quite a bit.  It's not as nice as
kqueue or epoll or whatnot, but it's better than synchronous
reads blocking on a single socket.  Sadly, any of these would
be subject to head-of-line blocking, but it would scale _better_
than the prefork-MPM stuff, provided the time to serve requests
is relatively small (and it probably is).

Of course, there's a limit to what one can do with a single HTTP
server instance using _any_ model, be it threads, pre-created
processes, or some sort of event-driven async task model.  And
then there's a limit to what one can do on a single machine,
real or virtual.  Once you hit a certain scale, you just have to
be a bit more circumspect with design, and in particular,
capacity planning; that's where things like load balancers start
to come into play.

	- Dan C.