Quantcast

(no subject)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

(no subject)

chiasa.men

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.

It works but each time I visit one of those sites the following

messages appear in apache's logs:

 

[00:00:39.641665] ---

[00:00:44.641883] [ssl:info] ssl_engine_io.c(675): (70007)The timeout

specified has expired: [client wwwclient:47122] AH01991: SSL input filter read

failed.

[00:00:44.642170] [ssl:info] ssl_engine_io.c(675): (70007)The timeout

specified has expired: [client wwwclient:47120] AH01991: SSL input filter read

failed.

[00:00:44.642442] [ssl:info] ssl_engine_io.c(675): (70007)The timeout

specified has expired: [client wwwclient:47118] AH01991: SSL input filter read

failed.

[00:00:44.642570] [ssl:info] ssl_engine_io.c(675): (70007)The timeout

specified has expired: [client wwwclient:47124] AH01991: SSL input filter read

failed.

[00:00:44.642977] [ssl:debug] ssl_engine_io.c(1016): -: [client wwwclient:

47118] AH02001: Connection closed to child 11 with standard shutdown (server

ww1.example.com:443)

[00:00:44.643241] [ssl:debug] ssl_engine_io.c(1016): -: [client wwwclient:

47124] AH02001: Connection closed to child 6 with standard shutdown (server

ww1.example.com:443)

[00:00:44.643373] [ssl:debug] ssl_engine_io.c(1016): -: [client wwwclient:

47120] AH02001: Connection closed to child 5 with standard shutdown (server

ww1.example.com:443)

[00:00:44.643560] [ssl:debug] ssl_engine_io.c(1016): -: [client wwwclient:

47122] AH02001: Connection closed to child 8 with standard shutdown (server

ww1.example.com:443)

[00:00:44.647119] [ssl:info] ssl_engine_io.c(675): (70007)The timeout

specified has expired: [client wwwclient:47116] AH01991: SSL input filter read

failed.

[00:00:44.647347] [ssl:debug] ssl_engine_io.c(1016): -: [client wwwclient:

47116] AH02001: Connection closed to child 3 with standard shutdown (server

ww1.example.com:443)

 

The corresponding access.log entries would be:

[00:00:39] "GET https://ww1.example.com/a/ HTTP/1.1" 503 4033 "-" "ua"

TCP_MISS:FIRSTUP_PARENT

[00:00:39] "GET https://ww1.example.com/some.js HTTP/1.1" 304 240 "https://

ww1.example.com/a/" "ua" TCP_MISS:FIRSTUP_PARENT

[00:00:39] "GET https://ww1.example.com/someother.js HTTP/1.1" 304 239

"https://ww1.example.com/a/" "ua" TCP_MISS:FIRSTUP_PARENT

[00:00:39] "GET https://ww1.example.com/more.js HTTP/1.1" 304 241 "https://

ww1.example.com/a/" "ua" TCP_MISS:FIRSTUP_PARENT

[00:00:39] "GET https://ww1.example.com/some.css HTTP/1.1" 304 277 "https://

ww1.example.com/a/" "ua" TCP_MISS:FIRSTUP_PARENT

[00:00:39] "GET https://ww1.example.com/someother.css HTTP/1.1" 304 277

"https://ww1.example.com/a/" "ua" TCP_MISS:FIRSTUP_PARENT

[00:00:39] "GET https://ww1.example.com/a.png HTTP/1.1" 304 241 "https://

ww1.example.com/a/" "ua" TCP_MISS:FIRSTUP_PARENT

 

 

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?

 

 

Regards

Chia


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (no subject)

Amos Jeffries
Administrator
On 23/04/17 23:25, [hidden email] 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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (no subject)

chiasa.men
Am Sonntag, 23. April 2017, 17:57:52 CEST schrieb Amos Jeffries:

> On 23/04/17 23:25, [hidden email] 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

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

  __
|"""\-=
(____)
  __
|"""\-=
(____)
(tanks)

Chia
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (no subject)

Amos Jeffries
Administrator
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, [hidden email] 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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (no subject)

chiasa.men
Am Freitag, 12. Mai 2017, 14:16:45 CEST schrieb 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, [hidden email] 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.
You are absolutely right.

>
> > 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.
I see. So I'll tell apache to set the KeepAliveTimeout to squids default
persistent_request_timeout of 2 minutes :)
That sounds reasonable.
Thank you for the explanation.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (no subject)

Alex Rousskov
On 05/12/2017 08:50 AM, chiasa.men wrote:
> Am Freitag, 12. Mai 2017, 14:16:45 CEST schrieb Amos Jeffries:
>> 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.

> I see. So I'll tell apache to set the KeepAliveTimeout to squids default
> persistent_request_timeout of 2 minutes :)

To avoid race conditions, the Apache timeout should be _larger_ than
Squid timeout. If Apache only talks to Squid, then it does not hurt to
set the Apache timeout to twice the value of Squid timeout. It is the
_smaller_ timeout that will effectively determine the number of idle
persistent connections between the two points in this case.

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Loading...