Użytkownik otwierający stronę widzi jej układ, treści i zdjęcia, ale nie obserwuje procesów zachodzących po stronie infrastruktury. Tymczasem każde kliknięcie uruchamia komunikację między przeglądarką, serwerem WWW, aplikacją, bazą danych i pozostałymi elementami środowiska. To właśnie sprawność ich współpracy decyduje o tym, jak szybko pojawi się odpowiedź i czy witryna zachowa stabilność przy większym ruchu.
Apache, Nginx i LiteSpeed realizują podobne podstawowe zadanie, lecz różnią się architekturą, sposobem konfiguracji oraz obsługą wielu jednoczesnych połączeń. Nie oznacza to jednak, że jeden serwer zawsze będzie lepszy od pozostałych. Na rzeczywistą wydajność strony wpływa cały stos technologiczny: moc obliczeniowa hostingu, wersja PHP, baza danych, mechanizmy cache, kod aplikacji, wtyczki, sieć i konfiguracja zabezpieczeń.
Porównując dostępne rozwiązania, trzeba więc patrzeć nie tylko na wyniki ogólnych benchmarków, ale przede wszystkim na potrzeby konkretnej witryny.
Jak działa serwer WWW i za co odpowiada podczas wyświetlania strony?
Serwer WWW jest warstwą pośredniczącą między przeglądarką użytkownika a plikami lub aplikacją znajdującą się na hostingu. Odbiera żądanie HTTP albo HTTPS, analizuje jego parametry, a następnie przygotowuje odpowiedź.
W żądaniu znajdują się między innymi:
- nazwa domeny;
- adres konkretnego zasobu;
- metoda żądania, na przykład
GETlubPOST; - nagłówki przesyłane przez przeglądarkę;
- informacje o plikach cookie i sesji.
Na podstawie nazwy domeny serwer wybiera właściwy host wirtualny, czyli zestaw reguł przypisanych do danej strony. Następnie sprawdza ścieżkę, przekierowania, ograniczenia dostępu oraz sposób obsługi wskazanego zasobu.
Gdy użytkownik pobiera statyczny plik CSS, obraz albo dokument JavaScript, serwer może zwrócić go bez uruchamiania aplikacji. W przypadku treści dynamicznej żądanie zostaje przekazane do odpowiedniego środowiska, takiego jak PHP, Node.js, Python lub Java. Aplikacja może następnie pobrać dane z bazy, przetworzyć je i wygenerować odpowiedź.
Serwer WWW może odpowiadać również za:
- zakończenie szyfrowanego połączenia TLS;
- utrzymywanie otwartych połączeń;
- kompresję odpowiedzi;
- ustawianie nagłówków bezpieczeństwa;
- obsługę przekierowań;
- kontrolowanie dostępu do zasobów;
- buforowanie wybranych odpowiedzi;
- zapisywanie logów dostępu i błędów.
W przypadku WordPressa serwer przyjmuje żądanie i kieruje je do PHP. Kod systemu CMS oraz zainstalowanych wtyczek pobiera potrzebne dane z bazy, tworzy stronę, a następnie przekazuje gotową odpowiedź do użytkownika. Serwer organizuje więc komunikację i dostarcza wynik, lecz sam nie odpowiada za każdy etap generowania treści.
Apache, Nginx i LiteSpeed – czym różnią się pod względem działania?
Apache, Nginx i LiteSpeed mogą obsługiwać zarówno proste strony firmowe, jak i rozbudowane serwisy. Różnice dotyczą przede wszystkim modelu obsługi połączeń, dostępnych mechanizmów konfiguracji oraz sposobu integracji z aplikacjami.
Apache
Apache jest rozwijanym od wielu lat serwerem WWW, którego ważną zaletą pozostaje elastyczność. Administrator może włączać różne moduły oraz wybrać mechanizm MPM, czyli sposób zarządzania procesami i wątkami.
Do najważniejszych wariantów należą:
- prefork – wykorzystuje oddzielne procesy bez wątków;
- worker – łączy procesy z wieloma wątkami;
- event – został zaprojektowany tak, aby ograniczać zajmowanie workerów przez połączenia oczekujące na kolejne żądania.
Z tego powodu samo stwierdzenie, że Apache zużywa dużo pamięci, jest zbyt dużym uproszczeniem. Wydajność zależy między innymi od używanego MPM, liczby procesów, sposobu komunikacji z PHP i aktywnych modułów.
Istotną cechą Apache jest obsługa plików .htaccess. Pozwalają one definiować reguły na poziomie poszczególnych katalogów bez modyfikowania głównej konfiguracji serwera. Jest to wygodne na hostingu współdzielonym i w aplikacjach, które automatycznie zapisują przekierowania lub reguły przyjaznych adresów.
Nginx
Nginx wykorzystuje model master–worker oraz mechanizmy zdarzeniowe systemu operacyjnego. Jeden proces nadrzędny zarządza procesami roboczymi, które mogą obsługiwać wiele połączeń bez tworzenia osobnego procesu dla każdego użytkownika.
Taka architektura dobrze sprawdza się przy:
- dużej liczbie jednoczesnych połączeń;
- przesyłaniu plików statycznych;
- pracy jako reverse proxy;
- kończeniu połączeń TLS;
- rozdzielaniu ruchu między backendy;
- buforowaniu odpowiedzi aplikacji.
Nginx nie obsługuje plików .htaccess. Reguły przekierowań, blokad dostępu czy przyjaznych adresów zapisuje się w centralnej konfiguracji serwera. Zwiększa to kontrolę i może ograniczyć dodatkowe operacje wykonywane podczas każdego żądania, ale wymaga dostępu administracyjnego oraz znajomości składni Nginx.
LiteSpeed
LiteSpeed również korzysta z architektury zdarzeniowej. W środowiskach PHP może komunikować się z aplikacją za pomocą LSAPI, czyli interfejsu zaprojektowanego z myślą o wydajnej obsłudze procesów PHP.
Warto odróżnić dwa rozwiązania:
- LiteSpeed Web Server Enterprise – komercyjny i licencjonowany serwer;
- OpenLiteSpeed – wariant rozwijany jako oprogramowanie otwartoźródłowe.
LiteSpeed Enterprise zapewnia wysoki poziom zgodności z konfiguracją Apache, w tym obsługę wielu reguł znajdujących się w plikach .htaccess. Ułatwia to migrację stron, które wcześniej działały na Apache.
OpenLiteSpeed obsługuje między innymi reguły przepisywania adresów, ale nie należy zakładać pełnej zgodności ze wszystkimi dyrektywami .htaccess. Przed migracją trzeba sprawdzić, które elementy konfiguracji wymagają przeniesienia lub ręcznego dostosowania.
Jak rodzaj serwera WWW wpływa na szybkość i zużycie zasobów?
Architektura serwera wpływa na sposób utrzymywania połączeń, wykorzystanie pamięci oraz liczbę żądań, które mogą zostać obsłużone w określonym czasie. Różnice są zwykle najbardziej widoczne przy dużej liczbie użytkowników, długich połączeniach albo ograniczonej ilości pamięci RAM.
Serwery wykorzystujące model zdarzeniowy mogą efektywnie obsługiwać wiele częściowo bezczynnych połączeń. Jest to istotne zwłaszcza wtedy, gdy użytkownicy korzystają z wolniejszych sieci, przesyłane są duże pliki lub jedno połączenie obejmuje wiele kolejnych żądań.
Nie oznacza to jednak, że Nginx albo LiteSpeed automatycznie przyspieszą każdą witrynę. Apache skonfigurowany z MPM event i PHP-FPM może pracować znacznie sprawniej niż starsze środowisko wykorzystujące prefork oraz nieoptymalne limity procesów.
Przy stronach dynamicznych źródłem opóźnień często nie jest sam serwer WWW, lecz:
- wolny kod PHP;
- zbyt mała liczba procesów PHP;
- nieefektywne zapytania do bazy danych;
- rozbudowane lub źle napisane wtyczki;
- zewnętrzne połączenia API;
- brak pamięci podręcznej;
- przeciążony procesor;
- niewystarczająca ilość pamięci RAM.
Zmiana oprogramowania serwerowego nie naprawi ciężkiego motywu WordPressa ani zapytania SQL wykonywanego przez kilka sekund. Może jednak poprawić wykorzystanie infrastruktury, skrócić kolejki i zwiększyć odporność strony na nagłe skoki ruchu.
Ocena wydajności powinna obejmować nie tylko średni czas odpowiedzi. Warto analizować również:
- TTFB, czyli czas oczekiwania na pierwszy bajt;
- medianę oraz wysokie percentyle czasu odpowiedzi;
- liczbę obsługiwanych żądań;
- zużycie procesora i pamięci;
- kolejki procesów PHP;
- błędy 5xx;
- stabilność podczas testów obciążeniowych.
Porównanie ma sens tylko wtedy, gdy dotyczy tej samej aplikacji, podobnych zasobów, identycznej wersji PHP i porównywalnych ustawień cache. W przeciwnym razie wynik może pokazywać różnicę między konfiguracjami lub pakietami hostingowymi, a nie między samymi serwerami WWW.
Jak Apache, Nginx i LiteSpeed obsługują treści dynamiczne?
Serwer WWW zazwyczaj nie wykonuje bezpośrednio kodu aplikacji. Przekazuje żądanie do interpretera lub menedżera procesów, a następnie odbiera wygenerowaną odpowiedź.
W środowisku PHP duże znaczenie ma sposób komunikacji z pulą procesów. Liczba dostępnych workerów decyduje o tym, ile żądań dynamicznych może być przetwarzanych jednocześnie.
- Apache i PHP. Apache może współpracować z PHP-FPM za pośrednictwem FastCGI, między innymi przy użyciu modułu
mod_proxy_fcgi. PHP-FPM utrzymuje określoną pulę procesów odpowiedzialnych za wykonywanie kodu. Takie rozdzielenie pozwala niezależnie kontrolować serwer WWW i środowisko PHP. Administrator może ustawić liczbę procesów początkowych, limity równoległych żądań oraz sposób uruchamiania kolejnych workerów. - Nginx i PHP-FPM. Nginx przekazuje żądania PHP do PHP-FPM przy użyciu dyrektywy
fastcgi_pass. Komunikacja może odbywać się przez port sieciowy albo gniazdo systemowe. Serwer może również buforować odpowiedzi pochodzące z FastCGI. W prawidłowo skonfigurowanym środowisku część użytkowników otrzymuje gotową odpowiedź bez ponownego uruchamiania WordPressa czy wykonywania zapytań do bazy. - LiteSpeed i LSAPI. LiteSpeed może korzystać z LSPHP, czyli wersji PHP współpracującej z interfejsem LSAPI. Mechanizm ten odpowiada za komunikację między serwerem a procesami wykonującymi kod aplikacji. Także w tym przypadku liczba procesów musi być dopasowana do dostępnej pamięci i charakteru ruchu. Zbyt mała pula powoduje tworzenie kolejek. Zbyt duża może doprowadzić do wyczerpania RAM, uruchomienia mechanizmu swap lub zakończenia procesów przez system operacyjny.
Niezależnie od wybranego rozwiązania na wydajność treści dynamicznych wpływają również:
- aktualna i kompatybilna wersja PHP;
- aktywny OPcache;
- limity pamięci;
- czas wykonywania skryptów;
- sprawność bazy danych;
- jakość kodu aplikacji;
- liczba równoczesnych użytkowników.
Dlatego strojenie środowiska powinno uwzględniać cały łańcuch obsługi żądania, a nie tylko nazwę serwera.
Wpływ serwera WWW na wydajność WordPressa
WordPress może działać na Apache, Nginx, LiteSpeed i innych serwerach obsługujących PHP oraz wymagane reguły adresów. Wybór infrastruktury ma znaczenie, ale zwykle nie jest jedynym ani najważniejszym czynnikiem decydującym o szybkości witryny.
Apache jest wygodny w środowiskach, w których WordPress lub wtyczki zapisują reguły do .htaccess. Dotyczy to między innymi przyjaznych adresów, przekierowań, kontroli dostępu i wybranych ustawień bezpieczeństwa. Trzeba jednak pamiętać, że przy aktywnej obsłudze .htaccess serwer może sprawdzać pliki konfiguracyjne znajdujące się w kolejnych katalogach.
W Nginx wszystkie wymagane reguły trzeba przenieść do konfiguracji hosta. WordPress nie może samodzielnie zmienić głównego pliku konfiguracyjnego, dlatego komunikat wyświetlany przez wtyczkę lub panel CMS nie zawsze oznacza, że dane ustawienie zostało rzeczywiście zastosowane.
LiteSpeed jest często wybierany w środowiskach WordPress między innymi ze względu na możliwość wykorzystania serwerowego mechanizmu cache. Pamięć podręczna musi być jednak skonfigurowana świadomie. Nie wszystkie odpowiedzi mogą być przechowywane i zwracane kolejnym użytkownikom.
Z publicznego cache pełnych stron należy wykluczyć przede wszystkim odpowiedzi zawierające dane prywatne, spersonalizowane lub zależne od bieżącej sesji użytkownika, w szczególności:
- panelu administracyjnego;
- koszyka i procesu zakupowego;
- stron kont użytkowników;
- treści zależnych od zalogowania;
- formularzy wykorzystujących dynamiczne tokeny;
- spersonalizowanych odpowiedzi.
Największą poprawę może zapewnić cache pełnych stron, ponieważ ogranicza liczbę uruchomień PHP oraz zapytań do bazy danych. Z kolei OPcache przechowuje skompilowaną postać kodu PHP, dzięki czemu interpreter nie musi przetwarzać tych samych plików od początku przy każdym żądaniu.
Serwer WWW nie zastąpi jednak optymalizacji samego WordPressa. Nawet wydajna infrastruktura może zostać przeciążona przez źle napisane wtyczki, rozbudowane zapytania, brak indeksów w bazie, automatycznie ładowane dane albo niezoptymalizowane obrazy.
Przed migracją warto sprawdzić, gdzie faktycznie powstają opóźnienia. Jeżeli głównym problemem jest kod aplikacji, przejście z Apache na Nginx może nie przynieść odczuwalnej zmiany. Jeżeli natomiast strona osiąga limity połączeń, workerów lub pamięci podczas skoków ruchu, odpowiednio dobrana architektura może poprawić stabilność.
Jak wybrać serwer WWW dopasowany do potrzeb witryny?
Nie istnieje jeden serwer odpowiedni dla każdej strony. Decyzja powinna wynikać z rodzaju aplikacji, wymagań dotyczących zgodności, kompetencji administratora i wyników testów.
Apache może być dobrym wyborem, gdy:
- aplikacja intensywnie korzysta z plików
.htaccess; - potrzebna jest konfiguracja na poziomie katalogów;
- priorytetem jest szeroka zgodność z istniejącymi rozwiązaniami;
- środowisko wykorzystuje narzędzia przygotowane z myślą o Apache.
Nginx warto rozważyć, gdy:
- serwer ma obsługiwać wiele jednoczesnych połączeń;
- potrzebny jest reverse proxy lub load balancing;
- infrastruktura składa się z kilku usług backendowych;
- konfiguracją zarządza administrator;
- ważna jest sprawna obsługa plików statycznych i TLS.
LiteSpeed może być uzasadniony, gdy:
- oczekiwana jest szeroka zgodność z konfiguracją Apache i plikami
.htaccess; - środowisko korzysta z PHP i LSAPI;
- potrzebny jest zintegrowany mechanizm cache, w tym możliwość wykorzystania ESI;
- koszt licencji mieści się w budżecie;
- operator hostingu zapewnia poprawnie skonfigurowaną usługę.
OpenLiteSpeed warto rozważyć, gdy:
- preferowane jest rozwiązanie open source bez opłaty licencyjnej;
- dopuszczalne jest dostosowanie konfiguracji podczas migracji z Apache;
- wystarcza obsługa reguł przepisywania adresów bez pełnej zgodności z dyrektywami
.htaccess; - brak obsługi ESI nie stanowi problemu dla używanej aplikacji i mechanizmu cache.
Na hostingu współdzielonym użytkownik zazwyczaj nie wybiera ani nie instaluje samodzielnie serwera WWW. W takiej sytuacji większe znaczenie od samej nazwy technologii mogą mieć limity procesora, pamięci, operacji dyskowych, procesów PHP i liczby jednoczesnych połączeń. Liczy się również jakość konfiguracji przygotowanej przez operatora.
Na VPS lub serwerze dedykowanym zakres decyzji jest większy, ale rośnie również odpowiedzialność za aktualizacje, monitoring, bezpieczeństwo, kopie zapasowe i reagowanie na awarie.
Migrację na inny serwer WWW należy poprzedzić testem w środowisku stagingowym. Powinien on obejmować najważniejsze ścieżki użytkownika, takie jak:
- otwieranie strony głównej i podstron;
- logowanie oraz obsługa konta;
- wysyłanie formularzy;
- dodawanie produktów do koszyka;
- przechodzenie przez proces zakupowy;
- obsługa przekierowań i przyjaznych adresów;
- działanie nagłówków bezpieczeństwa;
- zachowanie cache dla użytkowników zalogowanych i niezalogowanych;
- stabilność podczas symulowanego wzrostu ruchu.
Potrzebny jest również plan wycofania zmian. W razie problemów administrator powinien mieć możliwość szybkiego przywrócenia poprzedniego środowiska, konfiguracji i ruchu.
W Rapid DC patrzymy na serwer jako na część większego systemu, a nie pojedynczy element mający rozwiązać każdy problem z wydajnością. Właściwe rozwiązanie powinno być zgodne z aplikacją, bezpieczne, mierzalne i możliwe do sprawnego utrzymania. Dopiero zestawienie tych warunków z rzeczywistymi wynikami testów pozwala podjąć odpowiedzialną decyzję infrastrukturalną.