🎧 Czy zdarzyło Ci się, że strona „muliła”, a standardowe narzędzia jak PageSpeed Insights czy Query Monitor nie dawały jasnej odpowiedzi? W tym odcinku wchodzimy głębiej – na poziom serwera i interpretera PHP. Dowiesz się, czym są narzędzia APM i dlaczego New Relic to „czarna skrzynka”, którą warto mieć w swoim projekcie. Pokazuję, jak dane z APM zmieniają Twoją pozycję w rozmowie z klientem – z wykonawcy zgadującego przyczynę błędu, stajesz się inżynierem operującym na twardych dowodach.
🎙️ Nowy odcinek podcastu już dostępny!
Podcast dostępny m.in w: Spotify, Apple Podcasts, Google Podcasts
TRANSKRYPCJA AUTOMATYCZNA:
Maciej
Cześć, witam Cię w pierwszym odcinku w 2026 roku. W tym odcinku zajmiemy się tematyką narzędzi APM, czyli Application Performance Monitoring tutaj jako przykład posłuży nam New Relic. Zanim przejdziemy do tematu odcinka to chwila dla mojego partnera czyli marki CyberFolks, która dostarcza hosting i domeny pod wasze WP. Oprócz tego możecie znaleźć też sporą bazę wiedzy na blogu cyberfolks.pl
Końcówkę ubiegłego roku spędziłem nad budową mojej nowej platformy kursowej i nad przygotowaniem kolejnego mojego kursu. Będzie to kurs nie tylko dla deweloperów, w zasadzie dla wszystkich osób, które gdzieś tam kiedyś jakiegoś WordPressa postawiły, nawet pracują z WordPressem bardziej od strony panelu i od strony wyklikania strony, a niekoniecznie tak dewleopersko. ten kurs będzie dotyczył DNS-u i wszystkiego Co osoba pracująca z WordPressem o DNS-ach powinna wiedzieć. Oprócz takiej podstawowej wiedzy oczywiście podzielę się z Wami narzędziami jakie mogą się przydać przy testowaniu konfiguracji, przy weryfikowaniu pewnych problemów I zamkniemy ten kurs konfiguracją Cloudflera czyli jak przekierować sobie ruch przez Cloudflera na naszą stronę, to też zahacza o tematykę DNS-ów, więc to wszystko w tym mini-kursie będzie pokazane. Jeśli jesteś zainteresowany takim kursem, to zapraszam Cię na maciejkuchnik/dns tam możesz zostawić swojego maila. Będę Cię informował na bieżąco o postępach w pracy nad moim kursem. Zapraszam Cię również na moje sociale, na Instagrama, na TikToka, bo dzielę się tam takimi kulisami pracy nad samą platformą jak i nad kursem, który właśnie powstaje.
Myślę, że w swojej pracy kiedyś na pewno spotkałeś się z problemem wolno działającej strony bądź z sytuacją, której dostajesz np. od swojego hostingu informację o tym, że twoja strona pożera zbyt dużo zasobów. I z jednej strony może być to po prostu efekt dużego ruchu, co jest naturalną koleją rzeczy, że trzeba zapewnić po prostu dużo więcej mocy obliczeniowej, aby taki ruch obsłużyć.
No ale czasem się zdarza, że na stronie, która ma stosunkowo niewielki ruch. Takie obciążenie jest generowane dosyć duże i nie do końca wiemy z czego ono się lub na przykład klient zgłasza nam, że strona działa wolno ale bez większych tam szczegółów nie mówi konkretnie w jakich przypadkach, które podstrony itd. No to mamy pewien problem jeśli strona ładuje się wolno nie jesteśmy w stanie tego w prosty sposób odtworzyć no to tak naprawdę możemy działać sobie trochę na ślepo, trochę po omacku coś tam porobić, zobaczyć jaki to będzie miało ale ciężko mówić o jakichś konkretach. I tutaj właśnie z pomocą przychodzą nam narzędzia APM, Application Performance Monitoring. Ja tutaj się skupię na narzędziu jakim jest New Relic. Jest to narzędzie, które oczywiście pozwala na monitoring dużo. większej ilości rzeczy niż sam WordPress, bo możemy monitorować całe serwery jak i aplikacje. Ale oczywiście ja tutaj się skupię tylko na tym WordPressowym kawałku i na tym jak New Relic może Ci pomóc w pracy z Twoim WordPressem.
Na pewno spotkałeś się z narzędziami typu PageSpeed Insights, gdzie możesz sobie wkleić URL, zbadać stronę, zbadać prędkość ładowania. On ci pokaże tam jakieś wąskie gardła, problematyczne elementy, które powinieneś zoptymaliwać. Natomiast to jest taki wycinek rzeczywistości, bo po pierwsze narzędzie widzi tylko to, co się dzieje na mierzy ewentualnie czas odpowiedzi. No i jest to wykonywane w jednym punkcie czasu, że tak powiem, czyli powiedzmy wtorek godzinę 14, wchodzimy na tą stronę, wbijamy tego page speeda, czy w DevTools’ach z tego korzystamy, no i dostajemy jakieś wyniki, to jest ten stan na ten moment. Podobnie sprawa wygląda jeśli zainstalujemy sobie jakąś wtyczkę do WordPressa na przykład Query
Ona jest bardzo pomocna, daje nam też sporo informacji, ale jednocześnie jest to takie działanie w danym momencie, z punktu widzenia zalogowanego użytkownika. Oczywiście Query Monitor ma możliwość odpalenia tego również dla niezalogowanego użytkownika i podejrzenia jakichś tam parametrów. Często to wystarcza i jest wystarczające do złapania jakiegoś problematycznego wąskiego gardła, które powoduje albo nadmierne obciążenie serwera, albo zbyt wolne odpowiadanie naszej strony.
No ale znowu — jest to jakiś tam punkt w czasie, gdy my patrzymy. Czasem coś złapiemy, czasem nie, ale tak naprawdę nie mamy żadnego punktu odniesienia. Nie wiemy, jak te obciążenia i jak te problemy rozkładają się w czasie: czy to obciążenie jest stałe, czy ten czas odpowiedzi rośnie, maleje, co tam się właściwie dzieje.
I tutaj właśnie z pomocą przychodzi nam New Relic. To jest narzędzie, które pracuje na poziomie serwera, na poziomie PHP. I tutaj warto to zaznaczyć — to nie jest wtyczka do WordPressa, którą możecie po prostu zainstalować. Ona działa poziom niżej, na poziomie interpretera PHP. Jest tam agent New Relic jako moduł do PHP i podczas wykonywania skryptów WordPressa on mierzy pewne dane i przesyła je do chmury New Relic, do panelu, w którym możecie potem przeglądać te statystyki i wszystkie dane, mniej więcej tak jak przeglądacie statystyki chociażby w Google Analytics.
I tutaj, w odróżnieniu do Query Monitora, PageSpeeda czy innych tego typu narzędzi, mamy monitoring przez całą dobę — 24 godziny na dobę, 7 dni w tygodniu. Każde wywołanie WordPressa jest mierzone i możemy sobie potem popatrzeć na te dane.
Możemy się zalogować w poniedziałek rano do New Relica i zobaczyć sobie na przykład, co przez weekend się działo, jak szybko strona odpowiadała, jakie były tam problemy i co się dokładnie wydarzyło. Również wprowadzając jakieś optymalizacje, możemy sobie mierzyć ich efekty i mieć konkretne dane — nie tylko zebrane z powiedzmy pięciu czy dziesięciu requestów odpalonych z własnej przeglądarki, ale zebrane z realnego ruchu użytkowników. Na przykład mierzymy sobie czas odpowiedzi jakiejś konkretnej podstrony.
Oprócz tego oczywiście możemy te dane przeglądać i korelować je z jakimiś wydarzeniami, takimi jak premiera produktu w sklepie, jakiś pik sprzedaży, start kampanii marketingowej. Dzięki temu wiemy, co się stało i jaki wpływ miało na przykład uruchomienie kampanii sprzedażowej w Google Ads czy w innych tego typu narzędziach na obciążenie naszego serwera i na to, jak szybko strona odpowiadała.
Wtedy możemy to wszystko jakoś porównać, możemy cofnąć się w czasie i zobaczyć, jak te dane kształtowały się na przestrzeni, powiedzmy, tygodnia albo jakiegoś innego okresu, który jest nam akurat potrzebny.
New Relic jest narzędziem płatnym, natomiast w planie darmowym pozwala na zgromadzenie do 100 GB danych miesięcznie. Oczywiście on te 100 GB analizuje i jest to taka ilość, że myślę, iż spokojnie w większości projektów to wystarcza. Jeśli jednak ten limit się skończy, a nie macie podpiętej karty i nie przejdziecie na wyższy plan, to New Relic po prostu przestanie zbierać dane. Nic nadzwyczajnego się nie wydarzy – po prostu nie będziecie mieli danych z całego miesiąca, tylko z jakiegoś jego fragmentu.
Ale nawet na stronach, które generują spory ruch, te 100 GB danych to jest naprawdę całkiem dużo.
Tak jak już powiedziałem wcześniej, New Relic to nie jest wtyczka do WordPressa ani żadne tego typu narzędzie, które instalujecie z poziomu samego WordPressa. Trzeba zejść na poziom niżej, czyli na poziom serwera. I tutaj w zależności od tego gdzie hostujecie swojego WordPressa te drogi do instalacji New Relica będą
w większości takich powiedzmy zwykłych współdzielonych hostingów. Pewnie się okaże, że jednak tego New Relic’a zainstalować nie No bo jest to operacja już na poziomie samego serwera, co na współdzielonym serwerze raczej nie jest Chyba że są to takie bardziej premium hostingi, jak na przykład Kinsta, które mają w sobie integrację z New Relikiem, gdzie de facto instalacja tego New Relica, a w zasadzie jego aktywacja, sprowadza się do włączenia go, wpisania klucza i zatwierdzenia. To są w zasadzie trzy kliknięcia i te dane już lecą do chmury New Relic i tam są przetwarzane. I potem już w panelu New Relic widzicie, co z tym waszym WordPressem się dzieje. Jeśli macie serwer dedykowany czy jakiegoś tam VPS-a, tutaj jest dosyć prosty temat, bo instalujecie sobie agenta na tym serwerze. Jeśli macie dostęp do roota, instalujecie sobie agenta, wpinacie sobie ten serwer do New Relica i dane automatycznie są wysyłane do chmury New Relic.
Tutaj myślę, że warto wspomnieć o tym, że w Gdyni w tym roku na WordCampie był Harry Kimpel właśnie z New Relica, który pokazywał też proces instalacji. Ten skrypt instalacyjny robi w zasadzie wszystko za was. Jedyne, co musicie zrobić, to tak naprawdę uruchomić go i podać tam klucz. I to wszystko. I faktycznie tak to wygląda, że dosyć szybko ten New Relic się instaluje właśnie na jakiejś wirtualce czy na serwerze. To są dosłownie minuty, w ciągu których załatwiacie cały proces.
No a tak jak wspomniałem wcześniej, jeśli mamy jakiś taki zwykły, tradycyjny hosting, to raczej tutaj tego New Relica nie zainstalujemy. Natomiast pewnym wyjściem z tej sytuacji jest postawienie jakiejś wirtualki, czy to w Amazonie, czy gdziekolwiek indziej — po prostu jakiegoś serwera VPS, do którego mamy dostęp na poziomie roota.
Możemy wrzucić sobie taką stronę testowo, bez przekierowania domeny, bez niczego — po prostu wrzucamy sobie takiego WordPressa, kopiujemy go z produkcji i możemy za pomocą pliku etchosts przekierować sobie ruch z lokalnego komputera tak, aby nasz komputer kierował ten ruch właśnie do tego serwera.
Możemy wtedy poklikać sobie po tej stronie i New Relic zbiera nam jakieś dane. To też czasem się przydaje jako taka alternatywa, kiedy po pierwsze nie możemy podpiąć New Relica do środowiska produkcyjnego, a po drugie nie możemy zmigrować się na przykład na taki hosting, który by na to pozwalał.
To jest takie, powiedzmy, pośrednie wyjście, które pozwala sobie przeanalizować tego WordPressa bez dużego nakładu czasowego. Zdarzało mi się coś takiego w ostatnim czasie, że kopiowałem sobie całego WordPressa na jakąś wirtualkę w Amazonie. Tam miałem podpiętego New Relica i taki podstawowy stack WordPressowy, czyli NGINX, baza danych i PHP.
No i w zasadzie tyle. Tam sobie zdiagnozowałem te wąskie gardła i potem mogłem już podejść do optymalizacji całego WordPressa bądź zarekomendować jakieś konkretne kroki do tego, żeby usprawnić działanie danej strony.
Jak mamy już podłączonego New Relica pod naszego WordPressa, to teoretycznie możemy analizować te dane praktycznie od razu po jego skonfigurowaniu, bo te dane pojawiają się niemal w czasie rzeczywistym. Natomiast w praktyce dobrze jest poczekać sobie dzień, dwa albo trzy, żeby to narzędzie miało okazję zebrać miarodajne dane, które będą odzwierciedlały naturalny ruch na naszej stronie. Takie syntetyczne testy czy ręczne klikanie po WordPressie i obserwowanie tego, co się zbiera w New Relicu, niekoniecznie zawsze dają miarodajne efekty — ale o tym jeszcze za chwilę.
Jeśli już mamy ogarnięte zbieranie danych, to oczywiście kolejną częścią jest analiza tych danych. I co możemy zobaczyć w panelu New Relic? Przede wszystkim mamy tam takie rzeczy jak traces. I to jest zapis konkretnych wywołań WordPressa, czyli wejście na stronę główną, na podstronę produktu, na ekran logowania, stronę 404 i tak dalej.
Możemy to analizować zarówno w kontekście całościowym, na przykład pod kątem tego, jak efektywnie przetwarzana jest strona produktu w e-commerce, bądź jakiś inny custom post type i jego widok pojedynczy. Możemy też analizować to na podstawie konkretnego requestu, czyli możemy zobaczyć, że mamy jakiś wolny request wyświetlania strony głównej. Wtedy możemy wejść w ten konkretny trace i zobaczyć całe drzewo wywołań, czyli jakie funkcje po kolei były wywoływane i ile czasu każda z nich zajęła.
Tutaj możemy namierzyć wąskie gardła praktycznie na poziomie pojedynczej funkcji. Możemy zobaczyć, że całe wywołanie strony zajęło, powiedzmy, 10 sekund — jeśli to jest jakaś wolna strona, z którą mamy problemy. I tam po kolei mamy rozpisane, co ile zajęło. Możemy na przykład zaobserwować, że jedna konkretna funkcja wykonywała się przez 9 sekund. Wtedy mamy dosyć prostą sytuację, bo od razu widzimy to problematyczne miejsce.
Następnie możemy zajrzeć do kodu, zobaczyć, co tam jest zaimplementowane, czy to jest jakiś bug, czy to jest nieoptymalne zapytanie do bazy danych, czy jeszcze coś zupełnie innego, co wpływa właśnie na tego typu problemy i tak długie czasy wywołania. I możemy sobie każde takie wywołanie prześledzić krok po kroku. To jest bardzo przydatne w szukaniu, że tak powiem, „dziury w całym” i konkretnego miejsca, które jest odpowiedzialne za problem z wydajnością.
Możemy też analizować te dane w kontekście całej strony. Możemy sobie sprawdzić na przykład średni czas generowania strony albo konkretne percentyle. To jest bardzo ważne przy analizie danych, żebyśmy byli w stanie odsiać takie anomalie, bo wiadomo, że zwykła średnia nie do końca jest dobrym miernikiem. Mediana jest tutaj zdecydowanie lepsza, bo mówi nam więcej na temat realnej wydajności strony.
Szczególnie jeśli mamy takie dosyć pływające wyniki, że sto requestów wykona się w czasie do dwóch sekund, a kilka requestów zawiesi się i będzie wykonywać po 30 sekund, to taka średnia ma niewiele sensu, bo wyjdzie wartość zupełnie nieprzystająca do realnych warunków, jakie mamy w praktyce.
Kolejnym takim obszarem, który możemy sobie śledzić i który New Relic jest w stanie wyłapać, jest baza danych i wszystkie zapytania, które są wykonywane. Tutaj bardzo często, przy większych wdrożeniach WordPressa, zdarza się, że w pewnym momencie te zapytania do bazy stają się wąskim gardłem.
Taki klasyczny przykład, z którym wielu deweloperów się spotkało, to WP Query oparte na kilku warunkach zbudowanych na bazie meta_query, które mogą mocno obciążyć bazę danych, jeśli ta jest dosyć duża. Potocznie mówiąc, zamula to WordPressa i dodatkowo obciąża bazę. Tutaj właśnie New Relic bada te wszystkie rzeczy i jest w stanie wyłapać takie zapytania do bazy, które są nadmiernie czasochłonne.
Mamy też możliwość przeanalizowania, jak często takie zapytania są wysyłane do bazy, ile trwają średnio i gdzie mamy wąskie gardła. To jest bardzo przydatne narzędzie.
Oprócz tego New Relic gromadzi dane związane z logami PHP. Jeśli w naszym WordPressie pojawiają się warningi, notisy czy błędy, również znajdziemy je w New Relicu i możemy powiązać z konkretnymi transakcjami. Przy pierwszym rzucie oka do New Relica widzimy panel, który podpowiada dużo cennych informacji o WordPressowych hookach, które są wykonywane podczas pracy strony i wtyczek. New Relic ma wbudowany mechanizm, który pokazuje tabelę z czasami wykonania konkretnych hooków, uszeregowaną od największych do najmniejszych.
Widzimy po prostu, czym nasz serwer się zajmuje. To jest najlepsze, bo mamy tam po prostu hooki, które konsumują najwięcej czasu. Możemy sprawdzić, czy czas jest w miarę równomiernie rozłożony, czy może 80–90% czasu pracy pożera jeden konkretny hook, który jest bardzo kosztowny. To idealne rozwiązanie, żeby to sprawdzić, i są to dane zbierane na bazie normalnego ruchu, a nie syntetycznych testów.
Możemy również analizować hooki pod kątem tego, które wykonują się najwolniej. Warto pamiętać, że czas wykonania hooka to coś innego niż czas, jaki serwer potrzebuje na jego przetworzenie — hook może się wywoływać bardzo wiele razy, a jego sumaryczny czas będzie miał realny wpływ na szybkość działania strony.
Obok informacji o hookach mamy podobne informacje o pluginach. To daje szybki rzut oka na to, jak wtyczki zainstalowane na stronie wpływają na jej wydajność. Możemy też wyświetlić widok „Most Time Consuming”, czyli to, co zajmuje serwerowi najwięcej czasu.
Patrząc teraz w panel New Relica, widzę, że jedna ze wtyczek, którą mam podpiętą, zużywa ponad 35% czasu serwera. Jeśli dodamy do tego inne wtyczki, które są komponentami WPML-a, jak String Translation czy U-Commerce Multilingual, suma dochodzi do około 60–65%. Tutaj możemy śmiało postawić diagnozę, że WPML bardzo znacząco wpływa na to, że strona odpowiada wolno.
Te wtyczki komunikują się też z różnymi usługami, np. systemami do faktur czy bramkami płatności, i te requesty również widać w New Relicu. Czyli wszystko, co wychodzi z WordPressa na świat, jest monitorowane — np. zapytania do WordPress.org w celu sprawdzenia aktualizacji pluginów czy samego WordPressa. To bardzo cenne źródło informacji, bo jeśli strona działa wolno, przyczyną może być właśnie zewnętrzne API, które zamiast odpowiadać w 100–300 ms, odpowiada w kilku sekundach, a WordPress czeka na nie, zanim wygeneruje stronę.
Możemy też w historycznym ujęciu przeglądać te dane i sprawdzać, czy API zawsze odpowiadało tak wolno, czy coś się zmieniło w ostatnim czasie. To jest bardzo cenne przy rozwiązaniach e-commerce, które często komunikują się z systemami magazynowymi, księgowymi i innymi.
Jeśli mamy agenta zainstalowanego na serwerze czy VPS-ie, możemy monitorować także zasoby serwera: zajętość dysku, zużycie RAM-u, ruch na interfejsach sieciowych. Dzięki temu mamy pełny obraz sytuacji i możemy sprawdzić, czy wolna strona wynika z kodu WordPressa, czy z obciążenia serwera np. przez backupy czy inne procesy.
To jest super narzędzie deweloperskie. Nie szukamy problemów „na ślepo”, nie wyłączamy wtyczek losowo — choć czasem się udaje — ale wiele błędów pojawia się tylko w specyficznych warunkach i trudno je wyłapać ręcznie. New Relic pozwala analizować pojedyncze requesty i wyłapywać te problematyczne, które trwały nadzwyczaj długo.
Uwielbiam New Relica za to, że pozwala szybko diagnozować WordPressy i skraca czas rozwiązywania problemów. Drugi aspekt to perspektywa biznesowa: możemy klientowi pokazać konkretnie, jak jego strona działa, w oparciu o dane, a nie domysły.
Mieliśmy przypadek dużego WordPressa, który ładował się po kilkanaście, czasem kilkadziesiąt sekund. Na pierwszy rzut oka nie było wąskiego gardła, ale po podłączeniu New Relica zebraliśmy dane i okazało się, że problemy są na poziomie architektonicznym — źle zaprojektowana struktura strony nie sprawdzała się przy tej skali. Dzięki New Relic mogliśmy zidentyfikować te problemy i zaprezentować klientowi w formie wykresów i raportów.
Dzięki temu klientowi łatwo pokazać: „Patrz, tu były problemy, tu medianowy czas ładowania strony wynosił 10 sekund, a po optymalizacji spadł do 2,5 sekundy”. Nawet problematyczne 404, które generowały duży ruch i obciążały serwer, udało się namierzyć i zoptymalizować.
APM jest też takim „dupochronem” dla dewelopera: zmiany wprowadzane na stronie mogą być monitorowane i mamy konkretne dane, które pokazują, co faktycznie spowalnia stronę. Dzięki temu wiadomo, że awaria nie jest wynikiem przypadkowych działań osoby, która ostatnio coś zmieniała, tylko możemy to sprawdzić historycznie, krok po kroku.
Podsumowując: jeśli macie możliwość podłączenia New Relica do swojej strony, gorąco polecam. Można wyciągnąć mnóstwo informacji, nawet jeśli w danym momencie nie widać problemów. To takie źródło, które gromadzi dane niczym czarna skrzynka w samolocie, i w przypadku problemu pozwala analizować, co dokładnie się wydarzyło. Rozwiązanie problemów opieramy wtedy na danych, a nie zgadywaniu, która wtyczka lub wzrost ruchu coś spowodował.
W tym odcinku to wszystko. Zapraszam Cię na moje media społecznościowe, na Instagrama, a także na maciekuchnik.pl, gdzie możesz zostawić swojego maila, a ja będę informował Cię o postępach prac nad moim kursem o DNS-ach w kontekście WordPressa. Na dzisiaj to wszystko. Do usłyszenia.
