You are correct, the DNS server (Google Public DNS) isn't responding
to the requests. I don't know if this is because the UDP packets are
getting lost due to the flood generated, or if it thinks it's an
attack.
Ramming dnsmasq in the middle fixes it, but I don't really understand
why, as the test only generates 26*2=52 requests, and dnsmasq is
supposed to have a default concurrency of 150. Both generate, as far
as I can see, identical dns packets. dnsmasq takes about 200ms to
transmit them, whereas nginx only takes about 30ms, maybe that's
sufficient.
At least this isn't something scarily wrong with the http2 support,
which was what was worrying me. Cheers!
On 10 October 2016 at 12:58, Valentin V. Bartenev <vbart@nginx.com> wrote:
> On Monday 10 October 2016 12:34:18 Chris West wrote:
>> If you enable http2, our proxy setup develops 5s hangs, under load.
>> This happens from at least Chrome/linux, Firefox/linux and Edge/win10.
>>
>> Any suggestions on how to further diagnose this problem, or work out
>> where this "5 second" number is coming from? Full reproduction config
>> and debug logs are attached, but I don't understand the debug logs.
>>
>>
>> This isn't always reproducible, but happens frequently. Changing
>> browser, restarting nginx, ... doesn't cause it to be immediately
>> reproducible.
>>
> [..]
>> 2016/10/10 11:17:31 [debug] 4058#4058: *238 http2 frame complete
>> pos:00007F536315501D end:00007F536315501D
>> 2016/10/10 11:17:36 [debug] 4058#4058: *238 http upstream resolve:
>> "/proxy/nettesto....?"
>> 2016/10/10 11:17:36 [debug] 4058#4058: *238 name was resolved to 94.23.43.98
>> 2016/10/10 11:17:36 [debug] 4058#4058: *238 name was resolved to
>> 2001:41d0:2:2c62::
> [..]
>
>
> Looks like the delay is created by your resolver (8.8.4.4 as set in your configuration).
> Please, also check the documentation and don't use any public DNS in the resolver
> directive: http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver
>
> | To prevent DNS spoofing, it is recommended configuring DNS servers in a properly
> | secured trusted local network.
>
> wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
