Re: Apache + mod_php performance

In article <vd7l3k$tgu3$4@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

On 9/27/2024 8:38 PM, Dan Cross wrote:

Hmm. You had already said that you were _Not_ using keep alives
because that would somehow mimic multiple machines querying
simultaneously.

>
That is correct.
>
The client was not using keep alive.

What protocol version was the client using, and what, exactly,
_is_ the client?  Was this some ersatz thing, or an actual load
testing tool of some kind?

But the server was configured to support keep alive.

Keep alive is the default for HTTP/1.1 (and I presume later,
though I haven't looked at HTTP/2 or HTTP/3 in much detail)
unless explicitly disabled.  KeepwAlive is optional in some
implementations of HTTP/1.0.

One wonders whether your client was using 1.1 and not sending a
`Connection: close` header.  Presumably the effect of that would
be that the server sends the requested data and then blocks for
some time waiting for another request, eventually closing the
connection when no such request is quickly forthcoming.  A 20
second timeout is reasonable.

Turning that capability off on the server solved the performance
problem.
>
No changes on client.
>
No keep alive used before - no keep alive used after.
>
Just disabling the capability on the server.

While I believe you've observed these results, I still think you
haven't sufficiently explored the problem.  Here's a test that
you may consider trying:

1. Re-enable the keep-alive configuration option and restart the
   server.
2. Use `telnet` or another command-line client of your choice to
   connect to the HTTP port on that server.
3. Type, `GET /path/to/nop.txt HTTP/1.1`
4. Hit return twice.

What do you observe?  How long does it take for data to be
returned, and then what happens?

This was, of course, the area of investigation I had suggested
to you previously to try and nail down the baseline.  I question
whether this will impact your single query latency, however, or
whether this is masking it in your benchmark.
 

nop.txt 281 req/sec
nop.php 176 req/sec
real PHP no db con pool 94 req/sec
real PHP db con pool 103 req/sec
>
Numbers are not great, but within acceptable.

 
What is your single query latency?  Not calculated, but
actually measured.

>
It is a rather uninteresting number.
>
But easy to test. It obviously vary a bit, but they
are all in the 50-100 millisecond range.

See above.

It is a bug in the code.

 
The evidence in hand is insufficient to make that claim.

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

See above.  There are many unanswered questions about this, and
about your experimental setup, that really ought to be addressed
before you consider the space sufficiently explored to draw
definitive conclusions.

- Dan C.