Dobrý den,
děkujeme za reakci. V nejbližší době nemáme takovou funkci v plánu. V případě rozlišení na základě příjimajícího síťového rozhraní je možnost nakonfigurovat pro různá rozhraní různé instance serveru. Pro rozlišení na základě adresy odesílatele to samozřejmě nejde. Zařazení do dlouhodobého plánu však budeme zvažovat v případě, že by byl velký zájem ze strany uživatelů.
Z filozofickeho hlediska by spravne smerovani mel obstarat routing a ne DNS. DNS tu od toho neni. views jsou jen takova berlicka ktera ma zaplacnoust spatny design site na pocatku.
Pokud jde o views a a dmz versus non-dmz segment site tak je imho cistejsi ze systemoveho i sitoveho hlediska mit ruzne servery(resp. fyzicke procesy s rozdilnou konfiguraci) pro jednotlive ip adresy na kterych posloucha dns server.
Dobrý den,
ad 1/ s jistotou nemůžu říct. Bavili jsme se o tom už s vývojářem s NLnetu a můj osobní tip je, že může jít o anomálii na daném kernelu a HW. Momentálně provádíme nová měření na jádře 3.0
ad 2/ tady je chyba bohužel na mé straně, v benchmarku pro tento článek jsem měl chybu - nižší počet zadaných procesů než dostupných jader ignoroval. Tudíž je na grafu zobrazena nejlepší dosažená hodnota a není vidět škálování 1-3 procesů. A jak to bývá, odeslal jsem samozřejmě nepřegenerovaný graf. V nejbližší době budou grafy v článku opravené. Díky za upozornění a sypu si popel na hlavu.
A kdypak se objeví DEB a RPM balíčky? - Rozuměj jsem líný to kompilovat.
Jsou tam od začátku :-). Stačí jít na www.knot-dns.cz a kliknout na „Balíčky“.
Treba rovnou do ldapu a AD. A taky bych pridal podporu pro oracle,sybase,DB2,SOAP,XML-RPC a bsmlpsvz. Porad se mi zda ze nekomu nedochazi k cemu je Knot urcen a k cemu ne. Neni snad idea unixu mit jednoucelovy program ktery dela jednu cinnost ale dela ji naprosto dokonale? A neni to zrovna primarni ucel u neceho specifictejsiho jako server pro TLD? Na co vyrabet dalsi nabubrele gizmo?
Zdravim, zajimave vysledky. Gratuluju, je radost videt, jak se investice do vyvoje take muzou projevit. Ke grafu - netusim, jak vypada nsd vevnitr, ale pokud si pamatuju dobre, psal jste, ze Knot je navrzen tak, ze bud vubec zamykat nemusi, nebo minimalne.
Kdyz pominu anomalii nsd na ctyrech vlaknech, zda se mi, ze vykon stoupa do 3 vlaken a pak je vicemene konstantni. Tam bych cekal, ze bude nekde uzke hrdlo, coz by mohlo byt zamykani. To by mohlo vysvetlovat i to, ze jsou sice znatelne rychlejsi do tri vlaken, ale nedokazi toho vyuzit diky tomu, ze cast casu pak ztrati cekanim na vstupu do kritickych sekci, zatimco vy vesele vyuzivate strojovy cas ke zpracovani pozadavku. Tim, ze vy nezamykate (nebo minimalne), byste zrychlenim na jednom vlaknu, coz dle nsd je evidentne mozne, mohli ziskat dalsich 20-25% na kazdem vlaknu, na rozdil od nsd. Tim byste mohli byt na 4-5 vlaknech uz skoro 2x rychlejsi.
Jen spekuluju, ono se to na papire pocita hezky... Vy asi budete vedet, jestli to, co jsem popsal, je mozne.
Take mi prijde, ze u Knotu je pokles mezi 6 a 10 vlakny vetsi, nez co bych cekal, ze bude zpusobeno kontext switchi mezi vlakny. Rozdil je podle grafu skoro 25k dotazu, tedy vice nez 10%. Mate pro to nejake detailnejsi vysvetleni?
JP.
Díky za zpětnou vazbu. Určitě se výkonem budeme ještě zabývat, nicméně pro verzi 1.0 je nejdůležitější, aby Knot DNS obsahoval všechny důležité vlastnosti DNS, které jsme si naplánovali. Další cílenou optimalizací výkonu se budeme zabývat po stabilizaci současného kódu.
Každopádně si ale také myslíme, že je ještě možné dosáhnout dalšího zrychlení v jednom vlákně, nicméně to si následně zaslouží samostatnou analýzu toho, kde je současný kód pomalejší oproti NSD.
Zdravim,
zajimalo by me co zpusobilo podstatny rozdil ve vykonu freebsd oproti linuxu?
z grafu se zda ze Knot na freebsd dokaze zpracovat o 50 000 pozadavku za vterinu vice nez na linuxu. Rozdil je jeste vetsi u NSD.
Mam zkusenosti jen s provozem vytizenych webu (nginx, apache) nebo firewallu (iptables, pf), nikoliv s DNS, takze jsem celkem prekvapen protoze velke rozdily jsem v praxi nezaznamenal.
Diky.
Dobrý den,
benchmark DNS je specifický velkým počtem relativně malých paketů po UDP.
Velkou roli hraje určitě implementace síťového stacku v jádře a ovladače použité síťové karty. Zajímavé může být i že je poměrně velký rozdíl mezi síťovými kartami různých značek (což nakonec může být jen SW záležitost).
Zrovna zkouším kernel 3.0 a musím uznat, že Linux si poměrně polepšil v benchmarku oproti 2.6.38.
Marek Vavruša