New Relic – must-have analizy wydajności
w e-commerce

W przypadku dużych, skomplikowanych wdrożeń, niezwykle przydatnym, a często krytycznym narzędziem do utrzymania pełnej sprawności i wydajności systemu jest oprogramowanie pozwalające na realny monitoring pracy całej aplikacji, w tym pracy serwerów. Takie narzędzie pozwala sprawdzić i zoptymalizować aplikację tuż przed i po starcie. A w konsekwencji skutecznie i szybko eliminować błędy w całym serwisie, które nie tylko wpływają na niską satysfakcję klientów, ale mogą się przyczynić do ich bezpowrotnego odejścia.

Jednym z takich rozwiązań jest New Relic. O tym dlaczego jest tak ważne, do czego służy i jakie wymierne korzyści daje Klientowi i partnerowi wdrożeniowemu, opowie Robert Żochowski – Dyrektor IT w Bold Brand Commerce.

Czym jest New Relic

Jest wiele narzędzi do monitorowania pracy serwerów. Natomiast New Relic jest unikalnym, ponieważ pozwala nie tylko na monitoring pracy serwerów, ale również, czy też przede wszystkim, na realny monitoring pracy całej aplikacji. Dzięki licznym wtyczkom umożliwia łatwą integrację z wieloma usługami. Zawiera też szereg funkcji, m.in.: monitoring parametrów serwerów, monitoring działania i dostępności usług, monitoring infrastruktury, monitoring od strony przeglądarki użytkownika (rozwiązanie na wzór Google Analytics), monitoring aplikacji mobilnych. Z mojej perspektywy, biorąc pod uwagę oferowane funkcje, warto skupić się na APM (Application Performance Monitoring), czyli monitoringu aplikacji.

Jak działa New Relic?

New Relic działa na serwerach produkcyjnych, co oznacza, że monitoruje realny ruch i realną pracę, którą one wykonują. Dla kogoś, kto przygotowuje system, bardzo trudno jest przewidzieć, albo mieć pewność, co do tego, jak zachowują się użytkownicy, jakich funkcji w systemie używają, po jakich stronach chodzą częściej, jaki system jest najczęściej używany. Jak widać, możliwości jest bardzo wiele. Padają przykładowo pytania o to, jak dużo wyświetleń stron produktowych pojawia się w stosunku do wyświetleń stron kategorii. Jeżeli w systemie są funkcje związane z obsługą wishlist, to jak dużo użytkowników z tego korzysta. Te wszystkie odpowiedzi daje nam właśnie New Relic, który pracując na produkcyjnej aplikacji monitoruje nie tylko cały ruch przychodzący z Internetu, ale również operacje wykonywane z poziomu powłoki serwera, np. zadania uruchamiane cyklicznie przez mechanizm cron.

W jakich przypadkach sprawdza się New Relic?

Pierwsza typowa sytuacja to taka, kiedy dostajemy działający serwis z problemami wydajnościowymi, które trzeba rozwiązać. Drugi przypadek dotyczy opcji, kiedy wdrażamy zupełnie nowy serwis. Na etapie tuż przed jego uruchomieniem, New Relic pokaże słabości danego rozwiązania. Wystarczy, że deweloper zrobi jakiś banalny błąd na poziomie wielokrotnego załadowania danych lub nie utworzy odpowiedniego indeksu w bazie i w efekcie czas wykonania zapytań SQL będzie bardzo długi. Z kolei na poziomie frontu może się zdarzyć, że front-end deweloper będzie ładował dane ajaxowo, i ten request ajaxowy, którego normalnie nikt nie przewidział, będzie zajmował bardzo dużo czasu. W konsekwencji strona produktu lub kategorii będzie zwrócona bardzo szybko, ale wykonanie dodatkowych requestów ajaxowych będzie powolniejsze i w połączeniu z dużą ich liczbą może skutkować obniżeniem wydajności całej aplikacji. Jest naprawdę wiele takich sytuacji, w których generalnie aplikacja działa bardzo wy – dajnie, ale występują konkretne przypadki odbiegające od normy, które New Relic również wyłapuje i pozwala prześledzić.

Czy osoba nieobeznana technicznie będzie potrafiła zinterpretować samodzielnie informacje z monitoringu?

Oprócz tego, że New Relic prowadzi szczegółowy monitoring, to daje też wiedzę osobie powiedzmy „mało technicznej”, jaki jest status aplikacji. Czy działa ona prawidłowo, czy występują jakieś problemy. Używany do tego jest tak zwany Apdex. Jest to indeks, który pokazuje w jakiej kondycji znajduje się aplikacja. Na ten indeks składa się wiele czynników, m.in. czasy odpowiedzi, czasy tego jak długo użytkownicy czekają na załadowanie się strony i jej wyświetlenie, ale również np. fakt występowania błędów na poziomie kodu aplikacji lub przypadki nieprawidłowych odpowiedzi serwera.

Ponadto Apdex działa na poziomie satysfakcji użytkownika. Jeżeli ten indeks jest równy 1 to znaczy, że wszyscy użytkownicy są zadowoleni z działania aplikacja, każda strona jest dostarczana bezbłędnie w krótkim czasie. W praktyce oczywiście nie zawsze tak jest, że czas dostarczenia każdej strony jest tak samo krótki. Zdarza się, że pojedyncze strony ładują się dłużej, gdyż nie były np. znalezione w cache (pamięci podręcznej). W takich przypadkach indeks pokazuje na przykład, że 95% użytkowników serwisu jest zadowolonych.

Czy jest jakaś skala zadowolenia użytkownika determinowana przez czas ładowania się strony?

Tak. New Relic pozwala zdefiniować jaki czas załadowania się strony jest dla nas czasem prawidłowym, czyli takim, kiedy użytkownik jest zadowolony. Domyślnie NewRelic przyjmuje czas 0,5 sek. Co oznacza, że jeżeli czasy odpowiedzi są poniżej 0,5 sekund, to użytkownicy są zadowoleni, jeżeli przyjmują zakres 0,5–2 sekund, to tolerują takie zachowanie. Jeżeli jednak ten czas wynosi powyżej 2 sekund to są totalnie sfrustrowani i opuszczają stronę.

Z punktu widzenia deweloperów istotne są bardziej szczegółowe dane na temat działania aplikacji. Co zapewnia nam New Relic? Jakie informacje możemy wyciągnąć z systemu?

Informacja o aplikacji podzielona jest na sekcje. Jedną z nich jest sekcja transakcji, w której rejestrowane są wszystkie operacje wykonywane przez kod php aplikacji. Operacje grupowane są z zastosowaniem modelu router/controller/action czyli np. w przypadku systemu Magento wszystkie zapytania dla stron produktowych zbierane są w pozycji catalog/product/view, a wyświetlenia kategorii w pozycji katalog/category/view. Przeprowadzony wcześniej audyt UX pozwoli wypracować odpowiednią strategię UX dla nowego systemu, mającą na uwadze newralgiczne miejsca w sklepie z perspektywy klienta. Choć sklep po migracji będzie nowy, to klienci w dużej mierze (przynajmniej początkowo) tacy sami. Warto zadbać i pamiętać o tym, aby wszelkie zmiany miały charakter ewolucyjny. Projektując interface starajmy się unikać nowości, które bardziej zniechęcają, niż zaskarbią sympatię klientów. Pozostawmy również funkcjonalności, które dotychczas cieszyły się pozytywną opinią i oceną klientów.

Każdą z zarejestrowanych transakcji czy też listę transakcji można sobie w każdej chwili podejrzeć.

Jest również możliwość wyświetlenia transakcji, które z punktu widzenia całego serwera zajmują najwięcej czasu. I nie chodzi tutaj o to, czy dana transakcja długo się wykonuje, tylko ruch, czyli ilość dokonanych transakcji w połączeniu z czasem ich wykonania generują najwięcej czasu po stronie serwera. Idąc dalej, możemy wyświetlić transakcje, których czas wykonania był najdłuższy. Jako przykład można podać operacje generowania raportu sprzedażowego. Jest również opcja podglądu transakcji, które z punktu widzenia użytkowników były najbardziej niesatysfakcjonujące, czyli najwięcej użytkowników ich używało i trwały one najdłużej. Wchodząc w szczegóły takiej transakcji widzimy jakie elementy składają się na czas transakcji, pokazane są zapytania bazodanowe, konkretne funkcje po stronie kodu php i ile co zajmuje czasu.

Co jeszcze możemy zobaczyć w panelu New Relic?

Kolejną funkcją jest prezentacja operacji bazodanowych. Możliwa jest obserwacja czasu trwania poszczególnych rodzajów zapytań w powiązaniu z ich ilością, dająca wiedzę o głównych źródłach obciążenia bazy danych. Następną funkcją jest prezentacja zarejestrowanych błędów w kodzie aplikacji php oraz błędnych odpowiedzi serwera. W przypadku każdej z wymienionych funkcji można wybrać przedział czasu, który nas interesuje, ale również w przypadku użycia więcej niż jednego serwera aplikacyjnego można zawęzić prezentowane dane do określonego serwera.

Warto zwrócić również uwagę na funkcję śledzenia wywoływań do zewnętrznych serwisów. Jeżeli nasz system wykonuje wywoływania do innego systemu zewnętrznego np. zewnętrznej wyszukiwarki, czy do bramki obsługującej płatności, to taki przypadek jest również rejestrowany. Możemy zaobserwować, jak i w jakim czasie zewnętrzne serwisy zwracają odpowiedzi, czy tu nie ma wąskiego gardła na poziomie działania systemu.

A jeśli chodzi o procedury – czy jest jakiś sposób obsługi błędów i raportowania przez deweloperów Bolda?

Jeżeli wiemy od początku, że z danym serwisem są problemy wydajnościowe, to New Relic jest takim narzędziem, które pozwala wskazać obszary, których przyspieszenie da największy wzrost satysfakcji z punktu widzenia klientów. A zatem wiedząc, że z jakąś aplikacją są problemy, to po pierwsze identyfikujemy te najbardziej wymagające optymalizacji, zajmujące najwięcej czasu z punktu widzenia serwera lub najbardziej niesatysfakcjonujące z punktu widzenia klientów. Optymalizujemy je, wprowadzamy i raportujemy efekty poprawki.

Podam przykład z naszego doświadczenia. Jeden z naszych czołowych klientów, Castorama Polska, korzysta z GSA (Google Search Appliance). Jest to narzędzie znajdujące się na wydzielonym serwerze, który zasilamy danymi z Magento. Działa jako wyszukiwarka. Odpytujemy ten serwer, aby zwrócił nam wyniki dla klienta (odnośnie produktów / inspiracji /kategorii) z interesującej klienta frazy. New Relic pomógł nam ustalić, że w niektórych przypadkach musimy czekać na odpowiedź od GSA dłużej, niż zakładaliśmy. Po wdrożeniu dodatkowego cache na komunikacji z GSA problem udało się wyeliminować.

Dlaczego to narzędzie jest tak ważne z punktu widzenia Klienta?

Po pierwsze, co warto dobitnie podkreślić – jest to niezależne narzędzie, którego nie da się oszukać. Prezentowane informacje są pomocne nie tylko dla nas, jako partnera wdrożeniowego, przygotowującego system, ale przede wszystkim dla Klienta. Dzięki takiemu rozwiązaniu do monitoringu ma on stały wgląd do tego, co się dzieje z aplikacją. Zawsze może widzieć , że w danej chwili wystąpił problem, jakiś konkretny błąd zarejestrowany na poziomie aplikacji lub okresowy spadek jej wydajności. A zatem wszystko jest transparentne, na bieżąco kontrolowane przez obie strony.

A w jaki sposób New Relic pozwala ograniczyć czas, ryzyko i koszty, które są nieodzownym elementem procesu wdrożeniowego?

Integrując New Relic z systemem, który będzie przykładowo migrowany na Magento 2 możemy przeprowadzić jego audyt, sprawdzić, czy jest prawidłowo zrobiony, czy nie ma problemów z  działaniem. Narzędzie jest tak że idealne, kiedy wykonujemy zmiany w serwisie, pozwala nam porównać zachowanie serwisu przed i po zmianach. Widzimy efekty naszych działań , na co miały wpływ lub gdzie ulepszyły działanie systemu. Przy czym mam tu na myśli aktywne wykorzystanie New Relic do identyfikacji tego, co się realnie dzieje w systemie. Oprócz tych dokładnych szczegółów danych transakcji, mamy dane ilościowe. A zatem ile było transakcji obsługiwanych przez cały system, ile było tylko wybranych transakcji, w danej godzinie, itp.

Co i jak możemy monitorować?

Aplikację możemy monitorować w  różnych miejscach, okresach i na różnych serwerach. Wchodząc do aplikacji zlokalizowanej na wielu serwerach wybieramy, czy chcemy zobaczyć ruch na wszystkich serwerach, czy też chcemy go zawęzić do konkretnego. Istnieje także opcja wyboru okresu czasu, który nas interesuje np. jeżeli wiemy, że wystąpił problem z aplikacją o godzinie 1, to możemy się cofnąć do tego czasu i podejrzeć, co się wtedy działo.

Jak działają powiadomienia i komunikaty o błędach?

Definiujemy nie tylko rodzaj powiadomienia, uzależniony od błędów: powiadomienia mailowe, powiadomienia na komórki (jest bowiem dostępna aplikacja mobilna), ale także to o jakim zdarzeniu chcemy być poinformowani. Podstawowym zdarzeniem jest spadek indeksu Apdex, raportowany jest każdy przypadek, gdy indeks jakości aplikacji spada poniżej określonego progu, niezależnie od przyczyny jego spadku.

Możemy również zdefiniować własne punkty systemu, które mogą być monitorowane z różnych lokalizacji z definiowaną przez użytkownika częstotliwością. W przypadku wykrycia braku dostępności takiego punktu zostanie wygenerowane ostrzeżenie i wysłane powiadomienie.

Jak długo przetrzymywane są dane?

To zależy od wykupionej opcji. Jest kilka poziomów. Wersja darmowa jest mało przydatna, ponieważ nie pokazuje żadnych danych szczegółowych, tylko ogólny ruch i  ogólne informacje, co się dzieje na serwerach. Wersja ESSENTIALS prezentuje już szczegółowe dane i  przechowuje je przez 3 dni, a najwyższa PRO pozwala analizować dane z okresu 90 dni. Dodatkowo wersja PRO pozwala rejestrować momenty wprowadzania zmian w kodzie, ułatwiając porównywanie działania aplikacji przed i po zmianach.

Czy taki czas przechowywania danych jest wystarczający? Jak to wygląda w przypadku Bolda? Potrzebne jest dodatkowe miejsce do składowania rejestrowanych informacji?

Jeżeli jest system, w którym różne operacje wykonywane są w różnych odsuniętych od siebie okresach czasu, przykładowo aktualizacja danych odbywa się raz na tydzień, to opierając się na danych z jednego dnia możemy pominąć istotne informacje. W takich sytuacjach należy uwzględnić to, jak system jest skonstruowany i jaki okres czasu musimy wziąć pod uwagę, aby przeanalizować wszystkie przypadki. W dużej większości ten podstawowy czas 3 dni wystarcza do pracy nad optymalizacją.

Czy są jakieś słabe strony tego narzędzia?

Z mojej perspektywy jest to wyjątkowo przydatne narzędzie, które pozwala na bieżący monitoring aplikacji produkcyjnej. To jest esencja tego systemu. W związku z tym nie da się za jego pomocą śledzić każdego wywołania aplikacji szczegółowo, na przykład na potrzeby prac developerskich. Do takich zastosowań służą inne narzędzia.

Potrzebujesz wiedzy o procesie wdrożeniowym, konfiguracji Magento, a może chcesz stworzyć wewnętrzny zespół IT? Napisz do nas zorganizujemy cykl szkoleń specjalnie dla Twojej firmy.

Robert Żochowski,
IT Director

+48 502 572 048
robert.zochowski@bold.net.pl