-----Original Message----- From: "Jeremy C. Reed" <jr...@isc.org> Date: Friday, November 30, 2012 4:18 PM To: "Adamiec, Lawrence" <ladam...@kentlaw.iit.edu> Cc: "bind-users@lists.isc.org" <bind-users@lists.isc.org> Subject: Re: another performance tuning question
>On Fri, 30 Nov 2012, Adamiec, Lawrence wrote: > >> I got similar results when running against the master server. > >Then why so many lost? > >> Queries sent: 11000 queries >> Queries completed: 8968 queries >> Queries lost: 2032 queries >... >> Percentage completed: 81.53% >> Percentage lost: 18.47% > >Look at your queryperf data file and figure out what is not hosted by >you. Some of my systems get around 60,000 QPS with none lost. If >really do host these on same system, and are really lost, then will need >other research. > >Even if you are doing recursive work, your results are quite slow. you >may want to look in your queryperf input to see what is causing >problems. (It may not be a realistic, real world input set.) Based on your "hosted by you" reference, I assume 60K QPS was only resolving local names? If not I'd love to see the config. Some extra data points for the OP: I might have misread (or be mis-remembering since I last tested), but I think the default resperf query file includes ten million "real-world" entries -- if testing recursion, try it vs generating your own. If you are not just doing local queries, from experience server hardware (physical or virtual) and bandwidth play a big part in the numbers. More cores = more worker threads, faster connectivity to upstream servers = more responses. With the default resperf query file and drop rate capped at 1%, I was able to get ~20K qps w/ four vCPUs vs ~5K with one vCPU (VMware, RHEL, BIND 9.8). _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users