Duży ruch to szansa dla sprzedaży i wyzwanie dla infrastruktury. Większość problemów ze stabilnością sklepów podczas kampanii ma te same przyczyny. Są przewidywalne i można im zapobiec przed sezonem.
Baza danych jako wąskie gardło
W PrestaShop pod dużym ruchem baza danych jest zwykle pierwszym miejscem przeciążającym się. Każde żądanie strony generuje dziesiątki zapytań SQL. Bez warstwy cache obiektowego te zapytania trafiają do bazy przy każdym żądaniu. Przy kilkuset jednoczesnych użytkownikach baza zaczyna kolejkować zapytania i sklep spowalnia. Redis jako cache obiektowy PS to jeden z najważniejszych kroków przy przygotowaniu do wzmożonego ruchu.
Limit połączeń MySQL
MySQL ma limit jednoczesnych połączeń. Gdy jest osiągnięty, nowe żądania dostają błąd "Too many connections". Domyślna wartość jest za niska dla sklepów z dużym ruchem. Zwiększenie limitu i konfiguracja connection pooling to standard przy takich projektach.
PHP workers
Serwer PHP-FPM obsługuje określoną liczbę żądań jednocześnie przez pulę procesów roboczych. Gdy wszystkie są zajęte, nowe żądania czekają lub dostają błąd 502. Optymalna liczba procesów zależy od dostępnej pamięci RAM i czasu obsługi żądania. Wzór jest prosty: dostępny RAM podzielony przez RAM per proces równa się maksymalna liczba procesów.
Obsługa sesji
Domyślny mechanizm sesji PHP zapisuje pliki na dysku. Przy dużym ruchu to operacje dyskowe, które można wyeliminować przenosząc sesje do Redis lub Memcached. Poprawia to zarówno wydajność jak i możliwość skalowania poziomego przez kilka serwerów aplikacji ze wspólnym magazynem sesji.
Kolejki dla operacji asynchronicznych
Wysyłka e-maili, generowanie raportów, eksport danych - operacje, które nie muszą być wykonane synchronicznie, powinny trafiać do kolejki. Nie spowalniają wtedy checkoutu i nie blokują żądań użytkowników podczas wzmożonego ruchu.