Opublikowane .

Krótki wpis dla celów historycznych i ku pomocy tym, którzy informacji będą szukać w naszym ojczystym języku. Wyzwanie, to wysłanie SMS za pomocą smartfona wyposażonego w system Android (>2.7, bo na starszych nie testowałem) SMS przy użyciu skryptu/komend BASH. Oczywiście BASH działa na systemie do którego podłączony jest smartfon (np. kablem USB). Mój test przeprowadzany był na smartfonie (emerytowanym) ZTE Blade z CyanogenMod 7 na pokładzie. Do wykonania operacji wykorzystuję narzędzie ADB, a na komputerze z którego lecą komendy jest system Linux Mint 17.3 Rosa (czyli Ubuntu 14.04 LTS).

  1. Upewniamy się, czy nasz system umie „gadać” przez ADB do smartfona

    Jeżeli w odpowiedzi dostaniemy:

    To znaczy, że brakuje nam co nieco w udev, a konkretnie udev rules dla Androida. Tak więc tworzymy plik /etc/udev/rules.d/51-android.rules, a w nim:

    ZTE to zaledwie ostatnia linijka. Pozostałe to inni producenci urządzeń z Androidem na pokładzie. Posiadać nie zaszkodzi, więc dodać można.

    Następnie zmieniamy shmod:

    I restartujemy udev:

    Dla pewności ubijamy proces ADB:

    Teraz ADB powinien nam zwrócić po komendzie adb devices identyfikator naszego urządzenia:

  2. Wysyłamy SMS

Warto patrzeć co dzieje się na ekranie. Pierwsza komenda wywołuje główny ekran. Następnie uruchamiamy aplikację obsługującą SMS, ustawiamy numer odbiorcy i treść. Keyevent 22 sprawia, że focus znajduje się na przycisku wyślij. Keyevent 66 zatwierdza akcję i wysyła.

azday

Opublikowane .

9 marca społeczność profesjonalistów, architektów, programistów i pasjonatów rozwiązań Microsoft Azure, zgromadzona w grupie Microsoft Azure User Group Poland – której mam przyjemność być członkiem i liderem – wraz z Partnerami organizuje całodniowe wydarzenie poświęcone platformie Microsoft Azure.

Konferencja toczyć się będzie w dwóch głównych ścieżkach IT Pro oraz Dev. W tym wyjątkowym wydarzeniu w siedzibie Microsoft Polska w Warszawie uczestniczyć będzie mogło jedynie 50 programistów i 100 przedstawicieli specjalistów z dziedziny IT Pro.
Na konferencję zapraszamy, administratorów, programistów, konsultantów, architektów, przedstawicieli kadry odpowiedzialnej za rozwój IT w przedsiębiorstwie oraz tych wszystkich, którzy chcą zaznajomić się z chmurą Microsoft. Tematyka konferencji obejmować będzie swym zakresem technologie Microsoft ale również Open Source. Usłyszeć będzie można o rozwiązaniach hybrydowych, bezpieczeństwie, procesach migracji do chmury a także środowiskach testowych czy Machine Learning.

Moja rola w tym przedsięwzięciu to nie tylko współorganizacja. Będę miał okazję przedstawić prelekcję w ścieżce Dev i oczywiście będzie ona dotyczyła Open Source na platformie Microsoft Azure.

Więcej informacji, agendę i odnośnik do rejestracji można znaleźć pod adresem http://azureug.org/azureday

Opublikowane .

Czy idzie nowa fala wzrostu wydajności WordPress przy okazji pojawienia się PHP w wersji 7? Czy szokujące wyniki testów wydajności PHP 7 mają przełożenie na ten popularny CMS? Jak to wszystko ma się do zmian w MySQL (i tym samym MariaDB)? Słyszy się często głosy, że MySQL 5.6 i 5.7 dystansuje MySQL 5.5 pod względem wydajności. Co na to WordPress – najpopularniejszy CMS w sieci? Kilka słów i benchmarków na ten temat poniżej 😉

Od strony programistycznej wiem o PHP nieco więcej niż o node.js, czyli niewiele – nie piszę NIC w tym języku i chyba nigdy nie popełniłem w nim nic innego niż phpinfo();. Od strony administrowania serwerami i aplikacjami jest to jednak dla mnie… 80-90% czasu. Sam WordPress to lwia część aplikacji PHP, które mam „pod swoimi skrzydełkami”, a optymalizacja serwerów pod WordPress to rzecz którą nie tylko robię, ale także rzecz, którą robić lubię.
Tak więc PHP niedawno osiągnęło wersję 7 i klienci zaczynają o to pytać – głównie w świetle testów wydajnościowych (a właściwie w świetle ich wyników) – otóż gdzie nie spojrzeć, to PHP 7 zostawia w tyle PHP 5.6 – różnice sięgają 100% (przykład: tutaj). Od strony programistycznej nie dotrzymam więc polskiej tradycji „nie znam się, to się wypowiem”, ale od strony administracyjnej mogę „machnąć” kilka szybkich testów (teoretycznie dla Was drodzy czytelnicy, ale praktycznie dla moich kochanych klientów, którzy o to pytają) 😉

Nikogo chyba nie zaskoczy fakt, że testy przeprowadzam na platformie, na której pracuję, czyli Microsoft Azure + Ubuntu (aktualnie 14.04 LTS). Mógłbym na Debianie 8, bo od niedawna jest do wyboru z listy systemów na Azure, ale… cóż, pracuję na Ubuntu i bardzo mi z tym wygodnie. Bazą do testów jest instancja D1v2 uruchomiona w Dublinie (North Europe). Dv2 mają bardziej wydajne procesory (średnio o 35% szybsze niż seria D), oraz takie same konfiguracje pamięci i dysków co w przypadku serii D. Dv2 są oparte na procesorach Intel Xeon E5-2673 v3 (Haswell) z zegarem 2,4 GHz i technologią Intel Turbo Boost 2.0, dzięki której mogą osiągnąć częstotliwość 3,2 GHz. Dv2, podobnie jak D, mają lokalne moduły SSD, ale z nich korzystać nie będę (jest to pamięć niepersystentna). Maszyny testowe (D1v2) mają 1CPU i 3.5GB RAM oraz dwa dyski danych spięte w RAID0 – na macierzy znajdzie się baza danych. Pliki CMS umieszczone są na dysku systemowym. Na serwerze zainstalowany jest aktualny OS Ubuntu 14.04 LTS (żadnych optymalizacji).
Każda z trzech maszyn ma inną konfigurację platformy dla WordPress. Różnice są wyłącznie w PHP i bazie danych MariaDB. Trzy wersje PHP (5.5, 5.6 i 7.0) pochodzą z repozytorium Ondřeja Surý (link). Trzy wersje MariaDB pochodzą z oficjalnych repozytoriów (link).
Z PHP 5.5 uruchomiona została baza danych MariaDB 5.5 – stabilna wersja MariaDBm która jest połączeniem kodu MariaDB 5.3 i MySQL 5.5. Z PHP 5.6 uruchomiona została baza danych MariaDB 10 – czyli MariaDB 5.5 z backportwanymi „ficzerami” z MySQL 5.6 oraz nowymi funkcjonalnościami niedostępnymi nigdzie indziej. Ostatnia konfiguracja, PHP 7.0, zostałą uruchomiona z bazą danych MariaDB 10.1 – silnikiem zbudowanym na bazie MariaDB 10 z „ficzerami” z MySQL 5.6 oraz 5.7, a także zupełnie nowymi funkcjonalnościami, które nie są dostępne nigdzie indziej.
Wszystkie trzy konfiguracje wyposażone są w webserver NGINX w wersji 1.8.0. PHP-FPM dla każdej z konfiguracji jest odpowiedni względem wersji PHP.

Nie przeprowadzałem testów mieszanych – różne PHP z różnymi MariaDB – ze względu na fakt, że chciałem dopasować te elementy według generacji. Przykładowo PHP 7 + MariaDB 10.1 powinno być demonem wydajności w porównaniu do PHP 5.6 + MariaDB 10 i PHP 5.5 + MariaDB 5.5 – wynika to z faktu, że oddzielnie PHP 7 i MySQL 5.6/5.7 odnotowują radykalne zwiększenie wydajności względem swoich poprzedników. Oczywiście całość ma element wspólny: WordPress 4.4. Jedyne zainstalowane wtyczki to Akismet (out of the box) i PHP/MySQL CPU performance statistics, czyli benchamrk którego użyję do jednego z testów. Żadnego cache (po stronie WP, ani po stronie serwera).

Benchmarki

  1. PHP/MySQL CPU performance statistics (link) – benchmark w formie wtyczki do WP. Nie będę się rozpisywał nad poszczególnymi testami (ich opisami), bo w wynikach widać co było zrobione, a po szczegóły (jeśli ktoś chce), można sięgnąć do źródeł wtyczki. Najważniejszą informacją jest to, że do testów bazy danych używa ona WPDB, czyli bazodanowej warstwy abstrakcji WordPress – dzięki temu możemy przypisać wyniki do CMS WordPress i wymiernie je porównywać.
  2. Benchmark-PHP (link) –  prosty benchmark PHP/MySQL, który bezpośrednio odpytuje bazę danych. Dzięki niemu zobaczymy, czy fakt wykorzystania WPDB wpłynął w jakimś stopniu na wyniki testów.
  3. Locust.io – testy obciążeniowe (link). 100 użytkowników odpytujących stronę główną naszego WordPress’a.

Wyniki

PHP 7 + MariaDB 10.1

PHP/MySQL CPU performance statistics

Zaznaczenie_042

Benchmark-PHP

Zaznaczenie_050

Jak widać, pod względem wartości wyniki obu testów są zupełnie różne – i takie też było założenie. Testy te nie mają wspólnych elementów kodu i mają być jedynie względne pomiędzy testami różnych konfiguracji.

PHP 5.6 + MariaDB 10

PHP/MySQL CPU performance statistics

Zaznaczenie_043

Benchmark-PHP

Zaznaczenie_051

Różnice w wydajności samego PHP (w obu testach), są olbrzymie. Różnice w wydajności w testach bazodanowych są względnie niewielkie (2req/s) i około 5s w całokształcie czasu wykonania testu. Przy tej skali są to niewielkie różnice, ale trzeba brać pod uwagę, że przy ruchu na poziomie kilkuset req/s i innej architekturze różnice te mogą być dużo bardziej znaczące. Mamy zatem pierwsze, wymierne wyniki porównania.

PHP 5.5 + MariaDB 5.5

PHP/MySQL CPU performance statistics

Zaznaczenie_044

Benchmark-PHP

Zaznaczenie_052

Wyniki jakże zaskakujące! PHP 5.5 + MariaDB 5.5 w kwestii wydajności w testach bazodanowych deklasuje poprzednie konfiguracje. Pod względem wydajności samego PHP wersja 7 góruje nad pozostałymi, ale wydajność operacji związanych z bazą danych najlepiej wypada w „stabilnej” konfiguracji. Czy to znaczy, że pomimo nowych wymagań WordPress, które zrobiły niedawno niemało szumu, mamy do czynienia z degradacją wydajności? Wygląda na to, że tak. Sugerowana konfiguracja dla WordPress to od niedawna:

To run WordPress we recommend your host supports:
PHP version 5.6 or greater
MySQL version 5.6 or greater

Z powyższych testów wyraźnie wynika, że PHP 5.5 + MariaDB (MySQL) 5.5 to lepszy wybór – oczywiście tyczy się to warstwy administracyjnej, a nie programistycznej – oby nie był to w pewnym momencie znaczący konflikt…

Jak jednak wygląda to produkcyjnie? Testy testami, ale wydajność na wyjściu ma największe znaczenie – jednym słowem czas ładowania.

Testy obciążeniowe PHP 7 + MariaDB 10.1

locust70

Skupiamy się na czasie ładowania samej strony, czyli odpowiedź serwera + czas wykonania skryptów + czas odpowiedzi bazy danych. Nie oceniamy tu czasu pobierania arkuszy stylów, bibliotek JS itd.

Mediana wyników wyniosła 34ms, a maksymalny odnotowany czas odpowiedzi to 284ms. Wszystko przy średnim naporze ruchu na poziomie 13.7 req/s.

Testy obciążeniowe PHP 5.6 + MariaDB 10

locust56

Przy średnim naporze ruchu na poziomie 14.2 req/s mediana czasów odpowiedzi wyniosła 63ms, a maksymalna wartość tego czasu 332ms.

Testy obciążeniowe PHP 5.5 + MariaDB 5.5

locust55

Najbardziej wydajna w testach syntetycznych konfiguracja programowa osiągnęła wynik 71ms (mediana) i 301ms (max) przy średnim naporze ruchu na poziomie 14.7 req/s.

Podsumowanie

Powyższe testy uwydatniają moim zdaniem dwie kwestie. Pierwsza z nich to konkluzja, że nie ma sensu gonić za cyferkami, bo nie zawsze się to opłaca. Druga konkluzja jest taka, że PHP 7 jest szybsze, ale interpreter to nie wszystko – jeśli kod (framework) nie jest zoptymalizowany pod nowe funkcje (zarówno PHP jak i MariaDB), to radykalne wzrosty w wynika syntetycznych testów nie przełożą się na radykalne wzrosty wydajności naszego serwisu. Być może kiedyś WordPress będzie umiał wykorzystać zmiany w PHP i MariaDB na tyle, że różnice będą wyraźne i opłacalne. Dzisiaj widać, że stabilna konfiguracja nie ustępuje najnowszej, a zalecana konfiguracja może mieć wpływ na warstwę programistyczną, bo wydajnościowo jest jedynie regresem.

Opublikowane .

Pracuję obecnie nad rozwojem usługi, która ma mieć globalny charakter – jest to API REST, które w odpowiedzi na zapytanie, daje dane w formacie JSON. Porcja danych jest względnie niewielka (przykładowo 280 Bajtów), a charakter informacji zwrotnej sprawia, że wymagany jest krótki czas oczekiwania na odpowiedź (tak krótki, jak to tylko możliwe). Na etapie wczesnego rozwoju aplikacji infrastruktury, całość uruchomiona była w Dublinie (Microsoft Azure, lokalizacja „North Europe”). Testy API przeprowadzane codziennie z kilku lokalizacji na świecie pokazały jednak, że z Europy do Australii, Brazylii czy Chin jest dość daleko, a łącza nie są odpowiednio szybkie (ani jedno, ani drugie nie powinno specjalnie zaskakiwać).

runscope

Trzeba było zadbać o to, aby skrócić czas oczekiwania na odpowiedź API dla klientów znajdujących się po drugiej stronie globu (patrząc z perspektywy Szczecina i Dublina). Na etapie wczesnych testów konfiguracja była dość oczywista: adres API (przykładowo api.mojausluga.pl) był rekordem A w strefie DNS usługi i wskazywał na adres IP Cloud Service uruchomionego w Azure – standardowa konfiguracja z zarezerwowanym adresem IP dla Cloud Service. Zwiększenie zasięgu i skrócenie czasów oczekiwania na odpowiedzi od API wymagało uruchomienia serwerów aplikacji po drugiej stronie świata – w ramach testu wybór padł na „South Central US”, czyli Texas.

Zrównoważenie ruchu między dwie lokalizacje, a co najważniejsze kierowanie zapytań do lokalizacji, która da odpowiedź z mniejszym opóźnieniem, powierzone zostało Azure Traffic Managerowi. Wymagało to zmiany w podejściu do konfiguracji DNS – nie ma już wskazywania bezpośrednio na adres IP usługi poprzez rekord A, a w zamian tego jest CNAME wskazujący na adres Traffic Managera. Oczywiście rodziło to pewne obawy, wynikające z czasu potrzebnego na przetworzenie całego zapytania – chcieliśmy zmniejszyć czas odpowiedzi API, ale musieliśmy zapłacić zwiększeniem czasu realizacji zapytania DNS (przynajmniej teoretycznie). Plusem tego rozwiązania jest fakt, że teraz nawet nie ma potrzeby rezerwowania adresów IP dla CS. Jak wyszło? Całkiem nieźle…

runscope_better

Jak widać, jest pewien wzrost czasu odpowiedzi API tam, gdzie odległość od DC była niewielka (np. między Niemcami, a Irlandią), ale spadki czasów oczekiwania na odpowiedź tam, gdzie odległości były duże, są olbrzymie. W przyszłości (mam nadzieję) dodane zostaną węzły w Azji, Ameryce Południowej i być może w Australii (wszystko zależy od popularności usługi w danym regionie i oczekiwań jej uzytkowników).

W kwestii kosztów tego rozwiązania, sprawa jest dość jasna. Na etapie tworzenia i testów, koszt samego Traffic Managera jest pomijalny (niecałe 50 eurocentów za milion zapytań DNS). Na etapie produkcji jest to już jednak koszt, który pojawi się w rozliczeniach. Infrastruktura usługi (API) jest aktualnie konfigurowana pod obciążenie na poziomie 270 milionów zapytań miesięcznie – 100q/s. Zakładając, że API byłoby obciążone na 100% przez cały miesiąc, koszt Traffic Managera wyniósł by około €123.

Opublikowane .

Czasem Windows jest potrzebny – taka praca – ale nie koniecznie jako maszyna wirtualna. Pierwszy powód bardzo trywialny: mam dysk SSD o pojemności zaledwie 60GB i nie chcę marnować go na maszynę wirtualną. Drugi bardzo praktyczny: dobrze jest mieć dostęp do swojego środowiska zapasowego z każdego miejsca na świecie, które ma klienta RDP.

Założenia są proste:

  1. Windows w chmurze (Windows 10 w chmurze Microsoft Azure)
  2. Katalog współdzielony między moją lokalną maszyną i Windowsem w chmurze
  3. Pulpit Windows jako drugi pulpit w Mint

Wynik:

 

Klient RDP z którego korzystam to Remmina. Aby działało współdzielenie zaosbów z maszyną lokalną konieczna jest aktualizacja Remminy do najnowszej wersji dostępnej w repozytorium PPA remmina-next. Ta sama aktualizacja sprawie, że Remmina będzie lepiej współpracować z Windows Server 2012 – jeśli ktoś korzysta (informacja wyłapana w sieci – nie jest zweryfikowana).

Do aktualizacji po dodaniu PPA są cztery pakiety:

Kwestia drugiego pulpitu oczywiście bardzo prosta. Sesja Remminy odpalona w trybie full screen, następnie minimalizacja do paska i przeniesienie na drugi obszar roboczy. Żadnej filozofii. Może kiedyś automatyzacja uruchamiania tej sesji po starcie systemu. Kto wie…