Tag: benchmark

Opublikowane w

Testowanie szybkości kluczy Zabbix agenta

Było tak, że jeden z kluczy w Zabbiksie działał wolno. Nawet: bardzo wolno. Ile czasu może się wykonywać proste sprawdzenie wersji programu typu chef-client -v, nawet na umiarkowanie dobitym systemie? Zainteresowani znajdą odpowiedź na końcu wpisu[1], dość powiedzieć, że czasami załączał się timeout po stronie zabbix agent. Problem został rozwiązany w sposób najdoskonalszy, czyli poprzez zrzucanie wartości z crona do pliku, i czytanie jej z pliku, ale niesmak pozostał. Poza niesmakiem, pozostało pytanie które jeszcze klucze są nieoptymalne?

Ponieważ na ten moment Zabbix nie daje możliwości sprawdzenia statystyk czasu zapytań dla poszczególnych kluczy, wykonałem małą protezę w postaci skryptu w Perlu, który odpyta danego hosta o wszystkie klucze kilka(naście) razy i policzy dla nich statystyki. Wklejka poniżej.

 

Skrypt przyjmuje dokładnie jeden parametr – hosta na którym będzie przeprowadzać test. Poza tym, wymaga wszystkich kluczy dla danego hosta, które ma testować, w pliku określonym w zmiennej $file. Na końcu wyświetli łączny czas wykonania zdefiniowanej ilości zapytań dla każdego klucza wyrażony w sekundach oraz sam klucz. Czytaj: pewnie chcesz przepuścić wynik przez sort -n. 😉

Parę rzeczy, które wyszły w trakcie pisania tego skryptu lub których się nauczyłem (w sumie gdyby nie one, to nie powstałby ten wpis):

Pętla sprawdzające N razy wszystkie klucze po kolei jest dokładniejsza od pętli, która sprawdza kolejno wszystkie klucze N razy każdy. Chodzi o rozkład obciążanie na maszynie, w tym drugim przypadku jest większa szansa, że któryś klucz trafi w nietypowe obciążenie maszyny.

Dokumentacja do modułu Time::HiRes jest… taka sobie. Można to zrobić prościej, jak wyżej. Początkowo kombinowałem ze sprintf oraz clock_gettime(CLOCK_REALTIME);

Może zastanawiać, skąd mnożenie przez 1000000. Otóż chodzi o bug z zapisem liczb zmiennoprzecinkowych (kojarzyłem to raczej z ośmiobitowców i dzielenia, nie wiem czy słusznie…):

perl -e '$a=1415907504.646884; $b=1415907504.603042; $d=$a-$b; print $d,$/'

vs.

perl -e '$a=1415907504.646884*1000000; $b=1415907504.603042*1000000; $d=($a-$b)/1000000; print $d,$/'

Że tak zacytuję real programmers use integer. 😉

Na koniec niezła wiadomość: jest szansa, że w przyszłości Zabbix będzie miał coś w stylu MySQLowego slowloga, czyli nie będzie trzeba robić testów na poszczególnych hostach, tylko będzie wbudowane narzędzie do wykrywania wolnych zapytań. Można głosować na ten feature. 😉

Specjalne podziękowania za uwagi i wyjaśnienia dla Tona z #perl @ IRCnet (thanks Ton!).

I wracając do pytania o nieoptymalne klucze z początku wpisu – tylko nieszczęsny chef-client okazał się być czarną owcą. Pozostałe klucze, choć czasem wymagają uruchomienia Perla lub kilku poleceń w Bashu, wykonywały się w zdecydowanie przyzwoitym czasie, grubo poniżej sekundy.

[1] Wykonuje się nawet cbanq cvęganśpvr frxhaq (rot13)! Bo na tyle ustawiony był timeout…

Opublikowane w

Sortowanie – Bash vs Perl benchmark

Dziś na kanale IRC znajomy szukał błędu w skrypcie bashowym. Danych dużo, skrypt wykonuje się długo (kilkadziesiąt minut). Błąd pojawiał mu się w sort, skrypt złożony. Jakoś tak stwierdził, że przepisze na Perla, będzie szybciej. Tyle tytułem wstępu, bo potem rozpoczęliśmy akademickie rozważania pt. czy sortowanie w Perlu będzie szybsze.

Postanowiłem się pobawić w praktykę. Nie ukrywam, że sporą rolę maiła tu niedawna dyskusja nt. algorytmów (i czemu zabawy z nimi są fajne) z M.[0]

Najpierw wygenerowanie sporego zestawu danych testowych [1]. 10 mln liczb z zakresu 0-99, 28999760 bajtów.

Następnie prosty sort [2]. Wyniki oscylują w granicach 16-18 sekund.

Pierwszy skrypt w Perlu[3] Jest minimalnie szybciej, bo 15 sekund.

Widać parę niepotrzebnych przepisań i da się to skrócić [4]. Po skróceniu wyniki oscylują w granicach 14,4 sekundy.

Pora na mały cheat, bo wiemy, że większość danych się powtarza. Czyli wersja z hashem – zliczamy ilości wystąpień, a na koniec sortujemy tyko klucze hasha (których jest 100) i wyświetlamy tyle razy, ile razy wystąpiły [5].

Jest dużo szybciej. Okolice 4,7 sekundy. Szczerze mówiąc nie sądziłem, że aż tyle da się urwać.

Na koniec postanowiłem sprawdzić, czy różnica wynika z powtarzających się danych. Wygenerowałem mały plik z praktycznie niepowtarzającymi się danymi [6]

Tutaj sort wykonywał się ok. 70 ms, natomiast – ku mojemu zdziwieniu – Perl nadal był szybszy i wykonywał się ok. 50 ms.

Daleki jestem od wyciągania z tego benchmarku daleko idących wniosków, nikogo też na przechodzenie wszędzie na Perla nie namawiam. Bardziej chodziło mi o pokazanie ciekawostki. Zwykle 10 sekund różnicy nie ma znaczenia, narzut na pisanie nie zwróci się nigdy, a wersja z sort jest po prostu czytelniejsza. I pewnie nadal będę używał sort. Niemniej warto wiedzieć, że w prosty sposób da się szybciej. Taki mały hack.

Inna sprawa, że IMVHO pisanie skryptów w bashu zwykle nie ma sensu i lepiej użyć Perla, Pythona itp. Szybciej, więcej można w prosty sposób zrobić, a skrypty bashowe mają tendencję do puchnięcia z elementami dziwnych rzeźb.

Uwagi: Wynik sortowania jest identyczny, choć nie to było priorytetem. Sortowanie nie jest numeryczne (jak ktoś chce, może się bawić, stawiam, że wyniki będą podobne). Skrypty są pisane mało optymalnie, mało czytelnie itd. ale tak na szybko piszę onelinery z głowy, a nie bawiłem się w upiększanie, bardziej chciałem szybko notkę zrobić. Tak, wiem nie ma close (F), w skryptach, ale nie jest tu potrzebne. Nie ma potrzeby korzystania z open, spokojnie można było robić „tradycyjne” while (<>) i czytać ze STDIN; jak sprawdziłem później nie powoduje to zauważalnej różnicy w czasie wykonania.

Ponieważ Blox wyczynia cuda z tekstami w pre podczas edycji notki, efektem czego jest znikanie większej części skryptów i tekstu, poniżej wklejka z wszystkimi poleceniami (odnośniki powyżej).

 

[0] Jest szansa, że pojawi się parę zadań z algorytmami. Ale niczego nie obiecuję. Zresztą, chyba lepiej, żeby takie rzeczy działy się na blogu jakiegoś programisty… A jak zobaczyłem, co robi Blox z groźnymi nawiasami trójkątnymi, to zupełnie odeszła mnie ochota na pisanie czegoś wymagającego fragmentów kodu tutaj.

UPDATE: Jak trafnie zauważyli czytelnicy w komentarzach, sort można przyspieszyć (analogicznie, jak przyspieszyć można grep) poprzez ustawienie LC_ALL=C lub LANG=C. Po tym zabiegu sort, dla podanych danych, działa szybciej od dotychczasowego najszybszego Perla, w okolicach 4,2 sekundy.

Opublikowane w

OpenSSL AES benchmark

Mam dostęp do paru różnych maszyn, więc postanowiłem zrobić mini benchmark OpenSSL. Głównie z procesorami ARM. Wraz z kumplem z netu zebrało nam się na porównywanie wydajności różnych sprzętów. Poszło o nierewelacyjne osiągi OpenVPN na jego Banana Pi (nawiasem, do mnie też już Banan dotarł, wkrótce coś skrobnę).

Wszystkie testy na Linuksie (pochodne Debiana). Warunki niezupełnie „czyste”, bo maszyny normalnie działają (jakieś Xy, zwykłe usługi itp.), ale raczej dobrze oddaje możliwości – różnice między wynikami z netu pomijalne, maszyny raczej się nudzą. Testowane poleceniem openssl speed aes, w przypadku maszyn w których Linux widzi więcej niż jeden procesor, dodane –multi N, gdzie N  to ilość rozpoznawanych przez system rdzeni (z HT).

Na początek, w ramach punktu odniesienia, procesory Intela (testowane na architekturze amd64):

Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz (N=2)

aes-128 cbc     124896.83k   138273.46k   141166.08k   298696.36k   303164.07k
aes-192 cbc     105477.06k   116211.63k   117732.95k   246287.70k   249443.67k
aes-256 cbc      91720.90k    99602.26k   100765.95k   214892.54k   218794.67k

Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz (N=1)

aes-128 cbc      63276.43k    69732.33k    71320.92k   149509.14k   152286.27k
aes-192 cbc      53920.87k    58297.88k    59832.94k   126354.09k   128532.21k
aes-256 cbc      46232.08k    49934.93k    50964.99k   109278.55k   110320.76k

Intel(R) Atom(TM) CPU D525 @ 1.80GHz (N=4)

aes-128 cbc      30904.81k    46265.24k    53263.58k    55370.66k    55836.67k
aes-192 cbc      28137.17k    40040.66k    45127.08k    46556.50k    47162.91k
aes-256 cbc      29979.57k    36609.58k    39015.17k    39410.69k    39343.52k

Intel(R) Atom(TM) CPU N2800  @ 1.86GHz (N=4)

aes-128 cbc      63529.34k    67116.33k    67479.30k    69077.33k    70063.45k
aes-192 cbc      53305.24k    55930.01k    56726.87k    58294.95k    58384.38k
aes-256 cbc      46324.97k    48419.43k    49031.42k    49620.99k    49569.79k

Intel(R) Atom(TM) CPU N2800  @ 1.86GHz (N=1)

aes-128 cbc      25546.13k    28152.09k    29100.80k    29257.82k    29417.47k
aes-192 cbc      21745.97k    23033.45k    24188.43k    24440.15k    24491.35k
aes-256 cbc      18760.60k    20222.36k    20786.01k    20862.38k    20971.52k

Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz (N=2)

aes-128 cbc     139806.09k   153189.03k   157513.39k   329881.60k   336000.34k
aes-192 cbc     118517.33k   128203.82k   131191.81k   279747.24k   283568.81k
aes-256 cbc     102364.69k   110147.39k   111865.51k   240238.25k   242586.97k

Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz (N=1)

aes-128 cbc      69509.47k    76975.27k    79176.79k   166760.11k   168293.72k
aes-192 cbc      59564.63k    64345.22k    65814.19k   140067.50k   141836.29k
aes-256 cbc      51423.55k    55281.11k    56354.30k   120643.58k   121760.43k

Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (N=4)

aes-128 cbc     152665.50k   160758.55k   162619.56k   162693.12k   160432.13k
aes-192 cbc     128774.61k   134266.73k   136237.23k   136946.01k   136850.09k
aes-256 cbc     111035.63k   113086.31k   115218.09k   115126.95k   115452.59k

Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (N=1)

aes-128 cbc      64605.45k    79469.89k    80944.90k    81767.94k    81679.70k
aes-192 cbc      62476.10k    66903.19k    67975.42k    68745.33k    68009.98k
aes-256 cbc      54233.60k    56778.67k    57951.06k    58175.49k    58541.29k

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (N=4)

aes-128 cbc     178233.37k   197070.14k   202821.72k   204553.22k   203276.29k
aes-192 cbc     155289.71k   164140.12k   164286.98k   167794.69k   170915.16k
aes-256 cbc     134427.71k   141611.71k   145087.32k   145325.74k   144921.94k

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (N=1)

aes-128 cbc      93122.37k   101039.38k   104341.59k   105117.70k   104237.74k
aes-192 cbc      79544.40k    85362.03k    86720.00k    87005.87k    87758.17k
aes-256 cbc      69556.44k    73458.50k    74518.87k    74227.71k    73815.38k

AMD Sempron(tm) 2300+ (N=1) Test oczywiście dla architekury i386

aes-128 cbc      29157.09k    31077.91k    31887.50k    76258.89k    76728.08k
aes-192 cbc      25055.40k    26304.51k    26871.69k    65190.10k    65563.40k
aes-256 cbc      21279.27k    22447.52k    22859.69k    56840.22k    57122.08k

Tyle jeśli chodzi o procesory Intela, pora na benchmark openssl dla procesorów ARM:

Dockstar. Debian, architektura armel Feroceon 88FR131 rev 1 (v5l) 1,2GHz

aes-128 cbc      14013.23k    16435.69k    16982.28k    17336.92k    17317.89k
aes-192 cbc      12337.22k    14112.71k    15303.21k    14970.88k    14815.53k
aes-256 cbc      10989.90k    12474.70k    12831.67k    13312.00k    13218.91k

Raspberry Pi. Raspbian ARMv6-compatible processor rev 7 (v6l) 700 MHz

 aes-128 cbc      13241.53k    14935.94k    15386.52k    15716.75k    15576.54k
 aes-192 cbc      11420.51k    13032.96k    13501.64k    13664.95k    13465.79k
 aes-256 cbc      10378.09k    11521.94k    11991.62k    11855.19k    11988.44k

Banana Pi (N=2).

aes-128 cbc      38453.65k    45557.42k    47889.49k    48539.99k    48715.09k
aes-192 cbc      33638.03k    38975.96k    41001.13k    41532.42k    41694.55k
aes-256 cbc      30360.07k    34568.62k    36124.25k    36553.39k    36672.85k

Banana Pi (N=2) Debian armhf

aes-128 cbc      35393.00k    47858.58k    50317.74k    50995.88k    51183.62k
aes-192 cbc      35339.90k    40943.62k    43078.57k    43647.32k    43797.16k
aes-256 cbc      31896.82k    36317.72k    37956.01k    38405.80k    38532.44k

Feroceon 88F6282 rev 1 (v5l) 2,0 GHz

aes-128 cbc     20192.02k     24452.77k    25681.19k    25715.66k    26231.83k 
aes-192 cbc     18020.95k     21192.76k    22311.17k    22520.40k    22832.65k 
aes-256 cbc     16372.28k     18963.20k    19705.60k    19748.15k    20109.48k

Cubieboard 3 (N=1)

aes-128 cbc 18192.97k 21387.56k 22688.77k 22623.23k 20960.60k 
aes-192 cbc 17613.03k 18595.58k 19475.20k 19543.38k 19595.26k 
aes-256 cbc 15075.22k 16513.19k 17151.57k 17167.36k 17246.89k

Cubieboard 3 (N=2)

aes-128 cbc 40631.59k 43845.70k 44627.97k 45086.38k 45211.65k 
aes-192 cbc 35388.95k 36886.19k 38698.50k 38691.16k 39335.25k 
aes-256 cbc 30851.77k 33802.65k 34321.41k 34171.56k 33778.35k

ODROID U3 (N=1)

aes-128 cbc 54399.00k 58485.80k 59575.38k 60536.83k 60385.96k 
aes-192 cbc 47215.06k 50994.73k 52349.35k 52738.73k 52731.90k 
aes-256 cbc 41830.65k 44747.37k 45808.98k 46029.82k 45796.01k

ODROID U3 (N=4)

aes-128 cbc 216401.55k 233187.14k 237574.06k 237451.26k 239610.54k 
aes-192 cbc 187925.35k 203781.87k 209056.51k 202832.55k 210911.23k 
aes-256 cbc 166399.47k 178351.36k 182334.38k 183437.99k 183795.71k

Jetson TK 1 (N=1)

aes-128 cbc 101615.96k 105911.73k 109555.46k 110431.91k 110553.77k 
aes-192 cbc 87593.79k 92699.41k 95376.04k 96003.75k 96133.12k 
aes-256 cbc 76532.53k 80948.01k 83111.77k 83704.15k 83817.81k

Jetson TK 1 (N=4)

aes-128 cbc 400560.99k 417232.81k 426956.88k 411591.68k 423813.12k 
aes-192 cbc 327749.78k 351935.28k 364130.73k 377968.98k 379052.03k 
aes-256 cbc 300564.41k 319599.06k 325819.65k 328858.28k 330391.55k

Marvell Armada 370/XP (Device Tree) (N=1)

aes-128 cbc      41961.95k    50546.82k    53594.28k    54535.26k    53449.35k
aes-192 cbc      37750.78k    44366.68k    46631.68k    47299.58k    46623.40k
aes-256 cbc      33172.31k    37925.33k    40553.30k    41431.04k    40962.73k

Marvell Armada 370/XP (Device Tree) (N=4)

aes-128 cbc     166412.45k   201555.37k   213535.57k   217358.68k   213336.06k
aes-192 cbc     149429.29k   177001.39k   186009.77k   189066.24k   186086.74k
aes-256 cbc     131774.20k   151056.06k   161813.59k   165605.38k   163482.28k

Raspberry Pi 3 (N=1; 32 bit OS)

aes-128 cbc      41017.91k    48669.00k    51254.02k    51984.38k    52215.81kaes-192 cbc      35728.01k    41270.60k    43058.26k    43608.06k    43783.51kaes-256 cbc      32115.97k    36434.37k    38004.48k    38426.71k    38482.83k

Jak widać, trochę przepaść między ARM a Intelami w wynikach całkowitych. Dodatkowo sprawę wydajności pogarsza fakt, że OpenVPN nie wątkuje (podobno ma być dodane w wersji 3), czyli klient wykorzystuje tylko jeden rdzeń, co w przypadku Banana Pi oznacza w praktyce połowę podanej wyżej wydajności.

PS. Wpis będzie edytowany/uzupełniany.

UPDATE: dodaję wyniki dla Banana Pi uzyskane osobiście na czystym Debianie w normalnej architekturze armfh. Nie jestem pewien, czy wcześniejsze nie były na „niepełnym” armfh dla Raspbiana robione…