[Info-vax] Apache + mod_php performance

Arne Vajhøj arne at vajhoej.dk
Wed Oct 2 10:08:46 EDT 2024


On 10/2/2024 6:54 AM, Dan Cross wrote:
> In article <66fc8d31$0$716$14726298 at news.sunsite.dk>,
> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>> On 10/1/2024 7:55 PM, Dan Cross wrote:
>>> In article <66fc58ce$0$708$14726298 at news.sunsite.dk>,
>>> Arne Vajhøj  <arne at 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









More information about the Info-vax mailing list