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: Wed, 2 Oct 2024 10:54:20 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vdj8os$3tq$1@reader1.panix.com>
References: <vcv0bl$39mnj$1@dont-email.me> <66fc58ce$0$708$14726298@news.sunsite.dk> <vdi25q$f9h$1@reader1.panix.com> <66fc8d31$0$716$14726298@news.sunsite.dk>
Injection-Date: Wed, 2 Oct 2024 10:54:20 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="4026"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 3705
Lines: 68

In article <66fc8d31$0$716$14726298@news.sunsite.dk>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>On 10/1/2024 7:55 PM, Dan Cross wrote:
>> In article <66fc58ce$0$708$14726298@news.sunsite.dk>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 10/1/2024 3:45 PM, Dan Cross wrote:
>>>> In article <vd9mqn$1cm1v$1@dont-email.me>,
>>>> Dave Froble  <davef@tsoft-inc.com> wrote:
>>>>> On 9/27/2024 9:11 PM, Arne Vajhøj wrote:
>>>>> [snip]
>>>>>> I believe that server config supporting keep alive
>>>>>> causing performance to drop to 1/10'th for clients
>>>>>> not using keep alive is a bug.
>>>>>
>>>>> Feature ...
>>>>
>>>> Yes, it is a feature, despite this report of a non-problem.
>>>>
>>>> In this case, later posts revealed the real culprit: Arne's test
>>>> program did not follow the protocol, and was not sending
>>>> `Connection: close` with an HTTP/1.1 request; in response, the
>>>> server (correctly) kept the connection open waiting for the
>>>> client to send another request.
>>>
>>> It does not really make any sense for the test client
>>> to send "Connection: close".
>> 
>> It makes even less sense to implement the protocol improperly
>> and then blame the other side when it doesn't work the way you
>> expect, wouldn't you agree?
>
>Not sending "Connection: close" header is perfectly valid.
>And it is the normal scenario.

Indeed.  Because persistent connections are the default in
HTTP/1.1.  If you want the server to close the connection after
every request, which you said that you did, you would send
`Connection: close`.

>Sending "Connection: close" with every request is the client
>way to disable keep alive. And the unusual scenario.

Yes.  Colloquially, we call persistent connections "keep alive".
You were asked if your client was using keep-alive was disabled,
and you said that it was.  Clearly it was not.

>Disabling keep alive client side not surprisingly has
>the same effect as disabling keep alive server side.

Indeed.  I'm glad that you were able to recognize that, after
suggesting that there was a "problem" when the server didn't
close the connection when you didn't send `Connection: close`.
Why would you expect it to?

>But while disabling keep alive server side makes sense
>then it doesn't make sense to disable it client side.

Huh?  The RFC is quite clear on the behavior of persistent
connections and the use of the `Connection: close` header.  You
appear to have been sending HTTP/1.1 requests, sans header, and
then asserting that there was a bug in the server software when
it didn't behave as you expected.  Were you unable to understand
section 9.3 of RFC 9112, which I referred you to earlier?
https://www.rfc-editor.org/rfc/rfc9112#name-persistence

Again, it seems that the "bug" was yours.

	- Dan C.