On Wed, Oct 30, 2019 at 4:48 PM David Birdsong <[email protected]> wrote:
> > On Wed, Oct 30, 2019 at 11:39 AM Baptiste <[email protected]> wrote: > >> Thanks! >>> >>> It had that feel to it...seemed like a cache lock timeout and/or somehow >>> tied to the request interval. >>> >>> >> I think I know where to fix this behavior in the code. I will work on the >> "how to fix it" later tonight. >> In the meantime, you can apply the workaround below. This is doable >> because the DNS cache is per resolvers section: >> 1. create a second dummy DNS section: >> resolvers main_resolver_do-resolve >> nameserver dns1 8.8.8.8:53 >> >> which is a copy of the first one with a different name. >> >> 2. reference this new resolvers section in your do-resolve action: >> http-request do-resolve(txn.myip,main_resolver_do-resolve,ipv4) >> hdr(Host),lower >> >> And you should be good until I fix it and it's backported. >> > > Awesome, thanks! > > Quick question: should I pay attention to timer: Tr as a proxy for both > request received and DNS latency? I'm guessing that the capture and > dns-resolve cause delays in haproxy fully reading the request in, is that > right? > Capture should not take generate any delays. do-resolve does :) And yes, from what I saw, it is reported in HAProxy's Tr, so yes, you are correct. Baptiste
