Deutsch   English   Français   Italiano  
<66fc8d31$0$716$14726298@news.sunsite.dk>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!news.swapon.de!fu-berlin.de!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Tue, 1 Oct 2024 20:00:49 -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> <vd9mqn$1cm1v$1@dont-email.me>
 <vdhjhb$oid$1@reader1.panix.com> <66fc58ce$0$708$14726298@news.sunsite.dk>
 <vdi25q$f9h$1@reader1.panix.com>
Content-Language: en-US
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
In-Reply-To: <vdi25q$f9h$1@reader1.panix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 43
Message-ID: <66fc8d31$0$716$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: c64a4917.news.sunsite.dk
X-Trace: 1727827249 news.sunsite.dk 716 arne@vajhoej.dk/68.14.27.188:49514
X-Complaints-To: staff@sunsite.dk
Bytes: 2591

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 article <vd9mqn$1cm1v$1@dont-email.me>,
>>> Dave Froble  <davef@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 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.

Sending "Connection: close" with every request is the client
way to disable keep alive. And the unusual scenario.

Disabling keep alive client side not surprisingly has
the same effect as disabling keep alive server side.

But while disabling keep alive server side makes sense
then it doesn't make sense to disable it client side.

Arne