Sezonowe kampanie sprzedażowe potrafią w ciągu kilku minut skierować do sklepu internetowego ruch, który w zwykłym okresie rozkłada się na cały dzień. Klienci jednocześnie przeglądają produkty, używają filtrów, dodają towary do koszyka, wpisują kody rabatowe i przechodzą do płatności. Każda z tych operacji obciąża aplikację, bazę danych oraz infrastrukturę serwerową.
Niewystarczająco przygotowany hosting może w takim momencie powodować wydłużenie czasu ładowania, błędy podczas składania zamówień, problemy z aktualizacją stanów magazynowych, a nawet całkowitą niedostępność sklepu. Straty nie ograniczają się wtedy do pojedynczych transakcji. Klienci mogą zrezygnować z zakupu, wybrać konkurencję i stracić zaufanie do marki.
Skuteczne przygotowanie infrastruktury nie polega jednak wyłącznie na zwiększeniu parametrów serwera. Potrzebne są prognoza ruchu, testy obciążeniowe, optymalizacja aplikacji, właściwa konfiguracja pamięci podręcznej, monitoring oraz procedury reagowania na przeciążenia. Dopiero połączenie tych elementów pozwala zbudować hosting dla sklepu internetowego, który pozostanie stabilny również w najważniejszych godzinach kampanii.
Jak oszacować skalę sezonowego wzrostu ruchu w sklepie internetowym?
Przygotowania warto rozpocząć od danych, a nie od przypadkowego zwiększania zasobów. Najbardziej wartościowych informacji dostarczają statystyki z wcześniejszych kampanii, raporty sprzedażowe, dane analityczne oraz metryki serwera. Należy sprawdzić nie tylko całkowitą liczbę odwiedzin, ale przede wszystkim krótkie okresy największego natężenia ruchu.
Średnia dobowa może wyglądać bezpiecznie, mimo że przez kilkanaście minut sklep działał na granicy dostępnych zasobów. Infrastruktura musi być przygotowana właśnie na taki szczyt, ponieważ to wtedy rośnie ryzyko kolejek, przekroczenia limitów procesów i błędów podczas obsługi zamówień.
W analizie warto uwzględnić:
- maksymalną liczbę równoczesnych użytkowników;
- liczbę żądań HTTP w krótkich przedziałach czasu;
- liczbę zamówień i rozpoczętych płatności;
- współczynnik konwersji w poprzednich kampaniach;
- popularność konkretnych produktów i kategorii;
- natężenie ruchu po wysłaniu newslettera lub uruchomieniu reklam;
- aktywność botów, porównywarek cenowych i robotów wyszukiwarek;
- planowaną godzinę rozpoczęcia promocji.
Prognoza powinna obejmować co najmniej trzy warianty: spodziewany, wysoki oraz skrajny. Pierwszy przedstawia najbardziej prawdopodobny rozwój wydarzeń. Drugi uwzględnia lepsze od zakładanych wyniki kampanii. Trzeci odpowiada na pytanie, co stanie się w przypadku gwałtownego wzrostu zainteresowania, na przykład po publikacji materiału przez popularnego twórcę lub wysłaniu wiadomości do dużej bazy odbiorców.
Trzeba również oddzielić zwykłe przeglądanie oferty od operacji dynamicznych. Wyświetlenie obrazu lub publicznej strony produktu może zostać obsłużone przez cache i CDN. Logowanie, wyszukiwanie, koszyk, naliczanie rabatów, sprawdzanie stanów magazynowych oraz płatność wymagają natomiast pracy aplikacji i bazy danych. Dwa sklepy z taką samą liczbą odwiedzin mogą więc generować zupełnie inne obciążenie.
Jakie zasoby hostingu są najważniejsze podczas kampanii sprzedażowych?
Wydajność sklepu wynika ze współpracy wielu elementów. Samo zwiększenie pamięci RAM nie rozwiąże problemu, jeżeli ograniczeniem jest zbyt mała liczba procesów aplikacji, wolny dysk albo przeciążona baza danych. Dlatego hosting należy oceniać jako cały system, a nie wyłącznie zestaw wartości widocznych w cenniku.
Największe znaczenie mają następujące zasoby:
- CPU – odpowiada za wykonywanie kodu aplikacji, obsługę zapytań, generowanie stron dynamicznych, przeliczanie koszyka, działanie filtrów i procesów uruchamianych w tle;
- RAM – jest wykorzystywany przez aplikację, bazę danych, system operacyjny i pamięć podręczną. Zbyt mała ilość pamięci może prowadzić do spowolnień lub przerywania procesów;
- wydajność dysku i IOPS – wpływa na odczyty oraz zapisy w bazie, obsługę logów, sesji, plików tymczasowych i kopii zapasowych;
- liczba procesów lub workerów – określa, ile dynamicznych żądań może być jednocześnie przetwarzanych;
- połączenia z bazą danych – ich wyczerpanie może powodować kolejki albo błędy, nawet gdy procesor nie jest całkowicie wykorzystany;
- przepustowość sieci – ma znaczenie szczególnie przy dużej liczbie obrazów, pobieranych plików lub intensywnej komunikacji z zewnętrznymi systemami.
W praktyce trzeba obserwować nie tylko poziom wykorzystania zasobów, lecz także czas jego utrzymywania. Krótkotrwały wzrost wykorzystania CPU nie musi oznaczać problemu. Jeżeli jednak procesor przez dłuższy czas pracuje na granicy możliwości, rosną czasy odpowiedzi, a kolejne żądania czekają na obsłużenie.
Istotny jest również zapas wydajności. Hosting, który podczas zwykłego dnia wykorzystuje niemal wszystkie dostępne zasoby, nie jest przygotowany na większą kampanię. W takim przypadku nawet niewielki wzrost liczby klientów może doprowadzić do przekroczenia limitów.
Nie można pomijać usług zewnętrznych. Sklep często komunikuje się z operatorem płatności, systemem ERP, magazynem, firmą kurierską, platformą mailingową lub narzędziem księgowym. Wolna odpowiedź jednej integracji może blokować proces aplikacji, a wielokrotne ponawianie nieudanych wywołań dodatkowo zwiększa obciążenie serwera.
W jaki sposób testy obciążeniowe pomagają przygotować sklep na sezon sprzedażowy?
Test obciążeniowy pozwala sprawdzić, jak sklep zachowuje się pod wpływem rosnącej liczby użytkowników. Jego celem nie jest wyłącznie wykazanie, że strona działa. Test powinien określić granicę wydajności, wskazać pierwsze wąskie gardło oraz pokazać, czy system wraca do normalnego działania po ustaniu przeciążenia.
Scenariusz musi odwzorowywać rzeczywiste zachowania klientów. Testowanie wyłącznie strony głównej daje niewiele informacji, ponieważ najważniejsze procesy odbywają się głębiej w ścieżce zakupowej. Należy symulować między innymi:
- wejście do sklepu;
- przejście do kategorii;
- użycie wyszukiwarki lub filtrów;
- otwarcie karty produktu;
- dodanie produktu do koszyka;
- zmianę ilości lub zastosowanie kodu rabatowego;
- przejście do zamówienia;
- wykonanie testowej płatności.
Przygotowania mogą obejmować test przy stopniowo zwiększanym obciążeniu, test przeciążeniowy określający maksymalną wydajność, test nagłego skoku ruchu oraz dłuższy test stabilności.
Podczas pomiarów należy obserwować percentyle czasu odpowiedzi, przepustowość, liczbę błędów oraz wykorzystanie CPU, RAM, dysku, procesów i połączeń z bazą. Sama średnia czasu odpowiedzi może ukrywać problemy części użytkowników. Jeżeli większość stron otwiera się szybko, ale co dziesiąte żądanie trwa kilka sekund, doświadczenie klientów nadal będzie niezadowalające.
Test powinien zostać przeprowadzony w środowisku możliwie zbliżonym do produkcji, ale z wykorzystaniem bezpiecznych danych testowych. Trzeba też zadbać, aby symulowane zamówienia nie zostały przekazane do rzeczywistej realizacji, księgowości, magazynu lub systemu wysyłkowego.
Po każdej większej optymalizacji należy ponownie wykonać ten sam scenariusz. Dzięki temu można porównać wyniki i sprawdzić, czy zmiana rzeczywiście poprawiła wydajność, zamiast jedynie przenieść problem do innego elementu systemu.
Jak zoptymalizować bazę danych i aplikację przed wzrostem liczby zamówień?
Baza danych jest jednym z najczęstszych miejsc powstawania wąskich gardeł. W sklepie zapisuje ona produkty, warianty, klientów, sesje, koszyki, zamówienia, kupony, stany magazynowe oraz informacje wykorzystywane przez integracje. Im większy katalog i bardziej rozbudowane mechanizmy sprzedażowe, tym więcej pracy musi wykonać przy każdym żądaniu.
Pierwszym krokiem powinna być analiza wolnych zapytań. Szczególnej uwagi wymagają wyszukiwarka, filtrowanie produktów, sortowanie, pobieranie wariantów, przeliczanie koszyka i wyświetlanie historii zamówień. Plan wykonania zapytania można sprawdzić między innymi za pomocą polecenia EXPLAIN.
Polecenie EXPLAIN pozwala ocenić sposób wykonywania zapytania oraz sprawdzić, gdzie zastosowanie indeksu może przyspieszyć wyszukiwanie rekordów. Jednocześnie tworzenie zbyt wielu indeksów zajmuje miejsce i zwiększa koszt operacji zapisu, dlatego każda zmiana powinna wynikać z pomiarów.
Przed rozpoczęciem kampanii warto:
- przeanalizować najwolniejsze i najczęściej wykonywane zapytania;
- dodać uzasadnione indeksy do kolumn używanych w filtrowaniu, sortowaniu i łączeniu tabel;
- usunąć nieużywane moduły oraz rozszerzenia;
- ograniczyć skrypty uruchamiane przy każdej odsłonie;
- uporządkować zadania cykliczne;
- sprawdzić rozmiar tabel tymczasowych, logów i danych sesyjnych;
- zoptymalizować wyszukiwarkę oraz filtry katalogu;
- ograniczyć liczbę zapytań wykonywanych przez szablon strony.
Procesy, których klient nie musi wykonywać natychmiast, warto przenieść do kolejek lub zadań działających w tle. Dotyczy to między innymi generowania raportów, synchronizacji danych, wysyłania wiadomości, eksportów, importów czy aktualizacji informacji w zewnętrznych systemach. Dzięki temu użytkownik nie musi czekać, aż wszystkie dodatkowe operacje zakończą się podczas jednego żądania.
Istotny jest również harmonogram prac. Aktualizacje systemu, wtyczek i zależności trzeba przeprowadzać z wyprzedzeniem, a następnie poddać testom funkcjonalnym i wydajnościowym. Wprowadzanie dużych zmian tuż przed rozpoczęciem kampanii ogranicza czas na wykrycie regresji i zwiększa ryzyko awarii w najważniejszym momencie.
Jak wykorzystać pamięć podręczną i CDN do szybszej obsługi klientów?
Pamięć podręczna ogranicza liczbę operacji, które aplikacja i baza danych muszą wykonywać wielokrotnie. Jeżeli ta sama publiczna strona jest wyświetlana tysiącom użytkowników, nie zawsze musi być generowana od początku dla każdego z nich.
Cache może obejmować kilka poziomów. Pełny cache strony sprawdza się przede wszystkim przy publicznych treściach katalogu i stronach informacyjnych. Cache obiektowy przechowuje często odczytywane dane aplikacji, a wyniki wybranych zapytań można buforować w warstwie aplikacji lub w zewnętrznej pamięci podręcznej. Sam silnik bazy korzysta natomiast z buforów danych i indeksów, które ograniczają liczbę odczytów z dysku. Dostępność i zasadność stosowania osobnego cache wyników zapytań zależy od konkretnego systemu bazodanowego oraz charakteru obciążenia.
Z pełnego cache należy wykluczyć treści zależne od konkretnego użytkownika, zwłaszcza:
- koszyk;
- proces składania zamówienia;
- konto klienta;
- historię zakupów;
- strony zawierające dane sesyjne;
- spersonalizowane ceny i rabaty;
- formularze z indywidualnymi tokenami bezpieczeństwa.
Nieprawidłowe buforowanie stron dynamicznych może prowadzić do problemów z logowaniem, sesjami, aktualizacją koszyka, a nawet do wyświetlenia użytkownikowi danych przeznaczonych dla innej osoby. Dlatego należy precyzyjnie ustalić, które zasoby mogą być przechowywane w cache, i unikać bezwarunkowego buforowania dynamicznego HTML.
CDN przejmuje obsługę statycznych plików i dostarcza je z rozproszonych lokalizacji. Może to dotyczyć obrazów produktów, arkuszy CSS, plików JavaScript, fontów czy materiałów do pobrania. Zmniejsza się dzięki temu liczba żądań kierowanych bezpośrednio do hostingu, a serwer źródłowy może przeznaczyć większą część zasobów na koszyk, zamówienia i płatności.
Samo uruchomienie CDN nie wystarczy. Należy sprawdzić:
- współczynnik trafień do pamięci podręcznej;
- czas przechowywania poszczególnych zasobów;
- zasady unieważniania cache po zmianie ceny lub stanu magazynowego;
- sposób obsługi parametrów w adresach;
- kompresję i rozmiar obrazów;
- liczbę skryptów pobieranych z zewnętrznych serwisów;
- poprawność działania wersji mobilnej i personalizacji.
Dobrze skonfigurowany cache powinien przyspieszać sklep bez ryzyka prezentowania nieaktualnych cen, błędnych stanów produktów lub danych pochodzących z cudzej sesji.
Jak monitorować działanie sklepu podczas największego natężenia ruchu?
Monitoring jest potrzebny przed kampanią, w jej trakcie i po zakończeniu. Bez niego trudno ustalić, czy sklep wykorzystuje dostępne zasoby, czy pojawiają się kolejki oraz w którym miejscu rozpoczyna się spadek wydajności.
Podstawą są cztery grupy sygnałów: opóźnienie, natężenie ruchu, liczba błędów i nasycenie zasobów.
Monitoring infrastruktury powinien obejmować:
- wykorzystanie CPU i pamięci RAM;
- obciążenie oraz opóźnienie dysku;
- liczbę aktywnych procesów;
- liczbę połączeń z bazą danych;
- długość kolejek;
- wolne miejsce na dysku;
- czas wykonywania zapytań;
- kody odpowiedzi HTTP;
- liczbę odrzuconych lub przerwanych żądań.
Równolegle trzeba obserwować proces zakupowy. Spadek liczby zamówień przy niezmienionym ruchu może oznaczać błąd koszyka, płatności albo integracji, nawet jeśli serwer nadal odpowiada kodem 200. Warto monitorować liczbę rozpoczętych i zakończonych płatności, błędy formularzy, porzucone koszyki, opóźnienia webhooków oraz kolejki synchronizacji.
Przydatny jest także monitoring syntetyczny, który regularnie wykonuje testowe przejście przez najważniejsze elementy sklepu. Sprawdzanie serwisu z kilku lokalizacji pozwala odróżnić problem globalny od awarii pojedynczego operatora, regionu lub węzła CDN.
Alerty powinny być ustawione z odpowiednim wyprzedzeniem. Powiadomienie wysłane dopiero po całkowitym wyczerpaniu zasobów daje niewiele czasu na reakcję. Lepszym rozwiązaniem są progi ostrzegawcze oraz krytyczne, powiązane z przygotowaną procedurą postępowania.
W okresie kampanii warto mieć ustalone:
- osoby odpowiedzialne za decyzje techniczne;
- kontakty do operatorów płatności i pozostałych integracji;
- sposób eskalacji problemu;
- plan czasowego ograniczenia mniej istotnych funkcji;
- procedurę zwiększenia zasobów;
- sposób przywracania danych i konfiguracji;
- kanał komunikacji pomiędzy zespołem technicznym, sprzedażą i obsługą klienta.
Jeżeli sklep działa na infrastrukturze umożliwiającej skalowanie, zasoby można zwiększać pionowo lub poziomo. Skalowanie pionowe oznacza rozbudowę pojedynczej maszyny, na przykład o dodatkowe rdzenie i pamięć. Skalowanie poziome polega na uruchamianiu kolejnych instancji za mechanizmem równoważenia ruchu. Automatyczne skalowanie może działać według harmonogramu albo reagować na ustalone metryki i stan usług.
Architektura wieloserwerowa wymaga jednak odpowiedniego przygotowania aplikacji. Sesje, pliki, kolejki i dane klientów nie mogą być zapisane wyłącznie lokalnie na jednej instancji. Dlatego sposób skalowania należy zaplanować wcześniej, a nie dopiero wtedy, gdy sklep przestanie odpowiadać.
W Rapid DC przygotowanie hostingu do kampanii rozpoczynamy od realnego profilu obciążenia sklepu. Analizujemy wymagania aplikacji, bazę danych, charakter ruchu oraz możliwość dalszego zwiększania zasobów. Takie podejście pozwala dobrać rozwiązanie, które nie tylko działa podczas spokojniejszych miesięcy, ale jest również gotowe na momenty mające największe znaczenie dla sprzedaży.