Currently the Howto Optimize document (below url) leaves out some details and could use some clarification regarding the use of 'num-threads:'.
https://www.nlnetlabs.nl/documentation/unbound/howto-optimise/
Currently the default is one and the document says it can be set up to number of cores on the system.
Which makes sense for a busy server, not for most small/home use server. When using DoT forwarding upstream, too many threads will spread the requests across multiple tcp connections and most public DNS forwarders have shortened tcp timeout, example 10 seconds. Timed out connections can't be reused and results in a new tcp connection with 3 way handshake.
I have tested 11k sequential DoT lookups using 4 or 8 threads and it 90 minutes vs 1 thread taking 30 min.
One thread has been able on an old i7 4 core box easily handle 500-1000 requests per second.
Also noted during testing that TCP fast open with TLS does not seem to be working, which would improve testing times.
So recommendation is changing the below line:
Set num-threads equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.
to something like this:
Set num-threads to a range of 1 thru number of CPU cores in the system. E.g. for 4 CPUs with 2 cores each, use 8.
This should only be raised for busy servers, more threads uses more memory and increase chances of TCP timeout when using forwarding over DoT, resulting in slower lookups do to closed connections and TCP's 3 way handshake to build new connections.
Currently the Howto Optimize document (below url) leaves out some details and could use some clarification regarding the use of 'num-threads:'.
https://www.nlnetlabs.nl/documentation/unbound/howto-optimise/
Currently the default is one and the document says it can be set up to number of cores on the system.
Which makes sense for a busy server, not for most small/home use server. When using DoT forwarding upstream, too many threads will spread the requests across multiple tcp connections and most public DNS forwarders have shortened tcp timeout, example 10 seconds. Timed out connections can't be reused and results in a new tcp connection with 3 way handshake.
I have tested 11k sequential DoT lookups using 4 or 8 threads and it 90 minutes vs 1 thread taking 30 min.
One thread has been able on an old i7 4 core box easily handle 500-1000 requests per second.
Also noted during testing that TCP fast open with TLS does not seem to be working, which would improve testing times.
So recommendation is changing the below line:
Set num-threads equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.
to something like this:
Set num-threads to a range of 1 thru number of CPU cores in the system. E.g. for 4 CPUs with 2 cores each, use 8.
This should only be raised for busy servers, more threads uses more memory and increase chances of TCP timeout when using forwarding over DoT, resulting in slower lookups do to closed connections and TCP's 3 way handshake to build new connections.