Magento 2.4 ma konkretne wymagania techniczne — bez ich spełnienia sklep nie wystartuje albo będzie działał znacznie poniżej możliwości. Problem w tym, że oficjalna lista mówi, czego potrzeba, żeby sklep się uruchomił, a nie żeby sprzedawał. Przechodzimy przez stack element po elemencie, z perspektywy środowisk produkcyjnych, które utrzymujemy na co dzień.
PHP 8.3+ z OPcache — fundament
Magento 2.4.7+ wymaga PHP 8.3 lub 8.4 (PHP-FPM) z rozszerzeniami m.in. intl, soap, bcmath, gd. To, co robi różnicę na produkcji, to nie sama wersja, tylko konfiguracja OPcache: za mały bufor oznacza, że Magento — jedna z największych baz kodu PHP w ogóle — kompiluje się w kółko od nowa. Objaw: wolny sklep mimo mocnego CPU.
Baza danych — MySQL 8.0/8.4 lub MariaDB 10.11+
Kluczowy parametr to innodb_buffer_pool_size dobrany do rozmiaru katalogu. Zbyt mały bufor sprawia, że baza czyta z dysku to, co powinna mieć w pamięci — a strony kategorii w Magento potrafią generować dziesiątki zapytań każda. Na produkcji baza powinna też mieszkać na osobnej maszynie lub wolumenie — o tym niżej.
OpenSearch / Elasticsearch — bez tego nie ma katalogu
Od Magento 2.4 wyszukiwarka jest wymagana — katalog bez niej po prostu nie działa. Rekomendujemy OpenSearch 2.x. Dwie rzeczy, które trzeba dostroić: pamięć JVM (połowa dostępnego RAM-u instancji, nie więcej niż ~30 GB) i liczba shardów adekwatna do rozmiaru katalogu. Objaw złej konfiguracji: filtrowanie kategorii muli, choć reszta sklepu działa.
Redis + Varnish — duet, który robi szybkość
Redis obsługuje cache aplikacji i sesje — przenosi je z dysku do pamięci. Varnish jako full-page cache serwuje gotowe strony bez dotykania PHP w ogóle; na produkcji uznajemy go za obowiązkowy, nie „zalecany”. Poprawnie skonfigurowany duet oznacza, że 90%+ ruchu anonimowego nigdy nie dociera do aplikacji.
Pułapka, o której mało kto mówi: nawigacja warstwowa i boty. Kombinacje filtrów generują adresy spoza cache — agresywny crawler potrafi zdjąć skuteczność FPC do zera. Ochrona przed botami to element wydajności, nie tylko bezpieczeństwa.
RabbitMQ — opcjonalny, ale odciąża
Kolejki przetwarzają operacje asynchronicznie: masowe aktualizacje produktów, integracje, eksporty. Bez nich wszystko dzieje się „na żywo” w procesach obsługujących ruch klientów. Przy większej liczbie operacji katalogowych RabbitMQ to różnica między „import w tle” a „sklep klęka podczas importu”.
RAM — 2 GB to instalacja, nie produkcja
Oficjalne minimum (2 GB) wystarcza do postawienia sklepu deweloperskiego. Produkcyjny sklep z realnym katalogiem potrzebuje od 8 GB wzwyż — bo PHP-FPM, baza, OpenSearch i Redis konkurują o pamięć. I tu dochodzimy do najważniejszej decyzji architektonicznej.
Dlaczego oddzielamy bazę od aplikacji
W instalacji „wszystko na jednym serwerze” cięższa reindeksacja katalogu albo skok ruchu sprawia, że baza zabiera pamięć aplikacji — sklep zwalnia, chociaż na papierze serwer ma zapas. Rozdzielenie warstw daje każdej z nich zasoby na wyłączność i konfigurację pod jej rolę, a do tego: bazę w sieci prywatnej bez publicznego adresu, niezależne skalowanie (aplikacja pod ruch, baza pod katalog) i backupy, które nie konkurują z produkcją.
Podsumowanie: minimalne ≠ produkcyjne
| Element | Minimum „żeby działało” | Produkcja „żeby sprzedawało” |
|---|---|---|
| PHP | 8.3 z wymaganymi rozszerzeniami | + OPcache dostrojony do rozmiaru kodu |
| Baza | MySQL 8.0 | + bufory pod katalog, osobna warstwa |
| Wyszukiwarka | OpenSearch 2.x | + JVM i shardy pod rozmiar katalogu |
| Cache | Redis | + Varnish jako FPC + ochrona przed botami |
| Kolejki | — | RabbitMQ przy większym katalogu |
| RAM | 2 GB | 8 GB+ z separacją warstw |
Konfigurację zawsze przeliczamy na realny katalog, ruch i integracje konkretnego sklepu — dlatego zanim zaproponujemy środowisko, pytamy o liczby, nie o budżet. Jeśli Twój sklep działa „na minimalnych wymaganiach” i czujesz, że go to ogranicza — porozmawiajmy.