Sklep internetowy działa wolno. Jak znaleźć przyczynę przed zmianą serwera?

W skrócie

Wolny sklep nie musi potrzebować mocniejszego serwera. Przyczyną może być pojedyncze zapytanie do bazy danych, zewnętrzne API, źle działający cache, ciężki kod JavaScript, zadanie wykonywane podczas żądania albo proces, który przeciąża serwer tylko w określonych godzinach.

Zanim zwiększysz CPU i RAM albo przeniesiesz sklep na droższy hosting, warto ustalić, na którym etapie rzeczywiście tracony jest czas. Dopiero wtedy wiadomo, czy potrzebna jest optymalizacja aplikacji, bazy danych, integracji czy infrastruktury.

Najpierw ustal, co właściwie działa wolno

Informacja, że sklep działa wolno, niewiele mówi programiście. Strona główna może otwierać się w sekundę, podczas gdy wyszukiwarka potrzebuje pięciu sekund, dodanie produktu do koszyka trwa trzy, a zapis zamówienia czeka na odpowiedź zewnętrznego systemu.

Dlatego pierwszym krokiem powinno być odtworzenie konkretnej sytuacji.

Warto zapisać adres strony, wykonywaną czynność, przybliżony czas wystąpienia spowolnienia, urządzenie, informację o zalogowaniu użytkownika oraz dane mające znaczenie dla procesu, na przykład zawartość koszyka, wybraną metodę dostawy czy sposób płatności.

Jeżeli spowolnienie występuje tylko czasami, dokładna godzina jest szczególnie cenna. Można wtedy porównać ją z logami aplikacji, wykorzystaniem zasobów serwera, zapytaniami do bazy i działaniem integracji.

PageSpeed nie odpowie na każde pytanie

PageSpeed Insights i Core Web Vitals są bardzo przydatne, ale nie są pełną diagnostyką wydajności sklepu.

LCP pomaga ocenić szybkość wyświetlenia głównej treści, INP reakcję strony na interakcje użytkownika, a CLS stabilność układu. Dzięki nim można znaleźć problemy widoczne z perspektywy przeglądarki i użytkownika.

Sklep jest jednak aplikacją, a nie tylko zestawem stron do wyświetlenia.

PageSpeed może pokazywać dobre wyniki dla karty produktu, podczas gdy wyszukiwanie, naliczanie rabatu, wybór Paczkomatu, zapis zamówienia albo panel administracyjny działają zdecydowanie za wolno.

Dlatego diagnostyka powinna obejmować również konkretne operacje wykonywane podczas korzystania ze sklepu.

Sprawdź, ile czasu zajmuje odpowiedź aplikacji

Jeżeli użytkownik długo czeka, zanim przeglądarka zacznie otrzymywać właściwą odpowiedź, trzeba przeanalizować backend.

Pomocny może być TTFB, ale nie należy traktować go jako dokładnego pomiaru czasu wykonywania kodu PHP czy odpowiedzi samego serwera. Na wynik wpływają również między innymi połączenie, przekierowania, CDN i cache.

Dlatego po wykryciu wysokiego czasu odpowiedzi warto zejść poziom niżej i zmierzyć, co aplikacja robi podczas konkretnego żądania.

Może się wtedy okazać, że z pięciu sekund oczekiwania cztery zajmuje jedno zapytanie SQL albo oczekiwanie na odpowiedź zewnętrznego API.

Baza danych często ujawnia prawdziwą przyczynę

Sklep wykonuje dużą liczbę operacji na bazie danych. Pobiera produkty, ceny, warianty, stany magazynowe, klientów, zamówienia, ustawienia, promocje i dane potrzebne w integracjach.

Problem pojawia się, gdy pojedyncza operacja wykonuje bardzo ciężkie zapytanie albo kilkaset małych zapytań, które razem zaczynają zajmować znaczną część czasu.

Warto szukać między innymi wolnych zapytań SQL, brakujących indeksów, pobierania znacznie większej liczby rekordów niż potrzeba, wielokrotnego pobierania tych samych danych oraz zapytań uruchamianych osobno dla każdego elementu listy.

Znaczenie ma również skala. Rozwiązanie działające poprawnie przy 5 tysiącach produktów może zachowywać się zupełnie inaczej przy 200 tysiącach produktów i kilku milionach rekordów związanych z zamówieniami.

Jedna integracja może zatrzymać cały request

Sklepy coraz częściej zależą od zewnętrznych systemów. Podczas jednego procesu mogą komunikować się z ERP, magazynem, systemem kurierskim, operatorem płatności, CRM, systemem lojalnościowym albo usługą obliczającą dostępność produktu.

Jeżeli aplikacja czeka na odpowiedź takiej usługi przed wysłaniem odpowiedzi użytkownikowi, jej opóźnienie staje się opóźnieniem sklepu.

Dlatego podczas diagnostyki trzeba mierzyć czas poszczególnych połączeń zewnętrznych, a nie tylko całego żądania.

Jeżeli konkretne API regularnie odpowiada po trzech sekundach, zwiększenie liczby rdzeni procesora na serwerze sklepu tego czasu nie skróci.

Warto wtedy sprawdzić, czy dane rzeczywiście muszą być pobierane synchronicznie, czy można wykorzystać cache, przygotować je wcześniej albo przenieść część operacji do kolejki.

Nie każdą operację można jednak bezpiecznie opóźnić. Aktualna cena, dostępność produktu czy potwierdzenie płatności mogą być niezbędne do poprawnego wykonania zamówienia. Architektura musi uwzględniać znaczenie danych, a nie tylko szybkość odpowiedzi.

Sprawdź zadania wykonywane podczas żądania

Częstą przyczyną wolnego działania jest wykonywanie zbyt dużej ilości pracy w momencie, gdy użytkownik czeka na odpowiedź.

Po zapisaniu zamówienia sklep może na przykład aktualizować inne systemy, generować dokumenty, wysyłać wiadomości, przeliczać dane, synchronizować magazyn albo wykonywać operacje potrzebne dopiero kilka sekund później.

Część takich zadań można wykonywać asynchronicznie w kolejce. Użytkownik otrzymuje wtedy odpowiedź po wykonaniu operacji koniecznych do zakończenia procesu, a pozostała praca odbywa się w tle.

Przy analizie trzeba jednak dokładnie ustalić, które operacje są wymagane przed potwierdzeniem zamówienia. Przeniesienie wszystkiego do kolejki może przyspieszyć odpowiedź, ale jednocześnie stworzyć problemy ze spójnością danych.

Cache pomaga tylko wtedy, gdy buforujesz właściwe dane

Cache pozwala uniknąć wielokrotnego wykonywania tej samej pracy. Może dotyczyć całych stron, fragmentów odpowiedzi, wyników zapytań, danych z API albo obiektów wykorzystywanych przez aplikację.

Nie każda część sklepu nadaje się jednak do buforowania w ten sam sposób.

Lista kategorii może być wspólna dla tysięcy użytkowników, ale zawartość koszyka, indywidualny rabat, ceny B2B czy dane klienta już nie.

Źle skonfigurowany cache może powodować nie tylko problemy z wydajnością, ale również wyświetlanie nieaktualnych lub niewłaściwych danych.

Podczas optymalizacji trzeba więc określić, co można buforować, jak długo dane mogą pozostać aktualne i jakie zdarzenie powinno je unieważnić.

CPU na poziomie 100% jest informacją, a nie diagnozą

Jeżeli podczas spowolnienia procesor jest w pełni wykorzystany albo kończy się dostępna pamięć RAM, infrastruktura rzeczywiście może być ograniczeniem.

Nadal warto jednak ustalić, dlaczego tak się dzieje.

CPU może zużywać normalny ruch klientów, ale równie dobrze przyczyną może być źle działające zadanie cykliczne, import produktów, generowanie feedu, bot intensywnie przeglądający tysiące adresów albo jedna kosztowna operacja wykonywana przy każdym wejściu użytkownika.

Do podobnej sytuacji może dojść z pamięcią, bazą danych i operacjami dyskowymi.

Dodanie zasobów może chwilowo zmniejszyć objawy, ale jeżeli przyczyna skaluje się razem z ruchem lub ilością danych, sytuacja może wrócić po kilku tygodniach.

Sprawdź, czy problem pojawia się pod obciążeniem

Sklep może działać bardzo szybko podczas testu wykonywanego rano przez jednego programistę i zwalniać każdego dnia o 19:00.

Dlatego pojedynczy pomiar nie zawsze wystarczy.

Warto porównać czas odpowiedzi z wykorzystaniem CPU, RAM, bazy danych, liczbą jednoczesnych żądań i działaniem procesów wykonywanych w tle.

Jeżeli spowolnienie pojawia się regularnie o podobnej godzinie, trzeba sprawdzić również harmonogram zadań. Import produktów, synchronizacja stanów, generowanie raportów albo backup uruchamiany w tym samym czasie może konkurować o zasoby z klientami sklepu.

Problem może być również w przeglądarce

Szybka odpowiedź backendu nie oznacza jeszcze szybkiego interfejsu.

Strona może pobierać dużą ilość JavaScriptu, wykonywać kosztowne operacje w głównym wątku albo uruchamiać wiele skryptów marketingowych i analitycznych.

W takim przypadku serwer może zwracać odpowiedź szybko, ale użytkownik nadal będzie czekał na możliwość swobodnej interakcji ze stroną.

To właśnie jeden z powodów, dla których podczas diagnostyki warto rozdzielić czas odpowiedzi backendu od pracy wykonywanej później w przeglądarce.

Kiedy mocniejszy serwer rzeczywiście ma sens?

Zwiększenie zasobów jest uzasadnione, gdy pomiary pokazują, że aplikacja wykorzystuje dostępne zasoby i właśnie ich brak ogranicza wydajność.

Może to być procesor, pamięć RAM, baza danych, przepustowość albo wydajność operacji dyskowych.

Większy serwer może być również normalnym elementem skalowania sklepu, który obsługuje coraz więcej klientów, produktów i zamówień.

Nie powinien jednak zastępować diagnozy.

Jeżeli aplikacja przez cztery sekundy czeka na zewnętrzne API, zapytanie SQL skanuje miliony niepotrzebnych rekordów albo przeglądarka blokuje się na wykonywaniu JavaScriptu, dodatkowe CPU nie usuwa właściwej przyczyny.

Jak potwierdzić, że optymalizacja rzeczywiście pomogła?

Po wprowadzeniu zmiany trzeba ponownie wykonać dokładnie ten proces, który wcześniej działał wolno.

Jeżeli zapis zamówienia trwał 4,8 sekundy, mierzymy ponownie zapis zamówienia. Jeżeli wyszukiwarka zwalniała przy konkretnej frazie, testujemy tę samą frazę. Jeżeli problem występował pod obciążeniem, sprawdzamy zachowanie również przy większej liczbie jednoczesnych użytkowników.

Warto porównywać nie tylko średnią. Pojedyncze bardzo wolne odpowiedzi mogą być dla sklepu równie istotne jak przeciętny czas działania.

Po optymalizacji trzeba też sprawdzić poprawność działania. Skrócenie czasu odpowiedzi nie jest sukcesem, jeżeli cache pokazuje nieaktualną cenę albo operacja przeniesiona do kolejki czasami nie dochodzi do skutku.

Najpierw pomiar, później decyzja o infrastrukturze

Wydajność sklepu jest wynikiem działania wielu warstw: przeglądarki, sieci, aplikacji, bazy danych, cache, kolejek, integracji i infrastruktury.

Dlatego informacja, że sklep jest wolny, nie powinna automatycznie prowadzić do zakupu droższego serwera.

Najpierw warto znaleźć operację, która odpowiada za opóźnienie, zmierzyć ją i ustalić jej przyczynę. Czasami rozwiązaniem będzie indeks w bazie danych, czasami cache, zmiana działania integracji albo przeniesienie zadania do kolejki. W innych przypadkach pomiary rzeczywiście pokażą, że infrastruktura jest za mała.

W Dock zaczynamy optymalizację właśnie od takiej diagnostyki. Jeżeli masz konkretny widok, proces albo moment, w którym sklep zwalnia, możemy przeanalizować wydajność aplikacji i infrastruktury i wskazać, gdzie faktycznie tracony jest czas.

Jeżeli chcesz sprawdzić przyczynę przed zmianą serwera, napisz do nas i opisz, który element sklepu działa wolno oraz kiedy najłatwiej