[dnsdist] dnsdist performance

[Klaus Darilion]

Hi Remi!

Am 11.08.2019 um 18:26 schrieb Remi Gacogne:
> Hi Klaus,
> 
> On 8/10/19 10:30 PM, Klaus Darilion wrote:
>> I had similar results. Starting 4 listening threads and 4 receivers
>> threads (by adding the same backend 4 times) boosted my performance -
>> almost linear.
> 
> Similar in terms of QPS as well? I just tested master on Arch using
> calidns and dumresp as a responder, and I get 55k+ QPS on my 10 year-old
> CPU using no tuning, simply:
> 
> ./dnsdist -C /dev/null -l 127.0.0.1:53 127.0.0.1:54
> 
> So one listening thread and one receiver thread.
> 
> A quick glance at a perf recording shows that more than 76% of the CPU
> time is spent in syscalls, so I'm pretty sure disabling the
> meltdown/spectre mitigations would do a big difference, but it's already
> pretty far from 5-15K QPS.

My results were:
1 VM with 4vCPUs. The VM runs NSD and PDNS/PGSQL. DNSDIST forwards some
zones to NSD, others to PDNS/PGSQL

PDNS with cached responses: 40.000 q/s
PDNS random labels: 9.000 q/s
NSD: 65.000 q/s

1. dnsdist with single "listen" and each backend added only once
dnsdist with cached responses: 40.000 q/s
dnsdist random labels to PDNS: 7.300 q/s
dnsdist random labels to NSD: 40.000 q/s

2. dnsdist with 3 "listen" and each backend added 3 times
dnsdist with cached responses: 100.000 q/s
dnsdist random labels to PDNS: 7.300 q/s
dnsdist random labels to NSD: 60.000 q/s

> If you increase the number of threads you'll need to use ring buffers
> sharding to limit contention, by the way.

Any config recommendation? I currently use a single Cache for both
backends with 1 shard:

cache = newPacketCache(500000, 10, 10, 60, 60, true, 1, true, 10)
getPool(""):setCache(cache)
getPool("static"):setCache(cache)


thanks
Klaus