[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vd7l3k$tgu3$4 at dont-email.me>,
Arne Vajhøj  <arne at 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.