Different backends will have different characteristics - some will want to have more parallel instances than others. In general, if your backend is latency bound, like most relational databases are, it pays to open more backends.
This is done with the distributor-threads setting. Of special importance is the choice between 1 or more backends. In case of only 1 thread, PDNS reverts to unthreaded operation which may be a lot faster, depending on your operating system and architecture.
Another very important setting cache-ttl. PDNS caches entire packets it sends out so as to save the time to query backends to assemble all data. The default setting of 10 seconds may be low for high traffic sites, a value of 60 seconds rarely leads to problems.
To determine if PDNS is unable to keep up with packets, determine the value of the qsize-q variable. This represents the number of packets waiting for database attention. During normal operations the queue should be small.
If it is known that backends will not contain CNAME records, the skip-cname setting can be used to prevent the normally mandatory CNAME lookup that is needed at least once for each DNS query.
Much the same holds for the wildcards setting. On by default, each non-existent query will lead to a number of additional wildcard queries. If it is known that the backends do not contain wildcard records, performance can be improved by adding wildcards=no to pdns.conf.
PDNS by default uses the 'PacketCache' to recognise identical questions and supply them with identical answers, without any further processing. The default time to live is 10 seconds. It has been observed that the utility of the packet cache increases with the load on your nameserver.
Not all backends may benefit from the packetcache. If your backend is memory based and does not lead to context switches, the packetcache may actually hurt performance.
The size of the packetcache can be observed with /etc/init.d/pdns show packetcache-size