Dlaczego infrastruktura ma takie znaczenie w PrestaShop
PrestaShop dobrze radzi sobie z małymi i średnimi sklepami — ale przy tysiącach produktów, dziesiątkach modułów i rosnącym ruchu zaczyna odsłaniać słabe punkty hostingu. Backoffice zwalnia, importy kończą się timeoutem, a MySQL blokuje się dokładnie wtedy, kiedy klienci kupują. Na współdzielonym serwerze te problemy pojawiają się wcześniej i bolą bardziej.
Dla klientów sklepu różnica jest odczuwalna od pierwszego kliknięcia. Szybki sklep sprzedaje lepiej — nikt nie czeka na wolno ładujące się strony produktów. Dobrze skonfigurowany cache i baza sprawiają, że katalog i koszyk odpowiadają bez opóźnień. Szybkość ładowania to również czynnik rankingowy w Google (Core Web Vitals) — dobra infrastruktura pracuje na widoczność sklepu w wynikach wyszukiwania.
Jest jeszcze druga strona: koszty i spokój. Stack dobrany do realnej skali sklepu kosztuje mniej niż przewymiarowany serwer trzymany „na zapas", a możliwość skalowania zasobów sprawia, że kampania reklamowa czy sezonowy szczyt przestają być loterią.
Minimalne wymagania PrestaShop 8
PrestaShop 8 ma konkretne wymagania techniczne. Bez ich spełnienia sklep nie wystartuje albo będzie działał znacznie poniżej możliwości:
| PHP | 8.1–8.3 (PHP-FPM) z rozszerzeniami m.in. intl, gd, zip, curl, soap — plus poprawnie ustawiony OPcache |
|---|---|
| Baza danych | MySQL 8.0+ lub MariaDB 10.6+ — z buforami dobranymi do rozmiaru katalogu i historii zamówień |
| Cache i sesje | Redis dla sesji i cache aplikacji; Varnish lub nginx cache jako full-page cache na produkcji |
| Pamięć PHP | memory_limit i max_input_vars pod realną liczbę modułów — zbyt niskie wartości to typowa przyczyna timeoutów w BO |
| Pamięć RAM | 2 GB to absolutne minimum do instalacji — produkcyjny sklep z dużym katalogiem potrzebuje realnie od 8 GB wzwyż |
„Minimalne" nie znaczy „produkcyjne". Konfiguracja, która wystarcza do uruchomienia PrestaShop, rzadko wystarcza do sprzedawania — dlatego wymagania zawsze przeliczamy na realny katalog, ruch i zestaw modułów konkretnego sklepu.
Dlaczego oddzielamy bazę danych od aplikacji
W typowej instalacji „wszystko na jednym serwerze" PHP-FPM i MySQL konkurują o te same zasoby. Wystarczy cięższy import produktów albo skok ruchu i baza zaczyna zabierać pamięć aplikacji — sklep zwalnia, chociaż na papierze serwer ma jeszcze zapas.
Dlatego w środowiskach produkcyjnych rozdzielamy warstwę bazodanową od aplikacyjnej. Każda z nich dostaje wtedy zasoby na wyłączność i konfigurację pod swoją rolę: MySQL własną pamięć na bufory i szybkie dyski, PHP-FPM własne CPU pod obsługę ruchu. Warstwy skalują się niezależnie — aplikację rozbudowujesz pod rosnący ruch, bazę pod rosnący katalog, bez przenoszenia całego sklepu.
To także kwestia bezpieczeństwa i utrzymania. Baza działa w sieci prywatnej, bez publicznego adresu — na zewnątrz wystawiony jest wyłącznie front sklepu. Deploy czy restart aplikacji nie dotyka bazy, a backupy i tuning prowadzone są osobno dla każdej warstwy.
Środowiska PrestaShop budujemy na AWS
Jako certyfikowany partner AWS uruchamiamy sklepy na infrastrukturze Amazon Web Services — w europejskich regionach, z pełną separacją środowisk klientów i danymi przechowywanymi na terenie Unii Europejskiej, zgodnie z wymaganiami RODO.
Dla sklepu PrestaShop oznacza to przede wszystkim elastyczność. Zasoby można zwiększyć przed kampanią i zmniejszyć po niej, zamiast utrzymywać przez cały rok serwer wymiarowany pod jeden szczyt sprzedaży. Baza danych i usługi wewnętrzne pracują w sieci prywatnej (VPC), a snapshoty dysków pozwalają szybko odtworzyć sklep po awarii — również do środowiska testowego, kiedy trzeba bezpiecznie sprawdzić większą zmianę lub migrację do PS 8.