[squeak-dev] The Inbox: Monticello-ul.678.mcz
Levente Uzonyi
leves at caesar.elte.hu
Wed Mar 21 20:52:36 UTC 2018
On Wed, 21 Mar 2018, Tobias Pape wrote:
>
>> On 21.03.2018, at 02:43, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>>
>> On Tue, 20 Mar 2018, Chris Muller wrote:
>>
>>>> The code includes Connection: Keep-Alive header to support servers that
>>>> implement HTTP/1.0 only.
>>>
>>> Great. That just leaves the question whether the server is running
>>> 1.0 or 1.1. I should know that..
>>
>> As far as I know, the proxy server we use supports both and 2.0 too.
>
> Yes.
>
>> The proxy will communicate with the image with whatever version the image supports (probably 1.0), but that's less important regarding throughput.
>
> Also, If necessary I can make some changes so that the RevProx can serve the files directly...
> but not now ;)
Indeed, using x-accel-redirect would take some load off the image.
Levente
>
> -t
>
>>
>> Levente
>>
>>>
>>>> If you mean that these changes are unnecessary, because HTTP/1.1 already
>>>> defaults to persistent connections, then no, they are not. With the current
>>>> implementation, the client will close the socket once the request has
>>>> completed, and it will open a new connection for each subsequent request.
>>>
>>> Right. I didn't mean to imply the change was unnecessary, I'm just
>>> learning because I know you're an expert in this area.
>>>
>>>> If you think the speedup is negligible, then I suggest you backport it to a
>>>> 5.1 (or older) image (really easy, just file out the changes between
>>>> Monticello-cmm.677 and Monticello-ul.678 and file them into the 5.1 image)
>>>> and measure the difference in updating the image to a certain point (to
>>>> avoid broken updates and merges).
>>>
>>> Early versions of Magma opened a socket for each request, it was
>>> unbearable. It doesn't use HTTP, but fixing it to reuse the socket
>>> made a huge improvement in resource utilization and speed, as I know
>>> this change will for updating from trunk, too.
>>>
>>> I need to learn HTTP best practices.
>>>
>>
More information about the Squeak-dev
mailing list
|