15 Srp
2016
15 Srp
'16
15:32
Hi Jan,
Thanks for your response. Some comments inline:
On 15-08-16 14:29, Jan Včelák wrote:
Hi Matthijs,
processing of queries in Knot DNS is synchronous. So the UDP thread is
blocked until the query processing is finished. This usually doesn't
matter for authoritative server because the server can construct the
response immediately.
For dnsproxy, this is a problem. The dnsproxy module establishes a TCP
connection to the resolver and waits for the answer. During that time
the UDP handler thread is just idling.
The dnsproxy AFAICS will use the same transport protocol as the incoming
query. In our tests this is all UDP. So I don't think any TCP connection
is established.
Also, the query is forwarded to an authoritative server nearby, not a
resolver, which should be a lot faster. There is still idle time of
course, and perhaps too much.
I'm affraid this couldn't be fixed easily
without deep changes in the
knotd architecture.
Anyway, we are interested in your discoveries.
Me too.
Best regards,
Matthijs
Cheers,
Jan
On 15.8.2016 14:12, Matthijs Mekking wrote:
Hi,
I recently tested the mod-dnsproxy performance and I am disappointed in
the results:
Knot in our test setup can do ~320K QPS.
When using our own proxy in front of knot, we achieve quite a
performance hit, only able to do ~120K QPS.
However, when configuring knot to use the mod-dnsproxy, the performance
drops to ~7K QPS.
I am planning to investigate what causes this significant drop, but if
you have any insights or other measurements already I would love to hear
about them.
Best regards,
Matthijs
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users