Sujet : Re: Apache + mod_php performance
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.os.vmsDate : 04. Oct 2024, 00:30:49
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vdn9f9$gut$1@reader1.panix.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
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.