Allegro Tech Talks Poznań #4 – wrażenia

W projekcie abcc panuje chwilowy zastój, spowodowany czynnikami różnymi – od osobistych (bardziej, znacznie bardziej), przez zawodowe (mniej, znacznie mniej), ale faktem jest, że spocząłem na laurach nieco i nic się od ostatniego wpisu nie zmieniło w temacie. Plan jest taki, żeby uruchomić sobie stację testową opartą o Raspbbery Pi, która będzie działać na dwóch lub trzech łączach (kabel, modem GSM i być może, jeśli RPi wyrobi prądowo, karta WiFi) i zrzucać pomiary, w celu lepszego dobrania parametrów. Ale to plany…

Tymczasem w ramach pożeraczy czasu byłem w zeszłym tygodniu na spotkaniu Allegro Tech Talks Poznań #4. Staram się bywać, jeśli akurat mam czas. Jeśli dobrze zrozumiałem, po raz pierwszy można było wysłuchać przez net na żywo, ale jakoś nie przepadam za taką formą – lepiej mi się obiera na żywo, nie mam nawyku słuchania przez net. No i zawsze można spotkać znajomych i poplotkować.

Prezentacje były dwie, obie dotyczyły Apache Solr, więc zupełnie nie moja działka, i przyznaję, że wahłem się, czy w ogóle iść, ale obie były IMO bardzo dobrze i interesująco poprowadzone, więc części merytorycznej też nie żałuję.

Pierwsza prezentacja dotyczyła uruchamiania Solra w kontenerach dockerowych, poczynając od tego jak to skonfigurować i uruchomić, przez przedstawienie wyników benchmarków pomiędzy sprzętem fizycznym (bare metal), przez pełną wirtualizację, po kontenery. Różnice były duże, przedstawione dane przekonują do kontenerów, ale… Zawsze jest jakieś ale, w tym przypadku testy były robione na ustawieniach domyślnych. Z jednej strony rozumiem, bo jakiś wspólny mianownik trzeba mieć, z drugiej produkcję konfiguruje się pod konkretny przypadek. Niemniej, różnice były na tyle istotne, że konfiguracja raczej nie będzie w stanie ich zniwelować. W sumie można było traktować tę prezentację mniej jako o Solr, bardziej jako o dockerze.

Druga prezentacja dotyczyła optymalizacji Solra w Allegro. Jak pisałem, nie moja działka, więc momentami była to trochę chińszczyzna (na zasadzie: nie wiem co to dokładnie jest), ale opowiedziane przystępnie, ciekawie i z przykładami. Mocno nieoczywiste przypadki i wyniki, efekty dobre. Stawiam, że dla osób zajmujących się Solrem perełka. Jest dostępna w wersji online.

Spotkałem też starych znajomych i poplotkowaliśmy, więc ogólnie bardzo udane wydarzenie – 10/10.

Pierwsze pomiary

Wygląda, że w końcu mogę napisać, że powstało coś działającego. Nie jest to oczywiście pełna funkcjonalność, ale same pomiary są skończone. Nie twierdzę, że to ostateczna wersja, w szczególności muszę się przyjrzeć logowaniu, ale to jest ten moment, kiedy mogę pobawić się wartościami z konfiguracji i zobaczyć, jak wpływają na działanie w realnych warunkach.

Jak to wygląda? Otóż tak na szybko, uruchamiając modem GSM w sieci Virgin Mobile (3G) zarejestrowany do T-Mobile (roaming):

INFO:__main__:Route default got score 24.1516556059 on interface wlan0
INFO:__main__:Route default got score 89.6018913814 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7111227853 on interface wlan0
INFO:__main__:Route default got score 64.5852940423 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.101962362 on interface wlan0
INFO:__main__:Route default got score 63.8392652784 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.9711829594 on interface wlan0
INFO:__main__:Route default got score 78.0421457793 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 66.7648989057 on interface wlan0
INFO:__main__:Route default got score 62.6970052719 on interface enx582c80xxxxxx

Widać, że w ostatnim pomiarze domowe WiFi (lub operator, ale stawiam na WiFi) dało się we znaki i wypadło gorzej, niż modem GSM. Różnica jest jednak minimalna i do zmiany routingu by nie doszło, nawet na domyślnych wartościach.

Wyniki po zalogowaniu natywnie, czyli do Play:

INFO:__main__:Route default got score 23.7996305738 on interface wlan0
INFO:__main__:Route default got score 307.032244546 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.561555045 on interface wlan0
INFO:__main__:Route default got score 267.205837795 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.0223884583 on interface wlan0
INFO:__main__:Route default got score 268.849682808 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7405095782 on interface wlan0
INFO:__main__:Route default got score 275.927570888 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 38.6582265223 on interface wlan0
INFO:__main__:Route default got score 287.999381338 on interface enx582c80xxxxxx

Wszystkie wyniki dla przykładowego pliku konfiguracyjnego z repo, z dostosowaną nazwą interfejsu (jest interfejs modemu zamiast eth0) i zmienionym poziomem logowania na INFO. Wywołanie w pętli 5 razy:

for i in {1..5}; do python abcc.py --config local_test.yaml; done

Przyznaję, że jestem zaskoczony wynikami – wydawać by się mogło, że natywnie będzie działać lepiej, a tu niespodzianka. Muszę jeszcze dokładniej potestować na różnych urządzeniach, dotychczas miałem wrażenie, że w roamingu jest gorzej. Ale to już temat na inny, niezwiązany z DSP2017, wpis.

Przy okazji, to drugie wywołanie wykonuje się 71 sekund, czyli około 14 sekund na jeden pełen przebieg, a ilość przesłanych podczas badania danych (odczyt z ifconfig) to:

RX packets 11342  bytes 7440400 (7.0 MiB)
TX packets 9789  bytes 1133957 (1.0 MiB)
RX packets 11640  bytes 7475184 (7.1 MiB)
TX packets 10087  bytes 1169257 (1.1 MiB)

Czyli jakieś 7kB RX i 7 kB TX per pomiar. Czyli jakieś 10 MB/dobę, przy założeniu, że będzie wywoływane co minutę, 27/7. Czyli mniej więcej mieści się w limicie bezpłatnego pakietu Freemium w Virgin Mobile. 🙂

Skrypty pomocnicze

Wspominałem, że pewna część działania skryptu odbędzie się w zewnętrznych skryptach. Powiedzmy, że pluginach, choć to myląca nazwa. I że będą w Bashu.

Zrobiłem listę skryptów pomocniczych, których planuję używać:

  • ustawianie routingu do danego IP przez dany interfejs (bardziej gateway)
  • usunięcie routingu do danego IP przez dany interfejs (gateway)
  • ustawienie (domyślnego) routingu przez dany interfejs i gateway
  • zdjęcie (domyślnego) routingu przez dany interfejs i gateway

Jeśli chodzi o postępy, to pojawiło się wsparcie dla interfejsów, zarówno po stronie skryptu, jak i konfiguracji. Tak naprawdę pojawiła się cała sekcja interfaces, dla każdego interfejsu są określone nazwy tras, których parametry są zdefiniowane w sekcji routes. Taka konstrukcja, bo przecież nie każdy interfejs musi umożliwiać routing do każdej sieci, a nie chcę wymuszać cokolwiek długiej definicji trasy dla każdego interfejsu. Poza tym, łatwo byłoby w takim przypadku o błąd typu inne wagi czy IP.

Żeby można było mierzyć jakoś łącza do danej sieci (route) przez dany interfejs brakuje tak naprawdę pierwszych dwóch skryptów i ich wywołania – stosowne funkcje istnieją, ale są puste. Pewnie jutro/pojutrze. Mam nadzieję, że od razu pokażę pierwsze realne efekty działania, czyli wyniki pierwszych pomiarów. Stay tuned!