Black Friday bez awarii: jak przetestować sklep internetowy pod obciążeniem

Po co test, skoro sklep działa

Test obciążeniowy sklepu internetowego to kontrolowana symulacja ruchu: skrypt udaje setki klientów, którzy jednocześnie przeglądają kategorie, szukają produktów, dodają je do koszyka i płacą. Celem nie jest „zobaczyć, czy się wywali”, tylko odpowiedzieć na trzy konkretne pytania:

• przy jakim ruchu czas odpowiedzi zaczyna rosnąć ponad akceptowalny poziom,
• który element pęka pierwszy (baza danych, PHP, wyszukiwarka, zewnętrzne API),
• ile zamówień na minutę sklep przyjmie bez błędów.

Black Friday i Cyber Monday to obok okresu przedświątecznego najbardziej przewidywalne szczyty w polskim e-commerce. Przewidywalne, a mimo to co roku część sklepów pada. Zwykle nie dlatego, że przyszło za dużo ludzi, tylko dlatego, że nikt nie sprawdził, co się stanie, gdy wszyscy przyjdą w ciągu jednej minuty.

Ustal cel w liczbach

Zanim ktokolwiek napisze skrypt, potrzebujesz danych z zeszłego roku albo z ostatniej dużej promocji. Z Google Analytics, logów serwera i panelu sklepu wyciągnij:

Cel testu ustawia się zwykle na 2-3-krotność zeszłorocznego szczytu, bo promocje się nakładają, a jeden mailing do 60 tysięcy adresów potrafi skupić ruch w kwadransie. Określ też progi sukcesu, na przykład: 95. percentyl czasu odpowiedzi karty produktu poniżej 1,5 s, koszyk i checkout poniżej 2,5 s, odsetek błędów poniżej 1 %.

Jeden test to za mało

Pod hasłem „test obciążeniowy” kryje się kilka różnych przebiegów i każdy odpowiada na inne pytanie:

• obciążeniowy - ruch rośnie stopniowo do zakładanego celu i utrzymuje się przez 20-30 minut; sprawdza, czy sklep spełnia progi,
• przeciążeniowy - ruch rośnie dalej, aż coś pęknie; pokazuje zapas i sposób, w jaki sklep się poddaje,
• skokowy - w kilka sekund z 50 do 800 użytkowników, dokładnie tak, jak po wysłaniu powiadomienia push,
• wytrzymałościowy - umiarkowany ruch przez kilka godzin; wyłapuje wycieki pamięci, puchnące logi i kolejki, które się nie opróżniają.

Przed Black Friday sensowne minimum to pierwszy i trzeci wariant. Test skokowy jest szczególnie wymowny: sklep, który spokojnie znosi 800 osób narastających przez kwadrans, potrafi się zadławić, gdy ta sama liczba wejdzie naraz.

Scenariusze, które mają sens

Najczęstszy błąd to test, który uderza w stronę główną. Strona główna siedzi zwykle w cache i wytrzyma prawie wszystko. Prawdziwe obciążenie generują operacje, których cache nie obsłuży:

1. Wyszukiwarka i filtry - każda kombinacja parametrów to osobne zapytanie do bazy.
2. Koszyk - w WooCommerce dodanie produktu uruchamia żądania AJAX, które omijają cache stron.
3. Checkout - wyliczenie dostawy, walidacja kuponów, zapis zamówienia i rezerwacja stanu.
4. Logowanie i konto klienta - aktywna sesja wyłącza cache na całą wizytę.
5. Integracje - wybór paczkomatu InPost, przejście do bramki płatniczej, wysyłka danych do BaseLinkera lub ERP.

Realistyczny miks to na przykład 60 % przeglądania, 25 % wyszukiwania i filtrowania, 12 % dodawania do koszyka i 3 % pełnych zamówień. Proporcje weź jednak z własnej analityki, nie z tego artykułu.

Narzędzia i środowisko

Do generowania ruchu najczęściej używamy k6 i Apache JMeter, rzadziej Gatlinga lub Locusta. k6 ma czytelne skrypty w JavaScripcie i łatwo go skalować w chmurze, JMeter lepiej radzi sobie z nagrywaniem złożonych sesji. Samo narzędzie jest mniej ważne niż dwie decyzje.

Gdzie testować. Najbezpieczniej na kopii produkcji o identycznych parametrach serwera. Jeśli sklep działa na platformie SaaS (Shopify, Shoper, IdoSell), infrastrukturą zarządza dostawca i zwykle nie wolno jej obciążać bez zgody - sprawdź regulamin. Wtedy testujesz głównie to, co jest po Twojej stronie: aplikacje, własne skrypty, integracje i API.

Co zrobić z płatnościami i kurierami. Przelewy24, PayU czy Tpay udostępniają środowiska testowe, ale nie służą one do generowania tysięcy transakcji. Na czas testu bramkę zastępuje atrapa, która odpowiada jak prawdziwe API, z realistycznym opóźnieniem. Tak samo postępuje się z API przewoźników. Usługi zewnętrzne sprawdza się osobno: jakie mają limity zapytań i jak zachowuje się sklep, gdy odpowiadają z kilkusekundowym opóźnieniem.

W trakcie testu musisz widzieć, co dzieje się w środku: zużycie CPU i pamięci, liczbę połączeń do bazy, wolne zapytania SQL, stan Redisa, kolejkę PHP-FPM. Bez tego test powie Ci tylko, że jest wolno, a nie dlaczego.

Co zwykle wychodzi w wynikach

Przykład: sklep odzieżowy na WooCommerce zakłada przed Black Friday, że wystarczy większy serwer. Test pokazuje jednak, że przy około 300 równoczesnych użytkownikach checkout zwalnia do 9 sekund, choć procesor jest obciążony w 40 %. W takim układzie winowajcami bywają:

• tabele z sesjami i metadanymi zamówień bez indeksów pod najczęstsze zapytania,
• wtyczka rabatowa, która przy każdym przeliczeniu koszyka czytała wszystkie aktywne reguły,
• synchronizacja stanów z hurtownią uruchamiana co minutę i blokująca tabelę produktów.

Po usunięciu takich hamulców ten sam serwer zwykle znosi wyraźnie większy ruch. Mocniejsza maszyna kosztowałaby więcej i niewiele by zmieniła, bo wąskie gardło siedzi w bazie, a nie w procesorze.

Inne typowe znaleziska: brak cache pełnych stron dla gości, zdjęcia serwowane bez CDN, wyszukiwarka oparta na zapytaniach LIKE zamiast indeksu (Elasticsearch, OpenSearch, Meilisearch), zadania cron wyzwalane ruchem użytkowników, za mała pula procesów PHP-FPM.

Harmonogram przed szczytem

Test na tydzień przed Black Friday to za późno, bo nie zostaje czasu na poprawki. Rozsądny plan wygląda tak:

• 8 tygodni wcześniej - zebranie danych, ustalenie celów, przygotowanie środowiska testowego.
• 6 tygodni wcześniej - pierwszy test i lista wąskich gardeł.
• 4-3 tygodnie wcześniej - poprawki i powtórny test na tych samych scenariuszach.
• 2 tygodnie wcześniej - zamrożenie zmian w kodzie i wtyczkach, żadnych nowych integracji.
• W dniu szczytu - dyżur osoby technicznej, monitoring z alertami, rozłożone w czasie wysyłki mailingów i powiadomień push.

Przygotuj też plan awaryjny: lekką stronę z komunikatem przy przeciążeniu zamiast białego ekranu, możliwość szybkiego wyłączenia ciężkich elementów (rekomendacje, liczniki, widżety opinii) i kontakt do dostawcy hostingu na ten konkretny wieczór.

Od czego zacząć

Jeśli do szczytu został więcej niż miesiąc, zacznij od zebrania liczb z ostatniej promocji i sprawdzenia, które części sklepu omijają cache. Już to zwykle wskazuje dwa, trzy podejrzane miejsca. Pełne testy obciążeniowe prowadzimy zdalnie: przygotowujemy scenariusze na podstawie Twojej analityki, generujemy ruch z chmury i oddajemy raport z poprawkami uszeregowanymi według wpływu na wynik. Jeśli problem tkwi w architekturze samego sklepu, pomagamy ją przebudować w ramach usługi sklep internetowy. O tym, jak pracujemy z branżą, przeczytasz na stronie handel i e-commerce.