Deutsch   English   Français   Italiano  
<vdaecr$1es94$2@dont-email.me>

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

Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Sat, 28 Sep 2024 22:35:07 -0400
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <vdaecr$1es94$2@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> <vdab8a$1facd$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 29 Sep 2024 04:35:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bc06a8f6134385e116c9cfce5e1ddc31";
	logging-data="1536292"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tr4kJfs30H/TtBii4lWrIGzRCbSq1F9g="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:AYY5MF+xi0X2gWFMvD5e2o+9RiY=
Content-Language: en-US
In-Reply-To: <vdab8a$1facd$7@dont-email.me>
Bytes: 2485

On 9/28/2024 9:41 PM, Lawrence D'Oliveiro wrote:
> 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.

OK. Then it sounds like the client doesn't actually close the socket
but just stop using it and move on to a new connection.

I wonder why the HttpClient library does not do an actual close. But
it may be the best simulation of a browser - the browser doesn't know
if the user will want to view another page at the same site, so it
probably don't close the socket.

I also wonder why "Connection: close" header exist in request if the
client could just close the socket. But doesn't change how things
are.

Arne