| 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