Test dnes: jak si vedl Knot DNS

Při příležitosti nedávné prezentace Knot DNS na Tech26 (CENTR Jamboree) jsme aktualizovali metodiku měření a chtěli bychom se podělit o nové výsledky.

Testování nyní proběhlo na syntetické zóně se zastoupením podporovaných RR typů na testovaných serverech (Knot DNS, BIND 9, NSD 3 a YADIFA[*]). Zóna obsahuje 1 324 899 záznamů, velikost zónového souboru je 76MB. Zároveň byly aktualizované testovací sady dotazů, které se nyní skládají z dotazů jak na existující, tak neexistující jména v poměru 1:1. Důvodem bylo prověřit výkon datových struktur serveru i při vyhledávání neexistujících jmen. Existující jména byla vybrána náhodným způsobem z tohoto zónového souboru. Konfigurace, zónový soubor, testovací sada pro program dnsperf (1 000 000 dotazů, 18MB) i syntetický provoz ve formátu pcap (50 000 dotazů, 4,2MB) jsou včetně dalších nástrojů volně ke stažení v Git repozitáři.

Prvním testem je škálovatelnost, kdy se měří závislost výkonu serveru na počtu spuštěných vláken/procesů. Výkon serveru je měřen programem dnsperf od společnosti Nominum. Tento test je specificky navržen pro měření výkonnosti autoritativních DNS serverů a mezi jeho přednosti patří regulace rychlosti dotazování, čímž poměrně věrně simuluje reálný síťový provoz. Jak je z grafu pro Linux patrné, podařilo se nám oproti verzi 1.0.3 vyřešit problém s plánováním vláken a nyní téměř dosahujeme naměřené propustnosti sítě. Ta byla změřena utilitou trafgen s malými UDP pakety (payload 60B) a zanesena do grafu. V případě tohoto testu nebylo možné určit u serveru Yadifa zadaný počet vláken, proto běží stále ve výchozím nastavení.


K testu škálovatelnosti nám přibyl nový test, který měří závislost podílu zodpovězených dotazů na rychlosti odesílaných odpovědí. Tento test byl dříve použit např. pro měření výkonnosti serveru NSD nebo nově Yadifa. V tomto testu figurují všechny tři stroje, kdy na prvním běží testovaný server, druhý pouze generuje provoz zadanou rychlostí a třetí zachytává odpovědi ze serveru. Pro testování byly využity standardní nástroje tcpreplaytcpdump. Ze získaných dat se vypočte procento zodpovězených dotazů pro danou rychlost. Každý test je třikrát opakován a jako výsledek se počítá průměrná hodnota. Z grafu je patrné, že Knot DNS 1.0.6rc1 i na Linuxu zodpověděl téměř všechny všechny dotazy zaslané maximální dosažitelnou rychlostí.

Samotné testování probíhalo na třech shodných strojích osazených procesorem Intel Xeon X3430 a 2GB RAM, propojených 1Gb ethernet linkou se síťovými kartami Broadcom BCM5723. První stroj slouží k běhu serveru, druhý ke generování dotazů a třetí k zachytávání odpovědí. Testy byly prováděny na 64bit OS Linux 3.0.0 a FreeBSD-8.2. V současné době je výkon omezen dosaženou propustností sítě, nicméně chystáme testování s rychlejší síťovou kartou a věříme, že je ještě prostor pro další zlepšení.

Marek Vavruša

* – Yadifa bohužel podporuje jen omezenou sadu RR typů, nicméně pro tento druh testování to nevadí

Autor:

Komentáře (11)

  1. Michal Smrž říká:

    Ty rozdílné barvy čar v jednotlivých grafech jsou silně matoucí.

  2. Stanislav Petr říká:

    Zdravim, nechteli by jste zkusit test jeste zopakovat s jinou sitovou kartou nez zminenym broadcomem? Napr. neco z levnejsich ale v serverech beznych Intelu, napr. 82574L nebo neco podobneho a s ovladacem e1000e verze 1.11.3 (s DMA burst mode). Tahle kombinace se zrovna me velice osvetcila pri techtech DNS serveru a byl tam znatelny rozdil oproti jinemu Broadcomu ktery byl v nasem DNS serveru puvodne…

  3. pha říká:

    suhlas, broadcom linux driver ma problemy pri zatazi, e1000e je o dost lepsia volba

  4. Tomáš Chvátal říká:

    Hmm, pridali byste pekne prosim do dalsich grafiku az je budete delat jeste unbound?

  5. Stanislav Petr říká:

    Srovnavat Unbound a Knot je absolutni blbost. Knot je vyhradne autoritativni DNS server a Unbound je vyhradne rekurzivni, takze neni co porovnavat. To ja jako resit jestli je rychlejsi lednicka nebo tramvaj…

  6. Ondřej Surý říká:

    Zrovna předevčírem přišel nový server na testování a je v něm určitě nějaká Intel síťovka. Až otestujeme, tak to zase dáme ven.

  7. Domlia říká:

    Taky jsem pro, aby byla otestována i jiná NIC.

  8. Marek Vavruša říká:

    Michal Smrž: Omlouvám se, barvy v grafech byly aktualizovány tak, aby to bylo konzistentní.
    Stanislav Petr a Domlia: Na novém serveru je zrovna e1000, která je bez debat lepší. Co jsem četl tak s ní dosáhli (při vypnutých flow control rámcích) až 1.5M pps při stejné velikosti paketů. Zjistím možnost výměny síťovek v původních testovacích serverech.

  9. Yenya říká:

    Ten rozdíl ve výkonu nsd na Linuxu a FreeBSD je docela výrazný. Tušíte, čím to může být? Je třeba možné, že nsd na Linuxu nevyužívá nějaké pokročilejší metody selektivního čekání (epoll třeba) a na FreeBSD ano (kqueue)?

    A pro zajímavost, co používá knot za událostní model?

  10. Marek Vavruša říká:

    Nerad bych o NSD nějak spekuloval, ale jako základ používají klasický multiplex pselect() nad sokety pro UDP/TCP (+vnitřním IPC) a to vše v několika nezávislých procesech. Mechanismy jako epoll nebo kqueue nepodporuje, ale ani nemají pro UDP valný smysl. Zrychlují totiž pouze sledování velké množiny soketů, což se hodí např. pro TCP nebo sledování velkého množství filedeskriptorů atp.

    Knot DNS naopak události nesdružuje a UDP, TCP a IPC obsluhuje zvlášť, každé trochu jinou metodou. Např. pro UDP se na Linuxu využívá recvmmsg() a sendmmsg() a není potřeba multiplex, pro TCP využíváme epoll/kqueue/poll podle platformy na které server běží a pro vnitřní komunikaci využíváme anonymní roury. Obecně jsme se snažili minimalizovat počet syscallů na obsluhu jednoho paketu, vyhnout se větším abstrakcím jako event loopy a pokud možno přizpůsobit způsob obsluhy soketů každé podporované platformě. Ještě bych dodal, že oddělení různých událostí umožňuje nastavit například odlišná privilegia pro UDP a modul zpracovávající transfery.

  11. mato říká:

    No nie len nsd, ale aj yadifa bezi na FreeBSD lepsie (a dokonca sa zda, ze trosicku aj knotd).

Zanechte komentář

Všechny údaje jsou povinné. E-mail nebude zobrazen.