Apache vs NGINX — kto WYGRYWA pod względem wydajności?

Apache vs NGINX to jedna z najgorętszych debat (od czasu wydania NGINX), ponieważ oba te serwery są jednymi z najpopularniejszych serwerów internetowych na świecie, a następnie LiteSpeed ​​i OpenLiteSpeed.

Apache i NGINX obsługują prawie 60% światowych witryn internetowych. Apache i NGINX są podobne pod względem wydajności i funkcji. Z drugiej strony ich architektura, bezpieczeństwo i wydajność są różne.

Wybór między tymi dwoma serwerami może być trudny, ponieważ oba są doskonałe. Ponieważ każdy serwer sieciowy ma swój własny zestaw zalet i wad, bardzo ważne jest, aby wybrać najlepszą możliwą opcję.

Możesz również sprawdzić debatę openlitespeed vs nginx tutaj.

Porównanie prędkości Apache i NGINX

Przed zagłębieniem się w debatę Apache vs NGINX. Najpierw zrobimy prosty test prędkości, w którym przeprowadzimy test w następujących scenariuszach.

• Przetestujmy mały, statyczny plik o rozmiarze 5 KB
• Plik statyczny o rozmiarze 1MB
• Testowanie prostej aplikacji PHP Hello World
• Porównanie Apache vs NGINX dla WordPress

Wykorzystaliśmy tę samą procedurę do testowania openlitespeed vs nginx. OpenLiteSpeed ​​jest naprawdę świetną alternatywą dla NGINX, ponieważ obsługuje również podstawowe reguły przepisywania .htaccess , dzięki czemu możesz łatwo przejść z Apache do OpenLiteSpeed.

Przetestujmy mały, statyczny plik o rozmiarze 5 KB

Ostateczny werdykt : Oba serwery działały tak samo z małym plikiem statycznym.

Apache

NGINX

Plik statyczny o rozmiarze 1MB

Ostateczny werdykt : NGINX wyraźnie wygrał z dużym, statycznym plikiem.

Apache

NGINX

Testowanie prostej aplikacji PHP Hello World

Ostateczny werdykt : Oba serwery działały tak samo z aplikacją hello world php.

Apache

NGINX

Porównanie Apache vs NGINX dla WordPress

Ostateczny werdykt : NGINX wyraźnie wygrał z witryną WordPress. Możesz skorzystać z tego przewodnika, aby przyspieszyć swój sklep WooCommerce

Apache

NGINX

Wynik testów - Apache vs NGINX

Jak widać w testach, NGINX jest relatywnie lepszy od Apache pod względem szybkości. Wyniki to:

1. Przetestuj mały, statyczny plik o rozmiarze 5 KB:

W tym teście widzimy, że obie reklamy Apache NGINX dają względnie takie same wyniki.

2. Przetestuj duży plik statyczny o rozmiarze 1 MB:

W tym teście widzimy, że prędkość NGINX jest skokowo lepsza niż Apache. NGINX zapewnia znacznie krótszy średni czas odpowiedzi.

3. Przetestuj prostą aplikację PHP Hello World

W tym teście widzimy, że zarówno Apache, jak i NGINX dają względnie takie same wyniki.

4. Przetestuj Apache vs NGINX dla WordPress

W tym teście widzimy, że średni czas odpowiedzi NGINX jest o wiele krótszy niż Apache, co daje mu większą prędkość niż NGINX.

Apache

Istnieje społeczność programistów, którzy utrzymują Apache jako serwer WWW o otwartym kodzie źródłowym. Wykorzystuje architekturę opartą na procesach, w której tworzy nowy wątek dla każdego żądania połączenia.
Ponadto Apache oferuje różnorodne moduły, które można wykorzystać do zwiększenia funkcjonalności serwera WWW. Apache jest szybki, niezawodny, bezpieczny i wysoce konfigurowalny, aby sprostać potrzebom różnych środowisk za pomocą rozszerzeń i modułów.

Architektura obsługi połączeń

Apache ma wiele modułów przetwarzania wieloprocesowego (nazywanych przez Apache MPM), które kontrolują sposób obsługi żądań klientów. Zasadniczo umożliwia to administratorom szybką zmianę architektury obsługi połączeń.

• mpm-Prefor: Ten Multi-Processing Module (MPM) implementuje pre-forkingowy serwer WWW, który nie jest wątkowy. Każdy proces serwera może odpowiadać na przychodzące żądania, a rozmiarem puli serwerów zarządza proces nadrzędny. Jest odpowiedni dla witryn, które muszą unikać wątków, aby pracować z bibliotekami, które nie są bezpieczne dla wątków. Jest to również najlepszy MPM do izolowania każdego żądania, zapewniając, że problem z jednym nie wpłynie na inne.
• mpm-worker: Hybrydowy, wieloprocesowy, wielowątkowy serwer jest implementowany przez ten moduł wieloprzetwarzania (MPM). Może obsługiwać dużą liczbę żądań przy mniejszych zasobach systemowych niż serwer oparty na procesach, ponieważ do dostarczania żądań wykorzystuje wątki. Dzięki utrzymywaniu dostępności wielu procesów, z których każdy ma wiele wątków, zachowuje znaczną część stabilności serwera opartego na procesach.
• mpm-event: Zdarzenie Multi-Processing Module (MPM) ma na celu umożliwienie obsługi wielu żądań w tym samym czasie poprzez delegowanie określonego przetwarzania do wątków odbiornika, zwalniając wątki robocze do obsługi nowych żądań.
  Apache ma elastyczną konstrukcję, która pozwala wybierać spośród różnych algorytmów połączeń i obsługi żądań. Wraz ze zmianą krajobrazu internetowego prezentowane wybory są przede wszystkim wynikiem ewolucji serwerów i zwiększonego zapotrzebowania na współbieżność.

Treści statyczne a treści dynamiczne

Treść statyczna może być obsługiwana przez serwery Apache przy użyciu ich standardowych mechanizmów opartych na plikach. Wyżej wymienione podejścia MPM są w większości odpowiedzialne za wykonanie tych procedur.

Apache może dodatkowo przetwarzać zawartość dynamiczną, dołączając procesor specyficzny dla języka w każdej instancji roboczej. Dzięki temu może wykonywać dynamiczne treści bez użycia zewnętrznych komponentów na serwerze WWW. Dynamicznie ładowane moduły mogą być użyte do włączenia tych dynamicznych procesorów.

Ponieważ Apache może wewnętrznie obsługiwać zawartość dynamiczną, konfiguracja przetwarzania dynamicznego jest zwykle łatwiejsza. Moduły można łatwo wymienić, jeśli zmienią się wymagania dotyczące treści, a komunikacja nie musi być skoordynowana z dodatkowym oprogramowaniem.

Konfiguracja rozproszona a scentralizowana

Analizując i interpretując dyrektywy w ukrytych plikach w samych folderach zawartości, Apache dodaje opcję umożliwiającą dalszą konfigurację dla poszczególnych katalogów. Pliki .htaccess to nazwy tych plików.

Ponieważ te pliki znajdują się w folderach zawartości, Apache szuka pliku .htaccess w każdym komponencie ścieżki do żądanego pliku i stosuje znajdujące się tam dyrektywy. To skutecznie umożliwia zdecentralizowaną konfigurację serwera WWW, który jest powszechnie używany do przepisywania adresów URL, ograniczania dostępu, autoryzacji i uwierzytelniania, a nawet zasad pamięci podręcznej.

Chociaż wszystkie powyższe przykłady można skonfigurować w głównym pliku konfiguracyjnym Apache, pliki .htaccess zapewniają szereg korzyści. Po pierwsze, ponieważ są one oceniane za każdym razem, gdy zostaną napotkane na ścieżce żądania, są implementowane bez konieczności ponownego ładowania serwera. Po drugie, umożliwia nieuprzywilejowanym użytkownikom kontrolowanie określonych części ich własnej zawartości internetowej bez nadawania im pełnej władzy nad plikiem konfiguracyjnym.

Niektóre programy internetowe, takie jak systemy zarządzania treścią, mogą teraz łatwo dostosowywać swoje środowisko bez konieczności dostępu do centralnego pliku konfiguracyjnego. Dostawcy hostingu współdzielonego wykorzystują to, aby zachować kontrolę nad podstawową konfiguracją, jednocześnie oferując klientom dostęp do ich określonych katalogów.

Interpretacja plikowa a interpretacja oparta na URI

Apache może interpretować żądanie jako fizyczny zasób systemu plików lub miejsce docelowe URI, które wymaga bardziej abstrakcyjnej oceny. Ogólnie rzecz biorąc, Apache używa bloków <Directory> lub <File> dla tych pierwszych, podczas gdy bloki <Location> są używane do bardziej abstrakcyjnych zasobów.

Ponieważ Apache został zbudowany od podstaw jako serwer WWW, domyślnie interpretuje żądania jako zasoby systemu plików. Aby znaleźć rzeczywisty plik, zaczyna się od katalogu głównego dokumentu i dołącza fragment żądania następujący po numerze hosta i portu. W sieci hierarchia systemu plików jest zasadniczo reprezentowana przez dostępne drzewo dokumentów.

Gdy żądanie nie pasuje do podstawowego systemu plików, Apache oferuje kilka opcji. Na przykład dyrektywa Alias ​​może służyć do mapowania do innego miejsca. Używanie bloków <Location> zamiast systemu plików pozwala na bezpośrednią pracę z identyfikatorem URI. Odmiany wyrażeń regularnych są również dostępne do bardziej elastycznego stosowania konfiguracji w całym systemie plików.

Chociaż Apache może pracować zarówno na podstawowym systemie plików, jak i w przestrzeni internetowej, woli używać technik systemu plików. Odzwierciedlają to niektóre decyzje projektowe, takie jak użycie plików .htaccess do ustawiania poszczególnych katalogów.

Moduł

System modułów w Apache pozwala na dynamiczne ładowanie i rozładowywanie modułów, aby spełnić Twoje potrzeby, gdy serwer jest uruchomiony. Rdzeń Apache jest zawsze obecny, ale moduły można włączać lub wyłączać, dodając lub usuwając funkcje i łącząc się z głównym serwerem.

Ta funkcja jest używana przez Apache do szerokiego zakresu zadań. Ze względu na dojrzałość platformy zawiera ona dużą bibliotekę modułów. Mod php, na przykład, osadza interpreter PHP w każdym uruchomionym procesie roboczym i może być używany do zmiany części podstawowych funkcji serwera.

Z drugiej strony moduły nie tylko obsługują zawartość dynamiczną. Mogą między innymi przepisywać adresy URL, uwierzytelniać klientów, wzmacniać serwer, rejestrować, buforować, kompresować, proxy, ograniczać szybkość i szyfrować dane. Mogą oferować zwiększoną funkcjonalność bez dodawania dużej ilości pracy.

Wsparcie, kompatybilność, ekosystem i dokumentacja

Ponieważ Apache istnieje od tak dawna, jest dla niego duże wsparcie. W przypadku serwerów podstawowych i sytuacji opartych na zadaniach, związanych z łączeniem Apache z innym oprogramowaniem, dostępna jest pokaźna biblioteka dokumentacji własnej i innych firm.

Wiele narzędzi i projektów internetowych zawiera oprócz dokumentacji narzędzia do ładowania się w środowisku Apache. Może to być zawarte w samych projektach lub w pakietach obsługiwanych przez zespół ds. pakowania Twojej dystrybucji.

Ze względu na swój udział w rynku i ilość czasu, przez jaki był dostępny; Apache otrzyma ogólnie większe wsparcie od projektów stron trzecich. Administratorzy są również bardziej skłonni pracować z Apache, nie tylko ze względu na jego szerokie zastosowanie, ale także dlatego, że wiele osób rozpoczyna swoją karierę w środowiskach współdzielonego hostingu, gdzie Apache jest używany praktycznie wyłącznie ze względu na funkcje zarządzania rozproszonego .htaccess .

Zalety Apache vs NGINX

Wielu webmasterów i programistów woli Apache od NGINX, ponieważ jest znacznie starszy. Jest kompatybilny z systemami operacyjnymi Windows, Unix i Linux.

• W przypadku podawania materiału dynamicznego jest to doskonała wydajność.
• Dynamicznie ładuj i rozładowuj moduły.
• Udostępnia plik .htaccess dla każdego katalogu, którego można użyć do zastąpienia ustawień ogólnosystemowych.
• Wsparcie i dokumentacja są znakomite.
• Model wykorzystuje podejście jedno połączenie na proces.
• Zawiera moduły mod_evasive i mod_security, które dodają dodatkową warstwę bezpieczeństwa.

Wady Apache vs NGINX

• Nie można jednocześnie obsłużyć dużej liczby żądań.
• W porównaniu z NGINX wyświetlanie statycznej zawartości trwa dłużej.
• Zapewnia szerokie możliwości konfiguracji i zarządzania. W rezultacie nie jest odpowiedni dla nowicjuszy.
• Witryny o dużym natężeniu ruchu mają problemy z wydajnością.

NGINX

Próbując przezwyciężyć problem „C10k”, rosyjski koder Igor Sysoev wynalazł NGINX. Igor osiągnął swój cel: NGINX może z łatwością zarządzać ponad 10 000 jednoczesnych połączeń. Aby lepiej obsługiwać nowe połączenia, NGINX ma projekt oparty na zdarzeniach i asynchroniczny. NGINX to serwer WWW, który oferuje wiele możliwości. Poniżej wymieniono kilka z nich:

• Pamięć podręczna HTTP i system równoważenia obciążenia
• Serwer proxy frontonu Apache i innych serwerów internetowych.
• Odwrotny serwer proxy obsługuje wszystkie protokoły HTTP, HTTPS, SMTP, POP3 i IMAP.

Od czasu wydania NGINX zyskał na popularności ze względu na niskie zużycie zasobów i możliwość skutecznego skalowania na tanim sprzęcie. NGINX to serwer WWW, który specjalizuje się w szybkim udostępnianiu materiałów statycznych i jest przeznaczony do przesyłania dynamicznych żądań do oprogramowania, które jest lepiej dostosowane do takich zadań.

Architektura obsługi połączeń

NGINX pojawił się na scenie po Apache, dzięki lepszemu zrozumieniu problemów ze współbieżnością, z którymi borykają się witryny na dużą skalę. NGINX został zbudowany od podstaw przy użyciu asynchronicznego, nieblokującego, sterowanego zdarzeniami algorytmu obsługi połączeń, aby wykorzystać te informacje.

NGINX generuje procesy robocze, z których każdy jest w stanie obsłużyć dziesiątki tysięcy połączeń. Procesy robocze osiągają to dzięki opracowaniu mechanizmu szybkiego zapętlania, który regularnie sprawdza i przetwarza zdarzenia. Oddzielając rzeczywistą pracę od połączeń, każdy pracownik może skupić się na połączeniu tylko wtedy, gdy wystąpi nowe zdarzenie.

Każde z połączeń pracownika umieszczane jest w pętli zdarzeń, gdzie współistnieją z innymi połączeniami. Zdarzenia są przetwarzane asynchronicznie w pętli, dzięki czemu praca może być wykonywana w sposób nieblokujący. Link jest usuwany z pętli po jej zamknięciu.

NGINX może skalować się wyjątkowo daleko przy minimalnych zasobach dzięki metodzie przetwarzania połączeń. Ponieważ serwer jest jednowątkowy i żadne dodatkowe procesy nie są generowane do obsługi każdego nowego połączenia, użycie pamięci i procesora pozostaje względnie stałe, nawet gdy serwer jest pod dużym obciążeniem.

Treści statyczne a treści dynamiczne

NGINX nie ma natywnej obsługi dynamicznego przetwarzania treści. NGINX musi przekazywać żądania PHP i innych dynamicznych treści do zewnętrznego procesora w celu przetworzenia, a następnie czekać na zwrócenie renderowanej treści. Klient może następnie zostać poinformowany o ustaleniach.

Dla administratorów oznacza to, że komunikacja między NGINX a procesorem musi być skonfigurowana przy użyciu jednego z protokołów, które NGINX rozumie (http, FastCGI, SCGI, uWSGI, memcache). Może to nieco skomplikować sprawę, zwłaszcza przy szacowaniu liczby dozwolonych połączeń, ponieważ każde wywołanie procesora będzie wymagało nowego połączenia.

Z drugiej strony ta strategia zapewnia kilka korzyści. Narzut interpretera dynamicznego będzie obecny tylko w przypadku materiału dynamicznego, ponieważ nie jest on uwzględniony w procesie roboczym. Treści statyczne mogą być przesyłane w prosty sposób, z tłumaczem konsultowanym tylko wtedy, gdy jest to konieczne. Jest to również możliwe w przypadku Apache, ale eliminuje korzyści wymienione w poprzedniej sekcji.

Konfiguracja rozproszona a scentralizowana

NGINX nie rozumie plików .htaccess i nie ma sposobu oceny konfiguracji na katalog poza głównym plikiem konfiguracyjnym. Chociaż jest mniej wszechstronny niż podejście Apache, ma swój własny zestaw zalet.

Zwiększona wydajność to najbardziej zauważalny zysk w porównaniu z podejściem .htaccess w ustawieniach na poziomie katalogu. Dla każdego żądania serwer sprawdzi te pliki w każdym z nadrzędnych katalogów prowadzących do żądanego pliku w standardowej konfiguracji Apache, która zezwala na .htaccess w dowolnym katalogu. Jeśli to wyszukiwanie znajdzie jeden lub więcej plików .htaccess , należy je odczytać i przetworzyć. NGINX może szybciej obsługiwać żądania, wykonując pojedyncze zapytanie dotyczące katalogu i odczytując plik dla każdego żądania, nie zezwalając na zastępowanie katalogów (przy założeniu, że plik znajduje się w konwencjonalnej strukturze katalogów).

Kolejną korzyścią jest to, że jest bezpieczny. Dystrybucja dostępu do konfiguracji na poziomie katalogu powoduje również rozłożenie odpowiedzialności za bezpieczeństwo na poszczególnych użytkowników, którym można zaufać lub nie, jeśli chodzi o prawidłowe wykonanie tego zadania. Upewniając się, że administrator ma pełną kontrolę nad serwerem sieciowym, możesz uniknąć kilku błędów związanych z bezpieczeństwem, które mogą wystąpić, gdy dostęp zostanie udzielony innym.

Jeśli martwisz się tymi problemami, pamiętaj, że możesz wyłączyć interpretację .htaccess w Apache.

Interpretacja pliku VS oparta na URI

NGINX został zaprojektowany do pracy zarówno jako serwer WWW, jak i serwer proxy. Działa głównie z identyfikatorami URI, w razie potrzeby tłumacząc na system plików, ze względu na architekturę wymaganą dla tych dwóch zadań.

Widać to w sposobie tworzenia i przetwarzania plików konfiguracyjnych NGINX w niektórych przypadkach.
NGINX nie ma możliwości określenia konfiguracji katalogu systemu plików, dlatego analizuje identyfikator URI.

Na przykład bloki serwera i lokalizacji są najważniejszymi blokami konfiguracyjnymi dla NGINX. Blok serwera odpowiada za interpretację żądanego hosta, podczas gdy bloki lokalizacji odpowiadają za dopasowywanie części identyfikatora URI po hoście i porcie. Żądanie jest teraz przetwarzane jako identyfikator URI, a nie lokalizacja w systemie plików.

Wszystkie żądania dotyczące plików statycznych muszą być ostatecznie zmapowane do miejsca na dysku. NGINX najpierw wybiera bloki serwera i lokalizacji, które będą przetwarzać żądanie, a następnie łączy katalog główny dokumentu z identyfikatorem URI, modyfikując w razie potrzeby na podstawie ustawień.

Może się to wydawać podobne, ale interpretowanie żądań w dużej mierze jako identyfikatory URI, a nie lokalizacje systemu plików, ułatwia NGINX służenie jako serwer internetowy, pocztowy i proxy. NGINX jest konfigurowany przez zdefiniowanie sposobu, w jaki powinien odpowiadać na określone wzorce żądań. NGINX nie sprawdza systemu plików, dopóki nie jest gotowy do dostarczenia żądania, dlatego pliki .htaccess nie są obsługiwane.

Moduły

NGINX ma również system modułowy, jednak znacznie różni się od Apache. Moduły w NGINX nie mogą być ładowane dynamicznie, dlatego muszą być wybrane i skompilowane do oprogramowania podstawowego.
W wyniku tego NGINX stanie się znacznie mniej przystosowalny dla wielu użytkowników. Dotyczy to w szczególności użytkowników, którzy nie chcą utrzymywać swojego własnego oprogramowania poza standardowym schematem pakietów ich dystrybucji. Podczas gdy większość pakietów dystrybucji zawiera najczęściej używane moduły, jeśli potrzebujesz niestandardowego modułu, będziesz musiał sam zbudować serwer ze źródeł.

Z drugiej strony moduły NGINX są nadal bardzo cenne, ponieważ pozwalają dokładnie określić, czego chcesz od serwera, uwzględniając tylko te funkcje, których chcesz użyć. Niektórzy użytkownicy mogą również uważać, że podejście jest bezpieczniejsze, ponieważ dowolne komponenty nie mogą być połączone z serwerem. Jeśli Twój serwer znajdzie się kiedykolwiek w sytuacji, w której jest to możliwe, prawie na pewno jest już zagrożony.

Wiele z tych samych funkcji jest dostępnych w modułach NGINX, co w modułach Apache. Obsługa proxy, kompresja, ograniczenie szybkości, logowanie, przepisywanie, geolokalizacja, uwierzytelnianie, szyfrowanie, przesyłanie strumieniowe i funkcje poczty są dostępne za pośrednictwem modułów NGINX.

Wsparcie, kompatybilność, ekosystem i dokumentacja

NGINX zyskuje na popularności, ponieważ coraz więcej osób korzysta z niego ze względu na jego wysoką wydajność, ale nadal ma kilka do nadrobienia w niektórych kluczowych obszarach.

Ponieważ większość wczesnych prac rozwojowych i dokumentacji była w języku rosyjskim, w przeszłości trudno było znaleźć obszerną dokumentację anglojęzyczną dla NGINX. Dokumentacja została uzupełniona wraz ze wzrostem zainteresowania projektem, a obecnie w witrynie NGINX i za pośrednictwem stron trzecich dostępnych jest wiele zasobów administracyjnych.

Wsparcie i dokumentacja dla aplikacji innych firm stają się coraz szerzej dostępne, a opiekunowie pakietów zaczynają oferować opcje automatycznej konfiguracji Apache i NGINX w pewnych okolicznościach. Konfiguracja NGINX do pracy z innym oprogramowaniem jest zwykle prosta nawet bez wsparcia, o ile potrzeby projektu są udokumentowane (uprawnienia, nagłówki itp.).

Zalety NGINX

Serwer sieciowy NGINX jest prosty, lekki i szybki. Zaprojektowany specjalnie dla witryn o dużym natężeniu ruchu.

• Wykorzystuje sterowaną zdarzeniami, nieblokującą architekturę, która zużywa mniej procesora i pamięci.
• Zawiera wiele opcji optymalizacji i wyświetlania zawartości statycznej. W rezultacie obsługuje treści statyczne 2,5 razy szybciej i zużywa mniej pamięci niż Apache.
• Znakomicie sprawdza się w systemie wieloprocesorowym.
• Atakom DDoS zapobiega wbudowana opcja konfiguracji.

Wady NGINX

• Treści dynamiczne nie można przetwarzać natywnie.
• Dostępna jest mniejsza liczba modułów.
• Obsługiwane są systemy operacyjne Linux i Unix, jednak obsługa systemu Windows jest ograniczona.
• Plik .htaccess obsługiwany przez Apache nie jest obsługiwany przez NGINX.
• Niedobór oprogramowania do monitorowania dzienników — po prostu zapisuje dzienniki w plikach, do których należy ręcznie nawigować.

Aby używać Apache i NGINX razem

Po zapoznaniu się z zaletami i wadami zarówno Apache, jak i NGINX, powinieneś być w stanie określić, który serwer lepiej odpowiada Twoim potrzebom. Wielu użytkowników uważa jednak, że używanie obu serwerów razem pozwala im czerpać korzyści z każdego serwera.

Standardową konfiguracją tej współpracy jest użycie NGINX jako zwrotnego proxy przed Apache. Umożliwi to NGINX przetwarzanie wszystkich żądań klientów. Wykorzystuje to dużą szybkość przetwarzania NGINX i możliwość zarządzania dużą liczbą połączeń jednocześnie.

Pliki będą dostarczane szybko i bezpośrednio do klienta w celu uzyskania statycznej zawartości, w której NGINX przoduje. NGINX przekaże żądania zawartości dynamicznej, takiej jak skrypty PHP, do serwera Apache, który przetworzy wyniki i udostępni wyrenderowaną stronę. Materiał można następnie zwrócić do klienta za pośrednictwem NGINX.

Dla wielu użytkowników ten projekt działa dobrze, ponieważ pozwala NGINX działać jako maszyna sortująca. Obsłuży wszelkie żądania, które może, i przekaże te, z którymi nie wie, jak sobie poradzić. Możemy zmniejszyć część blokowania, które ma miejsce, gdy proces lub wątek Apache jest zajęty, zmniejszając liczbę żądań obsługiwanych przez serwer Apache.

Możesz skalować ten układ, dodając w razie potrzeby więcej serwerów zaplecza. NGINX można po prostu skonfigurować tak, aby przekazywał żądania do puli serwerów, poprawiając odporność konfiguracji na błędy i wydajność.

Kiedy używać Apache vs NGINX?

Zarówno Apache, jak i NGINX, jak opisano w tym artykule, są potężnymi, elastycznymi i wszechstronnymi serwerami sieciowymi. W przypadku witryn o dużym natężeniu ruchu Apache najlepiej nadaje się do dostarczania materiałów dynamicznych, podczas gdy NGINX najlepiej nadaje się do dostarczania zawartości statycznej lub strumieni multimediów. To takie proste:

Kiedy możesz używać Apache?

• Jeśli masz wspólny plan hostingowy.
• Jeśli cenisz sobie pomocną społeczność z mnóstwem zasobów, to jest to miejsce, w którym powinieneś być.
• Apache jest popularny wśród twórców stron internetowych, ponieważ jest prosty w konfiguracji.

Kiedy możesz korzystać z NGINX

• Jeśli masz VPS lub serwer dedykowany.
• Jesteś właścicielem popularnej witryny internetowej z dużą ilością statycznej zawartości.
• Jeśli chcesz zarządzać ruchem przychodzącym i dystrybuować go do serwerów nadrzędnych, które są wolniejsze.

Apache vs. NGINX: Który z nich wybrać dla swojego serwera w 2022 roku?

Powinieneś użyć tego, który zapewnia Twoja firma hostingowa. W wielu okolicznościach nie będziesz mieć opcji. Wielu dostawców stron internetowych stosuje tę samą strategię, którą powinieneś zastosować, jeśli decydujesz się między Apache a NGINX:

• Apache to dobry wybór, jeśli chcesz hostować serwer, który wymaga stałej konfiguracji lub jeśli chcesz dać użytkownikom opcję konfiguracji.
• Z drugiej strony NGINX jest najlepszym rozwiązaniem, jeśli potrzebujesz superszybkiej wydajności, solidnych zabezpieczeń i możliwości zarządzania konfiguracjami, a nie użytkownikami.

Ze względu na swoją podstawową architekturę Apache może zająć więcej pamięci RAM pod względem wydajności. W przypadkach o dużym natężeniu ruchu NGINX będzie działać lepiej, zwłaszcza jeśli trzeba zarządzać dużą ilością statycznego materiału.

NGINX może zatem być idealnym rozwiązaniem, jeśli polegasz na buforowaniu do przechowywania i udostępniania treści. Pamiętaj, że NGINX nie może zapewnić materiału dynamicznego; dlatego wydajność serwera proxy, z którego korzysta Twój serwer, będzie miała wpływ na wydajność.

Wniosek

Jak widać, zarówno Apache, jak i NGINX są potężne, elastyczne i zdolne. Ocena indywidualnych potrzeb i testowanie wzorców, których oczekujesz, to podstawowe kryteria wyboru odpowiedniego serwera.

Wśród tych projektów występują znaczne różnice w wydajności, możliwościach i czasie potrzebnym na wdrożenie każdego z nich. Często jednak są one wynikiem szeregu kompromisów, których nie należy ignorować. Wreszcie, nie ma czegoś takiego jak uniwersalny serwer WWW, więc wybierz opcję, która odpowiada Twoim potrzebom.