Benchmark DNS cache – problemy.

Jakiś czas temu zainteresowałem się, głównie za sprawą prezentacji Infoblox na 9 PLNOG nt. DNS, tematem DNS cache i jego wydajności. Nie jest to zupełnie nowa sprawa, bo kiedyś otarłem się o problem wydajności DNS cache (albo raczej sprzętu, na którym działało to jako jedna z wielu usług…). Skończyło się tak, że mały i lekki dnsmasq jest za mały dla większej osiedlówki, choć nadal fajny w rozwiązaniach domowych.

Pierwsze skojarzenie z DNS to oczywiście bind, którego „wszyscy znają, wszyscy używają i nadaje się do wszystkiego”. Autorzy unbound przekonują, że to niekoniecznie dobre podejście, więc – zachęcony tym, co znalazłem w sieci – postanowiłem przetestować wydajność bind vs. unbound.

Nie ma lekko. W Debianie nie znajdziemy gotowego pakietu z narzędziem do testowania wydajności serwera DNS. W ogóle nie ma (nie znalazłem) wydajnego narzędzia do tego. Jest queryperf, dostępny w źródłach bind (do samodzielnej kompilacji), ale do wydajności mu daleko – często obciąża maszynę porównywalnie, jeśli nie bardziej, niż sam testowany program. W prezentacji (http://www.infoblox.nl/content/dam/infoblox/documents/solution-notes/infoblox-note-ib-2000-performance-test.pdf – dead link) znalazłem skrypt:

#!/b in/sh
SECS=5
INPUT=qp.forward.master.cached
SERVER=10.34.31.2
# SECS is number of seconds to run test
# INPUT is input file
# SERVER is server IP
queryperf -s $SERVER -d $INPUT -l $SECS > out1 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out2 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out3 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out4 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out5 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out6 2>&1 &
wait
grep ‘Queries per’ out? | awk ‘BEGIN { sum=0;}{ sum += $5;}
END {printf(“Total: %.1f qps\n”, sum);}’


Szybkie zapytanie na kanale IRC i… jedna osoba zgłasza, że przesiadła się na unbound i jest zadowolona; sugestii co do oprogramowania testującego brak, za to pojawia się koncert życzeń: jak już to jeszcze przetestować pnds_recursor, djbdns… i może bind10, bo podobno poprawiona wydajność. Robi się tego sporo, bo i lab z paroma maszynami wysyłającymi zapytania by się przydał, i testowanych demonów większa ilość. A miało być szybkie i proste zagadnienie na 1-2h.

Do tego problem danych testowych – każdy ma u siebie nieco inną charakterystykę ruchu, wyniki mogą się różnić dość znacznie, więc skąd wziąć dane? Jasne, można benchmarkować na podstawie własnych, rzeczywistych danych i będzie to najbliższe optymalizacji w danym przypadku, ale czy wartościowe dla innych? No i na pewno nie opublikuję takiego testowego zestawu danych. Jest też problem dostosowania konfiguracji do konkretnej platformy, na której uruchamiane będzie oprogramowanie (np. ilość wątków). Domyślny konfig jest różny dla różnych demonów, przy czym domyślny debianowy dla unbound ma się nijak do maszyny wieloprocesorowej. No i przydał by się tuning samego systemu pod kątem wydajności sieci, bo default w Linuksie jest raczej słaby.

Więcej pytań, niż odpowiedzi. Stanęło na tym, że pełnego testu nie zrobiłem. Za to puściłem szybki test na jakimś małym zestawie danych (kilkanaście wpisów). W ww. skrypcie zmieniłem liczbę procesów na 4, czas na 60 sekund i testowałem na laptopie (Intel Core i5). Nie do końca optymalnie, ale cóż, lepiej, niż pojedynczy proces. Poprzestałem więc na tym pseudobenchmarku na domyślnym konfigu – zabawa w optymalizację to grubsza sprawa, jeśli ma być zrobiona porządnie. Unbound wypadł bardzo dobrze. Mimo, że działał tylko na pojedynczym rdzeniu, wypadł dwukrotnie lepiej, niż bind.

Nie ukrywam, że chętnie poznam sugestie dot. danych testowych (takich, które można opublikować) i ew. doświadczeń z benchmarkowaniem DNS (cache). Jeśli się zbiorę i zrobię benchmark, to dane i wyniki będą opublikowane. Na razie stanęło na tym, że na moich dekstopach zmieniłem bind na unbound (tak, mam lokalne cache na desktopach od jakiegoś czasu, raczej eksperyment, kiedyś napiszę na ten temat).

Benchmark jądra BSD i Linux.

Dawno temu pisałem o porównaniu Linuksa i FreeBSD i FUDzie/mitologizacji zwolenników *BSD przy okazji benchmarku tych systemów, który to wątek wyższości *BSD ciągnie się odkąd pamiętam. Wtedy badano wersje 32 bitowe, a teraz, z okazji zamrożenia Debiana Wheezy pojawiła się nowa wersja benchmarku, dla systemów 64 bitowych. Nie ma zaskoczenia – Debian z jądrem Linuksa jest zawsze szybszy od wersji kFreeBSD. Często różnice są znaczące i wersja z jądrem Linuksa jest szybsza o 20-30%. Pomijam zupełnie ekstremalne przypadki, gdzie różnica jest o wiele większa.

Także w typowo serwerowych zastosowaniach widać różnicę na korzyść Linuksa – serwowanie statycznego contentu przy pomocy Apache to 10% różnicy. PC-BSD, które było poddane paru testom pokazuje, że słaby wynik Debian/kFreeBSD to nie przypadek. Z argumentów za korzystaniem z *BSD pozostał już chyba tylko ZFS. Moja motywacja do instalacji Debiana/kFreeBSD jest coraz mniejsza.

Źródło: Benchmark Debiana z jądrem Linux i kFreeBSD by Phoronix.

Linux a FreeBSD czyli FUD w wydaniu FreeBSD.

Przy okazji niedawnej informacji o benchmarku Debiana z kernelem Linux i Debiana z kernelem FreeBSD wywiązała się dyskusja nt. mitycznej większej szybkości FreeBSD vs. Linux. Jako przykład nierzetelnej informacji nt. porównania Linuksa i FreeBSD pojawił się przykład tej stronki. Faktycznie, niekompetencja tego porównania jest ogromna, stąd wpis.

Zdaję sobie sprawę, że stronka jest przestarzała, ale… jest (cała dokumentacja do FreeBSD jest równie aktualna?). A część błędów w porównaniach była aktualna zawsze. Zarzuty (tylko tam, gdzie IMO Linux zyskał niezasłużenie niższą ocenę niż FreeBSD):

  1. Performance – porównanie starego kernela – linia 2.4. Do tego odnośnik do benchmarku na który się powołują nie działa.
  2. Security – ujemny punkt dla Linuksa to stanowczo za dużo. Chyba, że porównuje się typowo desktopowe dystrybucje, ale tu z kolei przydałby się punkt szybkość rozwoju systemu, gdzie FreeBSD zostaje daleko w tyle. Pewnie dlatego punkt pominięty.
  3. Filesystem – ext2 to przeżytek, chyba żadna dystrybucja nie korzysta z tego domyślnie. Porównywać trzeba by ZFS i ext4. No to proszę, świeże porównanie szybkości ZFS, ext4, brtfs. Oczywiście sama szybkość filesystemu to nie wszystko.
  4. Device Drivers – stawianie FreeBSD wyżej pod względem driverów (w tym zamkniętych binarnych) to jakiś żart. Spora część sprzętu po prostu nie ma żadnego drivera dedykowanego dla FreeBSD. Faktem jest, że pod Linuksem sterowniki binarne wymagają czasem konkretnej wersji kernela (patrz fglrx) ale nie jest to – i z tego co pamiętam nigdy nie było – tak dramatyczne, jak opisują.
  5. Development environment – zarzucanie, że skompilowana aplikacja z Red Hat nie działa na Slackware to totalne nieporozumienie. Z jednej strony jest porównywany jest jeden system (AKA dystrybucja *BSD), z drugiej różne dystrybucje. Poza tym, znakomita część oprogramowania działa po przeniesieniu binarek (patrz Debian i Ubuntu, patrz alien).

Zastanawiam się, jak obecnie wygląda propaganda FreeBSD? Nadal jest równie „rzetelna”? Jeśli chodzi o binarne sterowniki, to przykład „dobrego wsparcia sprzętu” i „stabilnych sterowników binarnych” opisywałem w tym wpisie o Opensolaris, FreeBSD i Linuksie.