Path: ...!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: Wed, 2 Oct 2024 10:08:46 -0400
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <vdjk5e$37f8p$1@dont-email.me>
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> <vdj8os$3tq$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 02 Oct 2024 16:08:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bfe2fe5007a4a9fefa5101551fde2bc9";
	logging-data="3390745"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19KTugTqf9YUzB84cFJ+yMr+IURUrIVzRc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DV+NXDfYm9muKF14aNasjYgl1gI=
Content-Language: en-US
In-Reply-To: <vdj8os$3tq$1@reader1.panix.com>
Bytes: 4386

On 10/2/2024 6:54 AM, Dan Cross wrote:
> 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 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.

I said that it was not using it. And it is not. It is just
not informing the server that it has no intention of using it.

>> 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?

I have never expected that.

>> 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.

You are not making any sense.

It is perfectly valid per RFS to make HTTP 1.1 connections
without "Connection: close".

It is the normal case.

It is what browsers do.

Changing the test client to always send "Connection: close"
does improve performance for the test client.

But it does not improve performance for the browsers that
do not send "Connection: close".

There is no point on improving test results for a test
program by having the test program do something that the browsers
it is simulating does not.

Arne