Hello everyone, I've just set up tinydns on a test box and I was wondering if there is a free testing tool available to query the name server repeatedly. NOTE: I want to test tinydns' performance alone --- the machine does NOT have dnscache running.
Basically, what I want to do is hit the name server with a bunch of queries simultaneously for a period of time and then monitor the load on the box. Is there any testing tool to do this?
The only performance statistics I could find for tinydns were here: http://cr.yp.to/djbdns/faq/tinydns.html#speed
Unfortunately, there aren't too many details here (like machine configuration and average load). Does anyone have any other information.
Thanks in advance.
>> Is there any testing tool to do this?
Maybe you should check out http://matt.simerson.net/computing/dns/
>> Unfortunately, there aren't too many details here
And here -> http://cr.yp.to/djbdns/knowles.html
Sometime you don't really need to perform any testing. Based on the design flaws and bad implementation of BIND you can assure (with common sense) that BIND must be much slower than djbdns.
Last edited by freebsd; May 29th, 2002 at 10:10 PM.
Thanks for the links. I just needed some figures so that I could show the other guys that the performance was way more than what we need. I was pretty much sold on djbdns just on the fact that the domains reload a heck of a lot faster than they do on bind.
For the record, the stats were as follows:
Current Production Boxes
CPU: One Single and One Dual 400 Mhz Pentium II
Memory: 256 MB
Services running: rsync, sshd, named
OS: Linux 2.4.13 (custom kernel builds on both)
Hard Drives: IBM DDRS-39130D SCSI Drives (Mylex DAC960 controller and hardware RAID enabled)
Nameserver: Bind 8.x.x (latest patches)
My test box
CPU: Single CPU Pentium III Celeron 550 Mhz
Memory: 128 MB
Services running: Apache, MySQL, XFree86 4.0, Blackbox, sshd, vncserver, 2 copies of Emacs, Gimp, tinydns.
OS: FreeBSD 4.5-RELEASE-p4 (custom kernel build)
Hard Drive: Maxtor 52049U4 IDE drive
Nameserver: djbdns 1.05
Not quite the same hardware wise, but I figure that the production boxes had more RAM and fewer services running, so the odds should be evened out a little. Besides, my test box is just that ... a box for me to play around with .
# of domains used: 131785 (basically our live configuration)
For both cases, perl programs were used to build the configuration file(s), which were then moved to the appropriate directories.
Time taken to reload named (running killall -HUP named): 4.25 hours (approx)
Time taken to reload djbdns (running make): 20 seconds (approx). Size of data.cdb = 139 MB
At this point, I was pretty much sold on djbdns
Last edited by Scorpions4ever; May 31st, 2002 at 04:19 PM.
Thanks for that link. Currently we have a whole system in place where the support team manages domains for different customers and such, so I currently build the information based on a table off the database, but the other information is certainly useful to know
>> And for maximum performance and reliability you should use dnscache for the caching part.
If I understand correctly, dnscache is a resolver. At this point, I only want to run authoritative nameservers on those boxes, so I don't think I'll need dnscache for that (isn't this correct?). I'm thinking that for tuning the performance, I'm going to turn off logging (except for stats) and maybe symbolic link data.cdb from a RAM disk, if necessary. Is there anything else that comes to mind right away?
At this point, we're still transferring some servers from our old co-lo facility to the new one, so the new nameservers won't be up yet. However, I think I've managed to convince the rest of the guys that tinydns is the way to go. Around the end of this month, I'll have my mitts on a few boxes to set things up on. Will post actual performance stats and figures then, if anyone is interested.
>> I'm going to turn off logging (except for stats)
The stats line is for dnscache, not tinydns.
>> maybe symbolic link data.cdb from a RAM disk
That would help. As you probably know, that data.cdb is read in real-time, not being stored in memory.