Apache vs Nginx – który serwer WWW jest lepszy? Porównanie wydajności i funkcji

Nginx jest obiektywnie lepszym i szybszym serwerem WWW do obsługi ogromnego ruchu statycznego i działania jako reverse proxy, podczas gdy Apache wygrywa elastycznością konfiguracji na poziomie pojedynczych katalogów dzięki plikom .htaccess. Wybór zależy wprost od architektury Twojej aplikacji, ale w nowoczesnych wdrożeniach o wysokim obciążeniu to Nginx deklasuje konkurenta pod kątem zużycia pamięci RAM. Taka jest po prostu techniczna prawda. Od lat administruję systemami Linux i widziałem dziesiątki upadających środowisk produkcyjnych tylko dlatego, że ktoś źle dobrał narzędzie do charakterystyki ruchu sieciowego.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Zrobiliśmy na wdrożeniu klasyczny setup LAMP, potem zawiesiło się odpytywanie bazy przy strzale ruchu, więc wprowadzono poprawkę w konfiguracji procesów roboczych przed poniedziałkiem. Nic to nie dało. Apache dławił się własnymi procesami. O 3 nad ranem na szybkiego, zrezygnowani przez awarie na wdrożeniu po potyczkach u siebie w oddziale IT, postawiliśmy przed nim Nginx jako load balancer. Zużycie zasobów spadło bez mała prawie o siedemdziesiąt procent. To nie magia. To różnica w architekturze, którą zaraz brutalnie rozbierzemy na części pierwsze.

Dlaczego w ogóle porównujemy Apache i Nginx w kontekście wydajności?

Dwa serwery HTTP kontrolują zdecydowaną większość światowego internetu. Apache HTTP Server powstał w połowie lat dziewięćdziesiątych. Był pisany pod zupełnie inne realia sieciowe. Wtedy nikt nie myślał o problemie C10K, czyli konieczności jednoczesnej obsługi dziesięciu tysięcy połączeń na jednej maszynie. Liczyła się stabilność i możliwość łatwego dodawania modułów. Z kolei Igor Sysoev stworzył Nginx na początku lat dwutysięcznych z jednym, bardzo konkretnym celem. Miał rozwiązać problem wydajności i zjadać jak najmniej pamięci operacyjnej. Udało mu się.

Prawda jest zresztą absolutnie taka, że do dzisiaj administratorzy toczą wojny na forach o to, co wybrać. Apache vs Nginx to nie jest tylko akademicka debata. To decyzja o tym, czy za serwer dedykowany zapłacisz trzysta, czy tysiąc złotych miesięcznie. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj z całego rynku, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem budżetów w IT. Firmy tną koszty. Optymalizacja infrastruktury to najprostsza droga do oszczędności.

Apache działa w oparciu o model procesowy lub wątkowy. Nginx jest oparty na zdarzeniach (event-driven). Brzmi jak nudny żargon. Ale to właśnie ten detal decyduje o tym, czy twoja strona przetrwa wykop efekt albo nagły atak DDoS. My u nas w zespole dawno przestaliśmy ufać domyślnym konfiguracjom. Piszemy własne reguły.

Jak architektura Apache wpływa na zużycie pamięci i procesora?

Apache oferuje trzy główne moduły wieloprzetwarzania (MPM). To one decydują o tym, jak serwer WWW przyjmuje żądania od przeglądarek. Mamy tu Prefork, Worker i Event. Prefork to prehistoria, ale nadal domyślnie używana w wielu tanich hostingach współdzielonych ze względu na mod_php. Działa to koszmarnie prosto. Dla każdego nowego połączenia serwer tworzy nowy, odrębny proces w systemie operacyjnym. Jeden proces obsługuje jedno połączenie. Jeśli masz sto wizyt jednocześnie, masz sto procesów. Jeśli masz tysiąc, masz tysiąc procesów. RAM znika w oczach.

Potem pojawił się MPM Worker. Tutaj jeden proces tworzy wiele wątków. Jest trochę lżej. Zdecydowanie mniej to obciąża zasoby serwera. Ostatecznie wprowadzono MPM Event, który próbuje naśladować asynchroniczność i zwalniać wątki utrzymujące długie połączenia Keep-Alive. Działa to nieźle. Ale to wciąż nakładanie łaty na starą koncepcję.

• W modelu Prefork pojedynczy proces potrafi pożreć od 20 do 50 megabajtów pamięci. Przy ataku na aplikację serwer natychmiast zaczyna używać pamięci swap na dysku. To zabija wydajność do zera. Maszyna staje w miejscu.
• Konfiguracja limitów MaxRequestWorkers wymaga ciągłego monitorowania. Ustawisz za mało – klienci dostaną błędy. Ustawisz za dużo – braknie RAM-u i zadziała systemowy OOM Killer, mordując procesy bazy danych.

Widziałem na własne oczy, jak potężne maszyny z 64 GB RAM padały pod naporem zwykłego ruchu ze strony głównej popularnego portalu lokalnego, bo administrator zostawił domyślne ustawienia Apache. Trzeba mieć świadomość, że elastyczność ma swoją cenę. A tą ceną jest narzut technologiczny.

W jaki sposób Nginx radzi sobie z tysiącami połączeń jednocześnie?

Nginx odrzucił model tworzenia procesu dla każdego użytkownika. Sysoev wymyślił to inaczej. Postawił na pętlę zdarzeń. Mamy jeden główny proces zarządzający (master process) i kilka procesów roboczych (worker processes), zazwyczaj przypisanych w relacji jeden do jednego z fizycznymi rdzeniami procesora. To wszystko.

Kiedy przychodzi nowe żądanie, Nginx nie tworzy nowego bytu w systemie. Pętla zdarzeń po prostu rejestruje to połączenie i obsługuje je asynchronicznie. Kiedy proces roboczy czeka na odczyt z dysku lub odpowiedź z bazy danych, nie blokuje się. Natychmiast bierze się za obsługę kolejnego klienta w kolejce. To jest genialne w swojej prostocie. Nginx na jednym rdzeniu spokojnie zamyka temat przy kilkunastu tysiącach połączeń statycznych, pożerając zaledwie parę megabajtów pamięci. Różnica jest kolosalna.

Wrzucamy do tego asynchroniczne I/O i obsługę nagłówków sieciowych na bardzo niskim poziomie. Zmieniliśmy te zasady na robocie u nas w firmie dwa lata temu. Wyrzuciliśmy Apache z frontu. Nginx przyjął cały ruch statyczny. Obciążenie procesorów spadło do poziomu błędu statystycznego. Omijamy w ten sposób wąskie gardła, które dławiły nas przez lata.

Apache vs Nginx w obsłudze treści dynamicznych – kto ma przewagę?

Tutaj zaczynają się schody i prawdziwe różnice w filozofii obu projektów. Apache to kombajn. Potrafi przetwarzać kod dynamiczny wewnątrz własnych procesów. Robi to za pomocą wbudowanych modułów, takich jak bardzo znany mod_php, mod_python czy mod_perl. Serwer WWW sam interpretuje kod aplikacji. Nie musi komunikować się z zewnętrznymi usługami. To wygodne z punktu widzenia konfiguracji. Odpalasz i działa.

Nginx tego nie potrafi. Z założenia. Twórcy uznali, że serwer HTTP ma serwować ruch HTTP, a nie kompilować skrypty w locie. Nginx nie ma czegoś takiego jak mod_php. Żeby obsłużyć stronę napisaną w PHP, Nginx musi przekazać żądanie do zewnętrznego procesu za pomocą protokołu FastCGI. Najczęściej jest to PHP-FPM (FastCGI Process Manager). Nginx działa tu w zasadzie jako reverse proxy. Odbiera żądanie, rzuca je do PHP-FPM, czeka na wygenerowany HTML i odsyła do przeglądarki.

Kto ma przewagę? Wydajnościowo wygrywa duet Nginx plus PHP-FPM. Rozdzielenie serwera WWW od interpretera języka pozwala na niezależne skalowanie obu usług. Jeśli maszyna nie wyrabia z renderowaniem PHP, możesz postawić PHP-FPM na innym serwerze fizycznym i kazać Nginxowi wysyłać tam pakiety przez sieć lokalną. Apache z mod_php wiąże ci ręce. Utoniesz w zasobach.

Czy pliki .htaccess to usprawiedliwienie dla wolniejszego działania?

To jest bez mała najgorsza opcja z wszystkich pod kątem wydajności, ale deweloperzy ją kochają. Pliki .htaccess pozwalają na zmianę konfiguracji serwera dla konkretnego katalogu bez potrzeby restartowania głównej usługi. Każdy użytkownik hostingu współdzielonego może sobie zdefiniować własne reguły przekierowań, blokady IP czy ustawienia pamięci podręcznej.

Jak to działa pod spodem? Kiedy użytkownik prosi o plik z głęboko zagnieżdżonego katalogu, Apache musi przeszukać każdy folder po drodze w drzewie katalogów, sprawdzając, czy leży tam plik .htaccess. Jeśli znajdzie, musi go odczytać z dysku, sparsować w locie i zaaplikować reguły. I tak przy każdym pojedynczym zapytaniu HTTP. Narzut na operacje wejścia/wyjścia (I/O) jest potężny.

Nginx na to leje z góry. Nie ma żadnych plików .htaccess. Cała konfiguracja musi znajdować się w głównych plikach konfiguracyjnych serwera i wczytywana jest tylko raz, podczas startu usługi lub przeładowania (reload). Ostrzegam, reguły Rewrite w Nginx to kompletnie INNA bajka dla kogoś przyzwyczajonego do składni Apache. Trzeba się uczyć wyrażeń regularnych na nowo. Ale dzięki temu serwer nie czyta dysku przy każdym kliknięciu myszką przez klienta. Szybkość odpowiedzi jest nieporównywalnie lepsza.

W jakich sytuacjach Nginx absolutnie deklasuje konkurencję?

Są miejsca w architekturze IT, gdzie stawianie Apache to po prostu proszenie się o kłopoty. Nginx został stworzony do konkretnych zadań i tam sprawdza się najlepiej na świecie.

• Serwowanie plików statycznych: Obrazy, arkusze stylów CSS, pliki JavaScript, wideo. Nginx potrafi wypluwać statykę prosto z pamięci podręcznej systemu z prędkością ograniczoną jedynie przepustowością karty sieciowej.
• Reverse proxy i Load Balancing: Stawiasz Nginxa na froncie. On przyjmuje uderzenie ruchu od klientów. Następnie rozdziela ten ruch za pomocą algorytmów (np. round-robin, least_conn) na kilka serwerów aplikacyjnych schowanych w sieci prywatnej. Potrafi przy okazji terminować połączenia SSL/TLS, zdejmując obciążenie kryptograficzne z backendu.
• Strumieniowanie mediów: Obsługa protokołów wideo, HLS, RTMP. Moduły Nginxa są do tego świetnie zoptymalizowane.
• Mikroserwisy i konteneryzacja: W środowiskach Docker i Kubernetes, Nginx (lub jego forki) jest standardem jako Ingress Controller. Lekkość obrazu kontenera ma tu ogromne znaczenie.

Poniżej zestawiłem twarde fakty oparte na naszych pomiarach z ostatnich wdrożeń u klientów. Cyfry nie kłamią, choć statystyki bywają brutalne dla starszych technologii.

Kiedy lepiej wybrać serwer Apache do swojego projektu?

Żeby nie było, że tylko chwalę jeden produkt. Apache wciąż ma swoje żelazne miejsce na rynku i wygryza konkurencję w specyficznych przypadkach użycia. U nas w firmie wciąż utrzymujemy kilkanaście maszyn na tym demonie.

Kiedy to ma sens?

• Gdy stawiasz masowy hosting współdzielony. Klienci wymuszają posiadanie dostępu do .htaccess. Bez tego nie zainstalują łatwo WordPressa czy PrestaShop, bo wtyczki modyfikują te pliki automatycznie. Jeśli zabierzesz im tę możliwość, zaleją dział wsparcia technicznego ticketami.

  Gdy utrzymujesz aplikacje typu legacy. Stare systemy ERP pisane dekadę temu w PHP 5.6 często polegają na specyficznych, rzadkich modułach Apache, których przepisanie pod Nginxa zajęłoby setki roboczogodzin. Koszt migracji przewyższa korzyści.

• Środowiska deweloperskie u programistów na lokalnych maszynach. Szybkość nie ma tam znaczenia, liczy się wygoda i brak konieczności ciągłego restartowania usługi po zmianie reguły przekierowania.

Apache posiada gigantyczną, wręcz przytłaczającą dokumentację i społeczność. Każdy błąd, jaki zobaczysz w logach, został już przez kogoś opisany w 2008 roku na Stack Overflow. To potężna wartość dla administratorów, którzy nie chcą tracić nocy na eksperymentowanie ze słabo udokumentowanymi modułami z GitHuba.

Czy połączenie Apache i Nginx ma sens w środowisku produkcyjnym?

To jest podejście, które stosujemy najczęściej przy ratowaniu upadających portali. Hybryda. Bierzemy to, co najlepsze z obu światów. Budujemy strukturę, w której Nginx stoi na samym przodzie jako reverse proxy, uderzając bezpośrednio do portu 80 lub 443 na firewallu.

Nginx przyjmuje całe uderzenie ruchu. Odfiltrowuje śmieci. Serwuje pliki statyczne prosto ze swojego cache. Kiedy jednak klient prosi o wygenerowanie dynamicznej strony, Nginx przekazuje to żądanie do serwera Apache, który działa w tle, schowany na porcie 8080. Apache robi swoją magię, czyta pliki .htaccess, przetwarza PHP i oddaje wynik Nginxowi. Nginx z kolei przesyła to z powrotem do przeglądarki użytkownika.

Zyskujemy potężną wydajność obsługi statyki i zachowujemy stuprocentową kompatybilność z wymogami aplikacji pod względem konfiguracji katalogów. Pamiętam, jak wdrażaliśmy to u wydawcy lokalnej gazety. Serwer padał codziennie o 19:00, gdy wypuszczali wieczorny biuletyn. Po postawieniu Nginxa przed Apachem, load average spadł z 25.0 do 1.2. Nawet nie musieliśmy dokupywać RAM-u u operatora chmury.

Jak wygląda proces migracji z Apache na Nginx?

To nie jest operacja na pięć minut klikania w panelu. Migracja wymaga przepisania logiki routingu. Najwięcej problemów sprawiają zawsze reguły mod_rewrite. Apache używa warunków i wyrażeń regularnych w bardzo specyficznym formacie. Nginx ma bloki location i dyrektywy try_files.

Dobrym pomysłem jest postawienie środowiska testowego i użycie konwerterów składni dostępnych w sieci, ale uprzedzam od razu – one zazwyczaj generują śmieciowy kod. Trzeba to weryfikować ręcznie. Zmieniliśmy te zasady na robocie i teraz każdą regułę piszemy od zera, testując odpowiedź nagłówków za pomocą polecenia curl w konsoli.

Musisz też przenieść obsługę SSL. Certyfikaty z Let’s Encrypt trzeba przekonfigurować, aby certbot odnawiał je dla domeny obsługiwanej przez Nginx w trybie webroot lub standalone. Często zapomina się o nagłówkach proxy. Jeśli Nginx przekazuje ruch do backendu, musisz ustawić dyrektywy proxy_set_header X-Real-IP oraz X-Forwarded-For. Bez tego aplikacja w logach będzie widziała tylko adres IP samego load balancera, czyli 127.0.0.1. Zepsujesz w ten sposób statystyki, blokady anty-spamowe i systemy płatności.

Porzuć sentymenty do starych przyzwyczajeń. Masz przed sobą twarde dane, architekturę systemów i opowieści z pierwszej linii frontu administracji serwerami. Wyłącz na chwile swoje ulubione IDE, wejdź na serwer przez SSH, odpal komendę htop i spójrz prawdzie w oczy. Ile pamięci marnuje twoja maszyna na utrzymywanie pustych procesów? Zmierz to, zrób zrzut bazy w nocy i spróbuj postawić Nginxa obok. Różnica uderzy cię w twarz szybciej, niż zdążysz przeładować usługę.

1. Który serwer WWW jest szybszy: Apache czy Nginx?

Nginx jest zdecydowanie szybszy w serwowaniu plików statycznych i radzeniu sobie z ogromną liczbą jednoczesnych połączeń (problem C10K) dzięki architekturze opartej na zdarzeniach. Apache przy obciążeniu zużywa znacznie więcej zasobów systemowych.

2. Czy Nginx obsługuje pliki .htaccess?

Nie. Nginx z premedytacją nie obsługuje plików .htaccess ze względów wydajnościowych. Cała konfiguracja reguł przekierowań i dostępu musi znajdować się w głównych plikach konfiguracyjnych serwera.

3. Jak Nginx radzi sobie z kodem PHP?

Nginx nie posiada wbudowanego modułu do interpretacji PHP (jak mod_php w Apache). Żądania dynamiczne przekazuje do zewnętrznych procesów, najczęściej do PHP-FPM, działając jako szybkie proxy odwrotne.

4. Czy mogę używać Apache i Nginx na jednym serwerze?

Tak, to bardzo popularna i wydajna konfiguracja. Nginx działa na froncie (port 80/443), serwując statykę i przyjmując ruch, a żądania dynamiczne przekazuje do ukrytego w tle serwera Apache.

5. Co to jest architektura event-driven w Nginx?

To model, w którym jeden proces roboczy obsługuje asynchronicznie tysiące połączeń w pętli zdarzeń, nie blokując się na operacjach wejścia/wyjścia. Apache tradycyjnie tworzy nowy wątek lub proces dla każdego klienta.

6. Kiedy lepiej zostać przy serwerze Apache?

Apache jest lepszym wyborem dla tanich hostingów współdzielonych (gdzie klienci wymagają izolacji przez .htaccess), dla starych aplikacji polegających na specyficznych modułach Apache oraz w szybkich środowiskach deweloperskich.

Bibliografia:

1. Apache HTTP Server Project – https://httpd.apache.org
2. NGINX – https://nginx.org
3. Linux Foundation – https://www.linuxfoundation.org
4. W3Techs – https://w3techs.com
5. Netcraft – https://www.netcraft.com