trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Payne <jp557...@gmail.com>
Subject Re: Trying to understand no-activity timeouts
Date Wed, 24 Jun 2020 21:47:22 GMT
do you have a packet trace between child and parent during this 20s ttfb ?

ill retest, but in 7.x
'proxy.config.http.parent_proxy.connect_attempts_timeout'
usually applies to both connection setup and ttfb.



On Wed, Jun 24, 2020 at 3:54 PM Nick Dunkin <Nick.Dunkin@vecima.com> wrote:

> Hi Jeremy,
>
>
>
> We are currently on 7.1.4
>
>
>
> This issue seems to only occur when the Origin server does nothing other
> than accept the connection.  We mocked up an Origin server and experimented
> with “trickling the data” versus “waiting before sending the first byte”
> and the latter seems to be where we can’t get the timeout behavior we
> desire.
>
>
>
> Many thanks
>
>
>
> Nick
>
>
>
> *From: *Jeremy Payne <jp557198@gmail.com>
> *Reply-To: *"users@trafficserver.apache.org" <
> users@trafficserver.apache.org>
> *Date: *Wednesday, June 24, 2020 at 3:57 PM
> *To: *"users@trafficserver.apache.org" <users@trafficserver.apache.org>
> *Subject: *Re: Trying to understand no-activity timeouts
> *Resent-From: *<Nick.Dunkin@ccur.com>
>
>
>
> yes.. what version of ATS are you using ?
>
>
>
>
>
> On Wed, Jun 24, 2020 at 1:32 PM Nick Dunkin <Nick.Dunkin@vecima.com>
> wrote:
>
> Hi Jeremy,
>
>
>
> Thanks for the reply.
>
>
>
> We did try that, but it did not behave as we expected, we still
> experienced a long response.  Have you used this parameter with parent
> routing with predictable results?
>
>
>
> Cheers
>
>
>
> Nick
>
>
>
> *From: *Jeremy Payne <jp557198@gmail.com>
> *Reply-To: *"users@trafficserver.apache.org" <
> users@trafficserver.apache.org>
> *Date: *Wednesday, June 24, 2020 at 8:16 AM
> *To: *"users@trafficserver.apache.org" <users@trafficserver.apache.org>
> *Subject: *Re: Trying to understand no-activity timeouts
>
>
>
>
>
> try setting this parameter.
>
>
>
> proxy.config.http.parent_proxy.connect_attempts_timeout
>
>
>
>
>
> On Tue, Jun 23, 2020 at 12:33 PM Nick Dunkin <Nick.Dunkin@vecima.com>
> wrote:
>
> Hi,
>
>
>
> We are still dealing with a particular kind of no-activity time out issue.
>
>
>
> We are dealing with an Origin that will occasionally take 20 seconds to
> return a HTTP 500 (annoying, right).  We took a tcpdump and captured this
> occurring.  In the trace we can see the /GET and the ACK, and then a full
> 20 seconds (approx) before the HTTP 500 comes back.  Please see the below
> picture.
>
>
>
> [image: A screenshot of a cell phone Description automatically generated]
>
>
>
> To be clear, apart from accepting the connection, the Origin Server sends
> NOTHING over the connection during the 20 seconds.
>
>
>
> *Without Parent Routing*
>
>
>
> This looks very much like something the Origin side “no-activity” timeouts
> should cater for, so we set both of the following (for good measure) to 2
> seconds, but we still see exactly the same thing occurring.
>
>
>
> *CONFIG proxy.config.http.transaction_active_timeout_out INT 2*
> * CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 2*
>
>
>
> We managed to resolve this particular issue by using adding the following
> configuration, which is a “timeout to first byte”.  Is this the correct
> configuration solution for dealing with this issue?
>
>
>
> *CONFIG proxy.config.http.connect_attempts_timeout INT 2*
>
>
>
> This all seems to make sense based on the available documentation.  So far
> so good.
>
>
>
> *With Parent Routing*
>
>
>
> However, when we enable parent routing, and put the same single Origin
> Server in parent.config, we DO NOT see the “timeout to first byte” being
> applied.  *What are we missing about these timeouts and how they interact
> with parent routing*?
>
>
>
> This all seems to hinge on the fact that the Origin server *does not send
> a single byte *for multiple seconds.    We see more predictable behavior
> if the Origin Server serves *any* data before the 20 seconds hang.
>
>
>
> Very grateful for any insight.
>
>
>
> Regards,
>
>
>
> Nick Dunkin
>
>
>
>

Mime
View raw message