[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vdjk5e$37f8p$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>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.

So then it was, because it's the default to use it unless the
client tells it otherwise, or you explicitly disable it in the
server configuration.

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

Apparently you did.  You said there was a "problem" when you
made an HTTP/1.1 request without the `Connection: close` header.

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

No, I'm afraid you are just confused.

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

I don't think you understand how the protocol works, or how a
browser might use it.  A browser will opportunistically reuse a
persistent connection; evidently, your test program does not.

In your test program, you had some number of threads sending
requests to the server; those requests did not include a
`Connection: close` header.  But those threads received the
expected response from the server, but then paused waiting for
the server to close the connection, which it did after the
`KeepAliveTimeout` number of seconds.  What did you expect the
server to do differently?  Why you were surprised by the results
you observed?

For some strange and unexplained reason, you then concluded that
the server had a bug.  That makes no sense.

	- Dan C.