Apache vs Nginx dla PrestaShop: Który serwer WWW zapewnia lepszą wydajność

Dlaczego wybór serwera WWW ma znaczenie dla PrestaShop

PrestaShop to aplikacja PHP, która dynamicznie generuje strony HTML, serwuje zasoby statyczne takie jak obrazy, pliki CSS i JavaScript oraz obsługuje zapytania AJAX zarówno z front office, jak i back office. Serwer WWW znajduje się pomiędzy odwiedzającymi a aplikacją PHP, obsługując każde pojedyncze zapytanie HTTP. Jego architektura bezpośrednio wpływa na liczbę jednoczesnych odwiedzających, jaką sklep może obsłużyć, na szybkość ładowania stron oraz na ilość pamięci serwera zużywanej przez każdego odwiedzającego.

Apache i Nginx to dwa dominujące serwery WWW do hostowania PrestaShop. Apache jest domyślnym wyborem od najwcześniejszych wersji PrestaShop, a sam PrestaShop jest dostarczany z plikami .htaccess zaprojektowanymi specjalnie dla Apache. Nginx zyskał ogromną popularność w ciągu ostatniej dekady dzięki lepszej obsłudze jednoczesnych połączeń i mniejszemu zużyciu pamięci. Oba serwery mogą skutecznie obsługiwać PrestaShop, ale różnią się w aspektach, które mają znaczenie dla wydajności sklepu, złożoności konfiguracji oraz kosztów operacyjnych.

Architektura: Model procesowy vs pętla zdarzeń

Fundamentalna różnica między Apache a Nginx polega na sposobie obsługi przychodzących połączeń. Ta architektoniczna różnica jest źródłem wszystkich różnic wydajnościowych między tymi dwoma serwerami.

Model procesowy/wątkowy Apache

Apache tradycyjnie wykorzystuje model oparty na procesach za pośrednictwem modułu prefork MPM (Multi-Processing Module). W tym modelu Apache uruchamia pulę procesów roboczych, a każdy proces obsługuje jedno zapytanie naraz. Gdy przychodzi zapytanie, przypisywany jest do niego jeden proces. Ten proces odczytuje zapytanie, wykonuje kod PHP (przy użyciu mod_php), wysyła odpowiedź i dopiero wtedy staje się dostępny dla następnego zapytania.

Moduł worker MPM używa wątków zamiast oddzielnych procesów, co pozwala na więcej jednoczesnych połączeń przy mniejszym zużyciu pamięci. Moduł event MPM idzie jeszcze dalej, stosując podejście oparte na zdarzeniach dla połączeń keepalive, jednocześnie nadal używając wątków do aktywnego przetwarzania zapytań. Nowoczesne instalacje Apache zazwyczaj używają event MPM, ale podstawowy model wciąż polega na dedykowaniu wątku do każdego aktywnego zapytania.

Praktyczne konsekwencje są takie, że współbieżność Apache jest ograniczona liczbą skonfigurowanych wątków lub procesów roboczych. Jeśli skonfigurujesz 150 workerów i jednocześnie nadejdzie 151 zapytań, ostatnie zapytanie czeka w kolejce. Każdy worker zużywa pamięć (zazwyczaj 10-30 MB na proces z mod_php, mniej z PHP-FPM), więc maksymalna liczba workerów jest ograniczona dostępną pamięcią RAM.

Model sterowany zdarzeniami w Nginx

Nginx wykorzystuje asynchroniczną architekturę sterowaną zdarzeniami. Niewielka liczba procesów roboczych (zazwyczaj jeden na rdzeń procesora) obsługuje tysiące połączeń jednocześnie za pomocą pętli zdarzeń. Gdy przychodzi zapytanie, Nginx przetwarza je w sposób nieblokujący. Jeśli Nginx musi czekać na coś (odpowiedź z PHP-FPM, odczyt pliku z dysku, odpowiedź z serwera backendowego), nie blokuje workera. Zamiast tego przechodzi do obsługi innych połączeń i wraca, gdy oczekiwana operacja się zakończy.

Oznacza to, że proces roboczy Nginx obsługujący 1000 jednoczesnych połączeń zużywa mniej więcej tyle samo pamięci, co przy obsłudze 10 połączeń. Zużycie pamięci jest determinowane przez liczbę procesów roboczych (garstka), a nie liczbę połączeń (potencjalnie tysiące). Dlatego Nginx doskonale radzi sobie przy wysokiej współbieżności i jest preferowanym wyborem dla witryn o dużym ruchu.

.htaccess vs konfiguracja serwera

Jedną z najistotniejszych praktycznych różnic między Apache a Nginx jest sposób obsługi przepisywania adresów URL, kontroli dostępu i innych konfiguracji per-katalog.

Apache i .htaccess

Apache obsługuje pliki .htaccess, czyli pliki konfiguracyjne przypisane do katalogów, które mogą nadpisywać ustawienia ogólnoserwerowe. PrestaShop w dużym stopniu polega na .htaccess w zakresie przepisywania przyjaznych adresów URL, kontroli dostępu, nagłówków cachowania i nagłówków bezpieczeństwa. Gdy włączysz przyjazne adresy URL w PrestaShop, generuje on plik .htaccess z regułami mod_rewrite, które tłumaczą czyste adresy URL jak /shoes/running-shoe na wewnętrzny adres URL dispatchera.

Zaletą .htaccess jest wygoda. Nie potrzebujesz dostępu root, aby modyfikować zachowanie serwera WWW, a zmiany zaczynają obowiązywać natychmiast bez restartowania serwera. PrestaShop może zapisywać własny plik .htaccess z poziomu back office, co oznacza, że funkcje takie jak przyjazne adresy URL, konfiguracja serwera mediów i pewne ustawienia bezpieczeństwa działają od razu po instalacji.

Wadą jest wydajność. Każde zapytanie powoduje, że Apache szuka i parsuje pliki .htaccess w każdym katalogu od katalogu głównego dokumentu do katalogu żądanego pliku. Przy typowym zapytaniu PrestaShop, Apache może sprawdzać .htaccess w /, /var, /var/www, /var/www/html i dalszych katalogach. To dodaje operacje dyskowe I/O i czas przetwarzania do każdego zapytania. Dla witryny obsługującej setki zapytań na sekundę, ten narzut jest mierzalny.

Jeśli masz dostęp root do konfiguracji Apache, możesz przenieść wszystkie dyrektywy .htaccess do konfiguracji VirtualHost i wyłączyć przetwarzanie .htaccess za pomocą AllowOverride None. To eliminuje narzut per-zapytanie przy zachowaniu tej samej funkcjonalności. Jednak wtedy zmiany wymagają przeładowania Apache.

Konfiguracja Nginx

Nginx nie obsługuje plików .htaccess. Cała konfiguracja znajduje się w plikach konfiguracyjnych bloków server, zazwyczaj w /etc/nginx/sites-available/ lub /etc/nginx/conf.d/. Każda reguła przepisywania URL, dyrektywa kontroli dostępu i nagłówek cachowania muszą być zdefiniowane w tych plikach.

Oznacza to, że przy konfiguracji PrestaShop na Nginx musisz ręcznie przetłumaczyć reguły .htaccess PrestaShop na składnię konfiguracji Nginx. Reguły przepisywania są zasadniczo różne między tymi dwoma serwerami. Apache używa RewriteRule z wzorcami regex i flagami takimi jak [L,R=301], podczas gdy Nginx używa bloków location z dyrektywami try_files, rewrite i return.

Zaletą scentralizowanej konfiguracji jest wydajność (brak skanowania plików per-zapytanie) i przejrzystość (wszystkie reguły w jednym miejscu). Wadą jest to, że PrestaShop nie może wygenerować konfiguracji Nginx za Ciebie. Musisz ją napisać i utrzymywać samodzielnie, a każda zmiana wymaga uruchomienia nginx -t w celu przetestowania składni i systemctl reload nginx w celu jej zastosowania.

Integracja PHP

Oba serwery WWW muszą wykonywać kod PHP, aby generować strony PrestaShop. Metoda integracji PHP wpływa na wydajność, stabilność i zarządzanie zasobami.

Apache z mod_php

Tradycyjne podejście to Apache z mod_php, gdzie PHP działa jako moduł wewnątrz każdego procesu Apache. Jest to proste w konfiguracji i nie ma narzutu komunikacji międzyprocesowej, ponieważ PHP wykonuje się w tym samym procesie, który obsługuje zapytanie HTTP. Jednak każdy proces roboczy Apache niesie w pamięci pełne środowisko uruchomieniowe PHP, nawet gdy serwuje pliki statyczne jak obrazy czy CSS. To marnuje pamięć, ponieważ większość zapytań do sklepu PrestaShop dotyczy zasobów statycznych, a nie stron PHP.

Apache lub Nginx z PHP-FPM

PHP-FPM (FastCGI Process Manager) uruchamia PHP jako oddzielną pulę procesów. Serwer WWW komunikuje się z PHP-FPM przez gniazdo Unix lub połączenie TCP za pomocą protokołu FastCGI. Gdy zapytanie wymaga przetworzenia PHP, serwer WWW przekazuje je do PHP-FPM. Gdy przetwarzanie PHP jest zakończone, PHP-FPM odsyła wynik z powrotem do serwera WWW, który wysyła go do klienta.

Z PHP-FPM procesy serwera WWW obsługujące pliki statyczne nie niosą środowiska uruchomieniowego PHP, co oszczędza znaczną ilość pamięci. PHP-FPM oferuje również własne zarządzanie procesami z funkcjami takimi jak dynamiczne skalowanie puli, slow log (logowanie zapytań trwających dłużej niż próg) oraz możliwość jednoczesnego uruchamiania wielu wersji PHP dla różnych witryn.

Nginx używa wyłącznie PHP-FPM, ponieważ jego architektura sterowana zdarzeniami jest niekompatybilna z osadzaniem PHP. Apache może używać PHP-FPM przez mod_proxy_fcgi. We współczesnych wdrożeniach PHP-FPM jest zalecanym podejściem dla obu serwerów.

Konfiguracja PHP-FPM dla PrestaShop

Niezależnie od wybranego serwera WWW, konfiguracja PHP-FPM znacząco wpływa na wydajność PrestaShop. Kluczowe ustawienia to:

pm = dynamic jest zazwyczaj najlepszym trybem menedżera procesów. Uruchamia bazową liczbę workerów i tworzy więcej pod obciążeniem, do skonfigurowanego maksimum. To balansuje zużycie pamięci i responsywność.

pm.max_children określa maksymalną liczbę procesów PHP. Każde zapytanie PrestaShop zazwyczaj zużywa 30-80 MB pamięci, więc podziel dostępną pamięć RAM (minus to, co potrzebują serwer WWW i system operacyjny) przez 80, aby uzyskać konserwatywne maksimum. Dla serwera z 4 GB użytecznej pamięci RAM, 50 procesów potomnych jest rozsądnym punktem wyjścia.

pm.max_requests = 500 recykluje każdego workera po 500 zapytaniach, zapobiegając akumulacji wycieków pamięci. Moduły PrestaShop czasami mają drobne wycieki pamięci, a to ustawienie zapobiega ich narastaniu do problemowego poziomu.

Serwowanie plików statycznych

Sklep PrestaShop serwuje dużą liczbę plików statycznych: obrazy produktów, arkusze stylów CSS, pliki JavaScript, czcionki i przesłane media. Wydajność serwowania plików statycznych bezpośrednio wpływa na czas ładowania stron i zużycie zasobów serwera.

Wydajność serwowania plików statycznych przez Apache

Apache serwuje pliki statyczne przez swoje procesy robocze. Każde zapytanie o plik statyczny zajmuje workera na czas trwania transferu. Dla małych plików (CSS, JS, małe obrazy) jest to szybkie. Dla dużych plików lub wolnych połączeń klienckich worker jest zajęty dłużej. Z załadowanym mod_php, każdy worker niesie niepotrzebny narzut pamięciowy PHP nawet dla zapytań statycznych.

Apache obsługuje sendfile, co pozwala jądru systemu na bezpośredni transfer plików z dysku do gniazda sieciowego bez kopiowania danych przez przestrzeń użytkownika. Jest to domyślnie włączone i pomaga przy transferze dużych plików. Apache obsługuje również negocjację treści, zakresy bajtów i zapytania warunkowe (If-Modified-Since) od razu po instalacji.

Wydajność serwowania plików statycznych przez Nginx

Nginx doskonale radzi sobie z serwowaniem plików statycznych, ponieważ jego model sterowany zdarzeniami może obsługiwać tysiące jednoczesnych transferów plików bez proporcjonalnego zwiększania zużycia zasobów. Pojedynczy proces roboczy Nginx może serwować setki jednoczesnych zapytań o pliki statyczne. W połączeniu z efektywnym wykorzystaniem wywołania systemowego sendfile i wbudowaną obsługą cache otwartych plików (cachowanie deskryptorów plików dla często odwiedzanych plików), serwowanie plików statycznych jest niezwykle szybkie.

Dla sklepów PrestaShop z wieloma obrazami produktów (czyli większości sklepów), przewaga Nginx w serwowaniu plików statycznych jest znacząca. Strony produktów z 5-10 obrazami, plus pliki CSS, JavaScript i czcionek, generują 20-30 zapytań o pliki statyczne na jedno załadowanie strony. Przy dużym ruchu Nginx obsługuje je przy znacznie mniejszym zużyciu zasobów niż Apache.

Terminacja SSL/TLS

Każdy sklep PrestaShop powinien działać na HTTPS, a serwer WWW obsługuje szyfrowanie i deszyfrowanie SSL/TLS (terminację). Oba serwery dobrze obsługują nowoczesny TLS, ale istnieją różnice w konfiguracji i wydajności.

Apache konfiguruje SSL przez mod_ssl, z dyrektywami takimi jak SSLEngine on, SSLCertificateFile i SSLProtocol w bloku VirtualHost. Zszywanie OCSP, cachowanie sesji i wybór zestawu szyfrów są w pełni konfigurowalne.

Nginx konfiguruje SSL w bloku server z dyrektywami takimi jak ssl_certificate, ssl_protocols i ssl_ciphers. Nginx również obsługuje zszywanie OCSP i cachowanie sesji, a jego konfiguracja jest zazwyczaj bardziej zwięzła.

Pod względem wydajności, handshake TLS jest wymagający obliczeniowo ze względu na asymetryczne szyfrowanie. Zdolność Nginx do obsługi wielu jednoczesnych połączeń przy niewielkiej liczbie procesów roboczych oznacza, że może obsłużyć więcej handshake'ów TLS na sekundę przy mniejszym zużyciu pamięci. Dla sklepów, które otrzymują duże fale nowych odwiedzających (podczas wyprzedaży na przykład), przewaga wydajnościowa Nginx w zakresie TLS może zapobiec kolejkowaniu połączeń.

Reverse proxy i load balancing

Dla sklepów PrestaShop o dużym ruchu, architektura reverse proxy rozdziela odpowiedzialności i poprawia skalowalność. Najczęstsza konfiguracja wykorzystuje Nginx jako reverse proxy przed Apache lub inną instancją Nginx z PHP-FPM.

Nginx jako reverse proxy dla Apache

Ta hybrydowa konfiguracja łączy zalety obu serwerów. Nginx stoi z przodu, obsługując wszystkie przychodzące połączenia, serwując pliki statyczne bezpośrednio, zarządzając terminacją SSL i przekazując tylko zapytania PHP do Apache. Apache obsługuje przetwarzanie PHP, a ponieważ otrzymuje tylko zapytania PHP (nie zapytania o pliki statyczne), potrzebuje znacznie mniejszej liczby procesów roboczych.

Ta architektura daje efektywność obsługi połączeń Nginx i wydajność serwowania plików statycznych przy jednoczesnym zachowaniu obsługi .htaccess Apache dla generowanych reguł przepisywania PrestaShop. Jest to powszechna ścieżka migracji dla sklepów, które chcą wydajności Nginx bez przepisywania całej konfiguracji Apache.

Konfiguracja proxy Nginx używa dyrektywy proxy_pass do przekazywania zapytań do Apache, który zazwyczaj działa na niestandardowym porcie jak 8080. Pliki statyczne są serwowane bezpośrednio przez Nginx za pomocą bloku location dopasowującego rozszerzenia plików takie jak .jpg, .css, .js i .png.

Pełna konfiguracja Nginx

Dla maksymalnej wydajności Nginx serwuje wszystko: pliki statyczne i zapytania PHP (przez PHP-FPM). W stosie nie ma Apache. To eliminuje komunikację międzyprocesową między Nginx a Apache i usuwa narzut pamięciowy uruchamiania dwóch serwerów WWW. Wymaga jednak ręcznego tworzenia i utrzymywania konfiguracji Nginx dla przepisywania adresów URL PrestaShop, co wymaga więcej początkowej pracy.

Zalecana konfiguracja Nginx dla PrestaShop

Produkcyjna konfiguracja Nginx dla PrestaShop musi obsługiwać przyjazne adresy URL, dostęp do panelu administracyjnego, cachowanie plików statycznych, komunikację z PHP-FPM i bezpieczeństwo. Kluczowe elementy obejmują blok server nasłuchujący na portach 80 i 443, blok konfiguracji SSL z certyfikatami, dyrektywę root wskazującą na instalację PrestaShop oraz kilka bloków location.

Główny blok location używa try_files $uri $uri/ /index.php?$args do obsługi przyjaznych adresów URL PrestaShop. Najpierw próbuje obsłużyć zapytanie jako plik statyczny, potem jako katalog, a na końcu przekazuje je do dispatchera PrestaShop przez index.php.

Blok location dopasowujący ~ \.php$ przekazuje zapytania PHP do PHP-FPM za pomocą fastcgi_pass. Zawiera standardowe parametry FastCGI i ustawia SCRIPT_FILENAME na prawidłową ścieżkę.

Blok location dla zasobów statycznych ustawia długie nagłówki wygaśnięcia cache i wyłącza logowanie dostępu w celu zmniejszenia I/O. Wzorce dopasowujące takie jak \.(jpg|jpeg|gif|png|svg|css|js|ico|woff|woff2|ttf|eot)$ przechwytują typowe typy plików statycznych.

Bloki location związane z bezpieczeństwem blokują dostęp do wrażliwych plików i katalogów: .htaccess, .git, config/ (oprócz config/xml/, który jest potrzebny PrestaShop), vendor/, app/config/ i innych katalogów, które nigdy nie powinny być dostępne przez WWW.

Zalecana konfiguracja Apache dla PrestaShop

Apache z event MPM i PHP-FPM zapewnia najlepszy hosting PrestaShop oparty na Apache. Konfiguracja VirtualHost powinna włączać moduły rewrite, headers, expires, deflate i proxy_fcgi.

DocumentRoot wskazuje na instalację PrestaShop. AllowOverride All włącza przetwarzanie .htaccess, które jest potrzebne, chyba że przeniesiesz wszystkie reguły przepisywania PrestaShop do konfiguracji VirtualHost.

Integracja PHP-FPM używa SetHandler lub ProxyPassMatch do przekazywania zapytań .php do gniazda PHP-FPM. Podejście SetHandler z proxy:unix:/run/php/php-fpm.sock|fcgi://localhost jest prostsze i zalecane dla większości konfiguracji.

Włącz kompresję gzip za pomocą mod_deflate dla typów treści tekstowych: HTML, CSS, JavaScript, JSON, XML i SVG. Włącz cachowanie przeglądarki za pomocą mod_expires, ustawiając długie czasy wygaśnięcia dla zasobów statycznych i krótsze dla HTML.

Benchmarki wydajności i różnice w rzeczywistych warunkach

Surowe wyniki benchmarków różnią się ogromnie w zależności od sprzętu, konfiguracji, wersji PHP i wersji PrestaShop. Zamiast prezentować konkretne liczby, które byłyby mylące poza kontekstem, oto wzorce, które konsekwentnie pojawiają się w benchmarkach hostingu PrestaShop.

Dla serwowania plików statycznych, Nginx jest konsekwentnie 2-3 razy szybszy niż Apache i zużywa znacznie mniej pamięci. Ta różnica powiększa się wraz ze wzrostem współbieżności. Przy 100 jednoczesnych połączeniach różnica może wynosić 20%. Przy 1000 jednoczesnych połączeniach Nginx może zużywać 10 razy mniej pamięci.

Dla przetwarzania zapytań PHP, serwer WWW nie jest wąskim gardłem. Czas przetwarzania PHP-FPM dominuje w cyklu życia zapytania, a oba serwery WWW dodają pomijalny narzut w porównaniu z czasem, jaki PHP spędza na wykonywaniu kodu PrestaShop, odpytywaniu bazy danych i renderowaniu szablonów. Różnica w obsłudze zapytań PHP między Apache z PHP-FPM a Nginx z PHP-FPM wynosi zazwyczaj poniżej 5%, co mieści się w marginesie błędu pomiarowego dla większości sklepów.

Dla obciążeń mieszanych (realistyczny scenariusz), przewaga Nginx wynika z efektywnej obsługi plików statycznych obok zapytań PHP. Załadowanie strony generuje jedno zapytanie PHP i 20-30 zapytań o pliki statyczne. Nginx obsługuje te 20-30 zapytań statycznych z minimalnym zużyciem zasobów, podczas gdy Apache przydziela wątek roboczy do każdego z nich. Przy dużym ruchu ta różnica w zużyciu zasobów oznacza, że Nginx może utrzymać wyższą współbieżność zanim wydajność zacznie spadać.

Praktyczny wniosek jest taki, że dla sklepów z mniej niż 50 jednoczesnych odwiedzających, wybór serwera WWW nie robi prawie żadnej zauważalnej różnicy. Dla sklepów zbliżających się do lub przekraczających 100 jednoczesnych odwiedzających, architektoniczne zalety Nginx stają się istotne.

Przewodnik migracji: Apache do Nginx

Migracja istniejącego sklepu PrestaShop z Apache na Nginx obejmuje tłumaczenie konfiguracji, dokładne testowanie i przełączenie.

Krok 1: Przetłumacz reguły .htaccess

Otwórz plik .htaccess PrestaShop i zidentyfikuj wszystkie aktywne reguły przepisywania. Kluczowa sekcja to przepisywanie przyjaznych adresów URL, które zazwyczaj zaczyna się od RewriteCond %{REQUEST_FILENAME} !-f i RewriteRule .* - [E=REWRITEBASE:/]. Te reguły tłumaczą się na dyrektywę try_files Nginx wspomnianą w sekcji konfiguracji powyżej.

Przepisywania serwera mediów, obsługa prefiksu języka i wszelkie niestandardowe przekierowania również wymagają tłumaczenia. Każda para RewriteRule i RewriteCond Apache musi zostać skonwertowana na odpowiednią dyrektywę location, rewrite lub return Nginx.

Krok 2: Skonfiguruj Nginx obok Apache

Zainstaluj Nginx i skonfiguruj go do nasłuchiwania na innym porcie (np. 8080), podczas gdy Apache nadal działa na porcie 80. To pozwala przetestować konfigurację Nginx bez wpływu na działającą witrynę. Skieruj Nginx na ten sam katalog główny dokumentów co Apache, aby serwował te same pliki.

Krok 3: Przetestuj wszystko

Uzyskaj dostęp do witryny przez port Nginx i przetestuj każdy aspekt: stronę główną, strony kategorii, strony produktów, koszyk, proces zamówienia, panel administracyjny, przyjazne adresy URL, ładowanie obrazów i wielojęzyczne routowanie URL. Zwróć szczególną uwagę na wzorce URL zawierające znaki specjalne lub parametry zapytania.

Krok 4: Przełącz się

Po zakończeniu testów zatrzymaj Apache i przekonfiguruj Nginx do nasłuchiwania na portach 80 i 443. Przeładuj Nginx i sprawdź, czy witryna produkcyjna działa poprawnie. Zachowaj konfigurację Apache przez kilka dni na wypadek konieczności cofnięcia zmian.

Typowe problemy przy migracji

Najczęstszym problemem są brakujące reguły przepisywania dla wielojęzycznego routowania URL PrestaShop. Jeśli Twój sklep używa wielu języków z kodami języka w adresie URL (jak /en/, /de/, /fr/), upewnij się, że konfiguracja Nginx prawidłowo obsługuje te prefiksy.

Innym częstym problemem są limity rozmiaru przesyłanych plików. Apache używa LimitRequestBody, podczas gdy Nginx używa client_max_body_size. Jeśli importujesz produkty z dużymi obrazami, ustaw client_max_body_size na co najmniej 20M.

Zapytania AJAX panelu administracyjnego, które polegają na przepisywaniu .htaccess, mogą przestać działać, jeśli odpowiednie reguły Nginx nie zostały dodane. Przetestuj panel administracyjny dokładnie, w tym edycję produktów, zarządzanie zamówieniami i konfigurację modułów.

Który serwer powinieneś wybrać

Wybierz Apache, jeśli korzystasz z hostingu współdzielonego, na którym nie kontrolujesz serwera WWW, jeśli w dużym stopniu polegasz na .htaccess w konfiguracji (reguły generowane przez moduły, wtyczki bezpieczeństwa) lub jeśli nie czujesz się komfortowo z pisaniem i utrzymywaniem plików konfiguracyjnych Nginx. Apache z event MPM i PHP-FPM to solidna, dobrze wspierana konfiguracja dla sklepów PrestaShop o umiarkowanym ruchu.

Wybierz Nginx, jeśli masz dostęp root do serwera, Twój sklep obsługuje znaczny ruch (setki lub tysiące jednoczesnych odwiedzających), chcesz jak najniższego zużycia zasobów dla danego poziomu ruchu lub konfigurujesz nowy serwer i preferujesz długoterminowe korzyści architektury Nginx. Początkowy wysiłek konfiguracyjny jest jednorazowym kosztem, który zwraca się w postaci wydajności i efektywności zasobów.

Wybierz podejście z Nginx jako reverse proxy przed Apache, jeśli chcesz wydajności Nginx dla plików statycznych i obsługi połączeń, ale potrzebujesz obsługi .htaccess Apache dla kompatybilności z modułami PrestaShop, które generują lub zależą od reguł .htaccess.

Dla większości nowych instalacji PrestaShop na VPS lub serwerze dedykowanym, Nginx z PHP-FPM jest zalecanym wyborem. Konfiguracja jest dobrze udokumentowana, zalety wydajnościowe są realne, a operacyjna prostota jednego stosu serwera WWW zmniejsza koszty utrzymania. Dla istniejących sklepów na Apache, które działają zadowalająco, migracja na Nginx jest wartościową optymalizacją, ale nie pilną koniecznością, chyba że napotykasz limity wydajności.