Re: Apache + mod_php performance

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