Path: ...!fu-berlin.de!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Sat, 28 Sep 2024 20:50:21 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Apache + mod_php performance
Newsgroups: comp.os.vms
References: <vcv0bl$39mnj$1@dont-email.me> <vcvmu1$3cnv1$2@dont-email.me>
 <vd10re$nmp$1@reader1.panix.com> <vd1bdp$3npm3$1@dont-email.me>
 <vd1lgd$dbq$1@reader1.panix.com> <vd1u8j$3qqpg$1@dont-email.me>
 <vd7hbi$tgu3$2@dont-email.me> <66f8183e$0$715$14726298@news.sunsite.dk>
Content-Language: en-US
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
In-Reply-To: <66f8183e$0$715$14726298@news.sunsite.dk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 99
Message-ID: <66f8a44c$0$716$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 87974db4.news.sunsite.dk
X-Trace: 1727571021 news.sunsite.dk 716 arne@vajhoej.dk/68.14.27.188:51537
X-Complaints-To: staff@sunsite.dk
Bytes: 3554

On 9/28/2024 10:52 AM, Arne Vajhøj wrote:
> On 9/27/2024 8:07 PM, Arne Vajhøj wrote:
>> And we have a solution.
>>
>> httpd.conf
>>
>> KeepAlive On
>> ->
>> KeepAlive Off
>>
>> And numbers improve dramatically.
>>
>> 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.
>>
>> It is a bug in the code.
>>
>> Comment in httpd.conf say:
>>
>> # KeepAlive: Whether or not to allow persistent connections (more than
>> # one request per connection). Set to "Off" to deactivate.
>>
>> It does not say that it will reduce throughput to 1/10'th if on.
> 
> Note that the problem may not impact anyone in
> the real world.
> 
> I am simulating thousands of independent users using keep alive
> with a single simulator not using keep alive.
> 
> It could very well be the case that the problem only arise for
> the simulator and not for the real users.
> 
> Still weird though.

Another update.

Client side can also impact keep alive.

HTTP 1.0 : no problem
HTTP 1.1 with "Connection: close" header : no problem
HTTP 1.1 without "Connection: close" header : problem

Server side:

KeepAlive On -> Off

solves the problem. But obviously has the drawback of loosing
keep alive capability.

Not a disaster. Back in the early 00's when prefork MPM was
common, then KeepAlive Off was sometimes suggested for high
volume sites. But inconvenient.

With KeepAlive On then we have a performance problem.

The cause is that worker processes are unavailable while
waiting for next request from client even though client is
long gone.

That indicates that the cap is:

max throughput (req/sec) = MaxClients / KeepAliveTimeout

The formula holds for low resulting throughput but it does
not scale and seems to be more like 1/3 of that for higher
resulting throughput.

But if one wants keep alive enabled, then it is something one
can work with.

My experiments indicate that:

KeepAlive On
KeepAliveTimeout 15 -> 1
MaxSpareServers 50 -> 300
MaxClients 150 -> 300

is almost acceptable.

nop.txt : 100 req/sec

And 1 second should be more than enough for a browser to request
additional assets within a static HTML page.

But having hundreds of processes each using 25 MB for serving a 2 byte
file at such a low throughput is ridiculous.

OSU (or WASD) still seems as a better option.

Arne