Deutsch   English   Français   Italiano  
<vdab8a$1facd$7@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Sun, 29 Sep 2024 01:41:31 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <vdab8a$1facd$7@dont-email.me>
References: <vcv0bl$39mnj$1@dont-email.me> <vcvmu1$3cnv1$2@dont-email.me>
	<vd10re$nmp$1@reader1.panix.com> <vd1bdp$3npm3$1@dont-email.me>
	<vd1lgd$dbq$1@reader1.panix.com> <vd1u8j$3qqpg$1@dont-email.me>
	<vd7hbi$tgu3$2@dont-email.me> <66f8183e$0$715$14726298@news.sunsite.dk>
	<66f8a44c$0$716$14726298@news.sunsite.dk> <vda9tl$1facd$1@dont-email.me>
	<vdaala$1es94$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 29 Sep 2024 03:41:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="22838b7286fd66ecaa0be3d192bfd789";
	logging-data="1550733"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/MVU0yB0aX2lBRHXyzhrzR"
User-Agent: Pan/0.160 (Toresk; )
Cancel-Lock: sha1:4qoemN1Rz8gbvUxVk2L9/Eg9xYc=
Bytes: 2491

On Sat, 28 Sep 2024 21:31:22 -0400, Arne Vajhøj wrote:

> On 9/28/2024 9:18 PM, Lawrence D'Oliveiro wrote:
>>
>> On Sat, 28 Sep 2024 20:50:21 -0400, Arne Vajhøj wrote:
>>
>>> The cause is that worker processes are unavailable while waiting for
>>> next request from client even though client is long gone.
>> 
>> That shouldn’t matter, if the client closed the connection properly.
> 
> It doesn't know the client closed connection.

That would only happen if the client crashed.

Note also that TLS connections require an explicit connection-closing 
exchange at the end, to guard against data-truncation attacks.

>> Also, why shouldn’t a worker handle a request for another client?
> 
> This is singlethreaded all sync workers so when they wait for a new
> request from an existing client, then they can't handle a new client.

Why not? The whole point of fork(2) is that all the processes are 
effectively clones. If you put all the client context into shared memory 
sections, then it becomes possible for any process to service any client.

Of course, I’m assuming that all the processes can share the same network 
socket connections. This might not be true under VMS ...