[squid-users] (no subject)

[Amos Jeffries]

On 12/05/17 22:31, chiasa.men wrote:
> Am Sonntag, 23. April 2017, 17:57:52 CEST schrieb Amos Jeffries:
>> On 23/04/17 23:25, chiasa.men at web.de wrote:
>>> Hello
>>>
>>> my squid.conf looks like that:
>>>
>>> https_port 3128 accel cert=/cert.pem key=/cert.key
>>>
>>> defaultsite=ww1.example.com vhost
>>>
>>> acl server20_domains dstdomain ww1.example.com ww2.example.com
>>>
>>> http_access allow server20_domains
>>>
>>> cache_peer server20 parent 443 0 no-query originserver name=server20
>>>
>>> login=PASSTHRU ssl sslversion=6
>>>
>>> cache_peer_access server20 allow server20_domains
>>>
>>> cache_peer_access server20 deny all
>>>
>>> The idea was to send ww1 and ww2 to server20 which is hosting an apache
>>>
>>> webservice for both sites.
>> That looks fine.
>>
>>> You can see that approximately after 5s the timeout happens. Is it a
>>> message
>>>
>>> to worry about? (it is just "info" labled) Why does it occur?
>> Unknown. This is an Apache problem. The Squid portion of things appears
>> to be working if I'm reading that weird  access.log correctly.
>>
>> Amos
> Acutally it's not. The problem seemed to be the
> server_persistent_connections setting in squid.conf.
> By default set to on it tries to keep the cache_peer connection. Apache on the
> other site hit the KeepAliveTimeout which was set to 5 seconds by default.
> server_persistent_connections off in squid.conf

So Squid is told (by Apache) that the connection is to be kept open / 
persistent and then Apache closes it very quickly afterward. That is an 
explicit configured problem, but still Apache endpoint is the cause of 
the issues you are having here.

It is not a bug or error for either software, since that is one of the 
behaviours explicitly allowed by HTTP. But for you its being a problem.


> It set server_persistent_connections to off and the problem disappeared.
> Is there any downside of this setting?

1) Every single HTTP request sent to any upstream server has to go 
through a full TCP connection handshake process, then a TCP shutdown 
process afterwards.

2) TCP socket cannot be used for a second connection until the kernel 
has confirmed both endpoints are not going to send anything on it. Which 
may be up to 15min.

Between them these can cause a 50ms extra latency on every request, with 
a limit of just over 70 requests per second through the proxy to any 
given server - compared to the several tens of thousands Squid can 
normally handle and under 1ms latency that is quite bad.


The efficient solution is to have long persistence on the connections 
between your CDN frontend (Squid) and the backend origins (Apache). You 
can make the timeout much shorter on the Squid client connections.

Amos