Regex

Czasami (a raczej zawsze) potrzebujemy coś wyciągnąć z odpowiedzi i wykorzystać to w jednym z kolejnych żądań.Nie ważne czy jest to jmeter, czy jakiś inny tool – wykorzystujemy do tego celu wyrażenia regularne.

Nie będę opisywał jak działają wyrażenia regularne (regular expressions). Podam za to linki do przydatnych stron.

‚Moja’ podstawowa strona, a raczej narzędzie online, do testowania wyrażeń regularnych i źródło wiedzy o ich konstrukcji:

https://www.regex101.com/

Poniżej coś dla ciut leniwszych:

http://www.hongkiat.com/blog/regex-web-developers/?imm_mid=0dfb9e&cmp=em-webops-na-na-newsltr_20160129 – przykłady trochę bardziej dla deweloperów, ale znalazłem też coś dla siebie

Regex

InfluxDB i Grafana

InfluxDB jest open-source’ową bazą danych time-series świetnie zastępującą bazę whisper w rozwiązaniach wykorzystujących protokół graphite (opis tutaj).

Aplikację Graphite zastąpmy produktem Grafana i mamy super środowisko do wizualizacji danych.

          InfluxDB grafanaInfluxDB

Oczywiście w  https://registry.hub.docker.com mamy oficjalny obraz Grafana oraz ‚prawie’ oficjalny obraz influxDB. Mamy też obrazy zawierające komplet komponentów wraz z  carbon’em.

Łatwo i szybko możemy zbudować sobie środowisko do monitorowania w czasie rzeczywistym przebiegu testów wydajnościowych czy to z jmeter’em czy to z Gatling’iem.

Konfiguracja dla Gatling.

Konfiguracja dla jmeter.

InfluxDB i Grafana

Wizualizacja danych ‚czasowych’

Trochę dziwny tytuł, ale myślę, że dobrze oddaje sens tego co chcę dzisiaj przedstawić.

Chciałbym w kilku kolejnych wpisach przybliżyć narzędzia, które pomogą zwizualizować dane, które najprościej mówiąc, na osi X mają czas, a dokładniej timestamp.

ELK, robi mniej więcej to samo, ale w opisanym wcześniej przypadku konfiguracja opiera się ściśle na pliku csv z raportem. Niekoniecznie wizualizacja danych w czasie rzeczywistym wymaga pracy z plikiem. Continue reading „Wizualizacja danych ‚czasowych’”

Wizualizacja danych ‚czasowych’

Gatling, Docker i spółka

Potrzebowałem szybko wystawić wynik testu z gatling ‚a, żeby omówić je z klientem. Mógłbym te wyniki spakować i wysłać mail’em, ale robienie tego po każdej iteracji wydało mi się mało optymalne.

Nie chciałem instalować sobie żadnego serwera http na moim komputerze. Z pomocą przyszedł Docker.

Wystarczy wejść do folderu z plikami raportu (raport zapisywany jest jako niewielka witryna web) i wykonać poniższe:

$ docker pull httpd
$ docker run -it --rm --name my-apache-app -v "$PWD":/usr/local/apache2/htdocs/ -p 80:80 httpd

Co powyższym zrobiłem? Ano pobrałem obraz maszyny z apache’m. Uruchomiłem z opcją zamapowania bieżącego folderu hosta na folder /usr/local/apach2/htdocs/ uruchamianej maszyny i zamapowania portu 80 hosta na port 80 uruchamianej maszyny i ….tadaaaa: po adresem http://127.0.0.1 mam wystawiony raport 🙂

gatling

Jeszcze tylko trzeba było grzebnąć w routerze, żeby wrzucić mój komputer do DMZ i raport stał się widoczny pod moim publicznym adresem ip 🙂

Następnym razem mogę pominąć pierwszy i ostatni krok, ponieważ mam już httpd lokalnie, a router zostawiam tak jak jest.

Gatling, Docker i spółka