[dnsdist] dnsdist performance

[Klaus Darilion]

Hi Remi!

Am 14.08.2019 um 10:39 schrieb Remi Gacogne:
> Hi Klaus,
> 
> On 8/13/19 9:31 PM, Klaus Darilion wrote:
>> 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
> 
> That's interesting, thank you! I assume the "dnsdist with cached
> responses" lines are with dnsdist's packet cache enabled? If so I'd be
> interested in knowing the results without any packet cache in dnsdist
> but with the packet cache in PDNS enabled.

First I have to say that my q/s values fluctuate quite strong, +-3000
q/s. So, these values show more a trend than exact results.

Yes, "dnsdist with cached responses" means that dnsdist has a cache and
I query always the same domain.

Now, I disabled the dnsdist-cache and tested again:

dnsdist w/o cache random labels to PDNS: still around 7300 q/s
dnsdist w/o cache static label to PDNS (cached responses): still around
4000 q/s.

Hence, dnsdist without cache has no impact when the results are coming
from PDNS packet cache, but seems to have impact when the results are
not cached by PDNS.

>>> 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)
> 
> I'd advise the use of more shards since it will pretty much get rid of
> the contention between the threads, although it might not matter that
> much at this level of QPS. A value like 50 should be enough for 6
> threads but in some setups I have used values up to 1000 shards. The
> sweet spot depends on your exact setup.
> 
> Note that this is the number of shards in the packet cache, not the ring
> buffers. Even if you don't use the packet cache it would be a good idea
> to shard the ring buffers as soon as you use several threads, with:
> 
> setRingBuffersSize(10000, 16)
> 
> which keeps the default value for the number of entries to keep in
> memory but use 16 shards instead of 1, reducing lock contention there as
> well.

I guess in my setup, where I only have one backend, the backend is the
bottleneck, not the dnsdist cache. Anyway, I just tested with:

setRingBuffersSize(10000, 16)
cache = newPacketCache(500000, 10, 10, 60, 60, true, 50, true, 10)

instead of
cache = newPacketCache(500000, 10, 10, 60, 60, true, 1, true, 10)

and do not see a difference (which is more than my q/s jitter)

Thanks
Klaus