[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vdjjpv$37f8q$2 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 10/2/2024 9:31 AM, Dave Froble wrote:
>> On 10/1/2024 4:17 PM, Arne Vajhøj wrote:
>>> On 10/1/2024 3:45 PM, Dan Cross wrote:
>>>> In article <vd9mqn$1cm1v$1 at dont-email.me>,
>>>> Dave Froble  <davef at 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 does if the server is holding the connection open, waiting for more.
>
>Not really.
>
>The real goal is to make it work well for users not to make the
>test program work well.
>
>Having the test program send "Connection: close" will improve
>performance for the test program.
>
>But it does not improve anything for the web browsers that
>does not send "Connection: close".

If a web browser sends an HTTP/1.1 request without the
`Connection: close` header, it's likely that it wants that
connection to be persistent, presumably so that it can use it
for another request.

You do not seem to understand how this is qualitatively
different from your test program not sending `Connection: close`
with its single request per connection, and then blocking until
the server times it out.

Do you understand that the protocol definition specifies that
the connection should be persistent unless the client says
differently via the `Connection: close` header?

	- Dan C.