On Wed, Oct 30, 2019 at 4:48 PM David Birdsong <david.birds...@gmail.com>
wrote:

>
> On Wed, Oct 30, 2019 at 11:39 AM Baptiste <bed...@gmail.com> 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

Reply via email to