Apache czy Nginx: Praktyczne rozważania – Część 1

Porównanie wydajności serwerów Apache oraz Nginx:

• Apache czy Nginx: Praktyczne rozważania [Część 1/2]
• Apache czy Nginx: Praktyczne rozważania [Część 2/2]

Apache i Nginx są dwa najpopularniejsze open source serwery WWW na świecie. One są odpowiedzialne za obsługę ponad 50% ruchu Internetowego. Oba rozwiązania są w stanie obsługiwać różne obciążenia i pracę z innym oprogramowaniem w celu zapewnienia pełnego stosu WWW.

W tym czasie jak Apache i Nginx mają wiele wspólnych cech, one nie powinny być traktowane jako całkowicie wymienne. Każdy wyróżnia się na swój własny sposób i ważne jest, aby zrozumieć sytuacje, w których może być konieczne ponownie ocenić wybór swego serwera WWW . Ten artykuł będzie poświęcony dyskusji o tym, jak każdy serwer działa w różnych dziedzinach.

Przegląd ogólny

Zanim zagłębimy się w różnice między Apache oraz  Nginx, rzućmy okiem na ich wspólne cechy.

Apache

Apache HTTP Server został stworzony przez Roba McCoola w 1995 roku i został opracowany pod kierunkiem Apache Software Foundation od 1999 roku. Ponieważ serwer WWW HTTP to autorski projekt Fundacji i jest zdecydowanie ich najpopularniejszym kawałkiem oprogramowania, często jest dalej po prostu nazywany  jako Apache.

Serwer WWW Apache jest najpopularniejszym serwerem w Internecie od 1996 roku. Z powodu takiej popularności, Apache korzysta z dużej ilości dokumentacji oraz zintegrowanego wsparcia ze strony innych projektów programistycznych.

Apache jest często wybierany przez administratorów za jego elastyczność, moc i szerokie poparcie. On może rozwijać się dzięki dynamicznie obciążanych modułów systemu i może obsługiwać wiele interpretacji języków bez podłączenia do oddzielnego oprogramowania.

Nginx

W 2002 roku Igor Sysoev rozpoczął pracę nad Nginx jako odpowiedź na problem C10K, który był problemem dla serwerów WWW, przetwarzanie dziesięciu tysięcy jednoczesnych połączeń jako wymóg dla nowoczesnych sieci. Pierwsza wersja publiczna została wykonana w 2004 roku, spełniając ten cel, opierając się na asynchroniczne zdarzenia zorientowanej architektury.

Popularność Nginx wzrosła od czasu jego wydania ze względu na jego lekkość i jego zdolności do łatwego skalowania na minimalnym sprzęcie. Nginx wyróżnia się w szybkiej obsłudze treści statycznej i jest przeznaczony do transmisji dynamicznych zapytań do innego oprogramowania, które lepiej nadaje się do tych celów.

Nginx jest często wybierany przez administratorów do jego efektywnego zarządzania zasobami i reagowania pod obciążeniem. Zwolennicy witają ostrość Nginx w sprawie podstawowych funkcji serwera WWW oraz proxy.

Połączenie Handling Architecture

Jedną wielką różnicą między Apache i Nginx jest ich sposób traktowania połączeń i ruchu. To zapewnia chyba najbardziej istotną różnicę w tym, jak reagują na różne warunki trafiku.

Apache

Apache udostępnia różne multi-procesowe moduły (Apache nazywa to jako MPMs), które określają jak żądania klientów są obsługiwane. Zasadniczo, to pozwala administratorom łatwo zamienić swoje połączenia manipulacyjną architekturę. To są:

• mpm_prefork :

Ten moduł przetwarzania generuje procesy z jednego wątku do obsługi każdego żądania. Dopóki liczba wniosków jest mniejsza niż liczba procesów, to MPM jest bardzo szybki. Jednak wydajność spada szybko po tym, jak wnioski przewyższają liczbę procesów, więc to nie jest dobry wybór w wielu scenariuszach. Każdy proces ma znaczący wpływ na zużycie RAM więc MPM trudno efektywnie skalować. To nadal może być dobrym rozwiązaniem, jeżeli są stosowane w połączeniu z innymi składnikami, które nie są zbudowane z wątków  w pamięci. Na przykład, PHP nie jest bezpieczny dla wątków, więc MPM jest zalecany jako jedyny bezpieczny sposób pracy z mod_php, który jako moduł Apache służy do przetwarzania tych plików.

• mpm_worker:

Ten moduł uruchamia procesy, w których każdy może zarządzać wieloma wątkami. Każdy z tych wątków może obsługiwać pojedyncze połączenie. Wątki są znacznie bardziej efektywne niż procesy. Ponieważ istnieje więcej wątków niż procesów, oznacza to również, że nowe połączenia mogą od razu skorzystać z wolnego wątku zamiast czekać wolnego procesu.

• mpm_event :

Moduł ten jest podobny do modułów pracy w większości sytuacji, ale jest zoptymalizowany do obsługi otwartych  połączeń. Podczas korzystania przez MPM, połączenie odbędzie się bez względu na to, czy wniosek jest aktywnie wykonany tak długo, jak połączenie jest utrzymywane przy życiu. Wydarzenie MPM obsługuje połączenia, utrzymywane przy życiu przez uchylenie dedykowanych wątków do obsługi połączeń, utrzymanych przy życiu, i przechodzących aktywnych żądań do innych wątków. To utrzymuje moduł od  ugrzęznąć przez żądania otwarte, co pozwala na szybszą realizację. To było zaznaczone stabilną wersją serwera Apache 2.4.

Jak widać, Apache zapewnia elastyczną architekturę wybierając różne algorytmy połączenia oraz żądania. Wybory przewidziane są głównie funkcją ewolucji serwera  i coraz rosnącym zapotrzebowaniem, paralelnie jak się zmieniła sytuacja dostępu do Internetu.

Nginx

Nginx wszedł na scenę po Apache, z większą świadomością problemów współbieżności, które spotykają strony w skali. Korzystając z tej wiedzy, Nginx został zaprojektowany od podstaw, aby korzystać z asynchronicznego,  niezablokowanego, zarządzanego zdarzeniami połączenia algorytmu przetwarzania.

Nginx uruchamia procesy robocze, z których każdy może obsłużyć tysiące połączeń. Procesy robocze to osiągają poprzez wdrożenie szybkiego mechanizmu pętli, który stale sprawdza i przetwarza zdarzenia. Oddzielenie rzeczywistej pracy od połączeń pozwala każdemu pracownikowi zajmować połączenie tylko wtedy, gdy nowe zdarzenie zostało wyzwolone.

Każde z połączeń, które są przetwarzane przez pracownika znajdują się w pętli zdarzeń, gdzie one istnieją z innymi związkami. Wewnątrz pętli zdarzenia są przetwarzane asynchronicznie, pozwalając aby praca była przetwarzana w niezablokowany sposób. Gdy połączenie zostanie zamknięte, zostanie ono usunięte z cyklu.

Statyczna czy dynamiczna treść

Pod względem rzeczywistych przypadków zastosowań, jednym z najbardziej popularnych porównań między Apache i Nginx jest sposób, w jaki każdy serwer obsługuje żądania dotyczące statycznej i dynamicznej treści.

Apache

Serwer Apache może obsługiwać statyczne treści, wykorzystując swoje zwykłe metody oparte na plikach. Realizacja tych działań zależy głównie od metod MPM, opisanych powyżej.

Apache może również obsługiwać dynamiczne treści, poprzez osadzenie procesora danego języka w każdym ze swoich robotniczych wystąpień. To umożliwia wykonywanie dynamicznych treści w obrębie samego serwera WWW, bez konieczności polegania na zewnętrzne komponenty. Te dynamiczne procesory można włączyć poprzez zastosowanie dynamicznie ładowanych modułów.

Zdolność Apache do obsługi treści dynamicznej wewnątrz oznacza, że konfiguracja dynamicznego przetwarzania jak zwykle będzie łatwiejsza. Związek nie musi być skoordynowany z dodatkową częścią oprogramowania i module mogą być łatwo zastąpione,  jeśli wymagania co do treści zmieniają się.

Nginx

Nginx nie ma zdolności do przetwarzania dynamicznej treści początkowo. Do obsługi PHP i innych zapytań z dynamiczną zawartością, Nginx musi przejść na zewnętrzny procesor do wykonania i czekać, aż wyświetlana treść zostanie wysłana z powrotem. Wyniki mogą być następnie przekazywane do klienta.

Dla administratorów oznacza to, że komunikacja musi być skonfigurowana między Nginx i procesorem przez jeden z protokołów Nginx (http, FastCGI, SCGI, uWSGI, memcache). To może nieco skomplikować sytuacje, zwłaszcza gdy próbujesz przewidzieć liczbę dozwolonych połączeń, jako dodatkowe połączenie będzie używane do każdego połączenia do procesora.

Jednak ta metoda ma także pewne zalety. Ponieważ dynamiczny interpretator nie jest wbudowany w proces,  jego koszty będą uczestniczyć tylko dla dynamicznej treści. Statyczna treść może być złożona w prosty sposób i interpretator będzie się kontaktować tylko w razie potrzeby. Apache może również funkcjonować w ten sposób, ale przy tym usuwa korzyści w poprzednim rozdziałe.

Rozdzielona czy centralna konfiguracja

Dla administratorów jedną najbardziej oczywisą różnicą między tymi dwoma częściami oprogramowania, czy konfiguracja katalogu poziomu jest dozwolona w katalogach treści.

Apache

Apache zawiera opcję umożliwienia dodatkowej konfiguracji na podstawie katalogu poprzez sprawdzanie i interpretacji dyrektywy w ukrytych plikach wewnątrz  samych katalogów treści. Pliki te są znane jako .htaccess pliki.

Ponieważ pliki te znajdują się wewnątrz samych katalogów treści podczas przetwarzania żądania, Apache sprawdza każdy składnik ścieżki do żądanego pliku .htaccess i stosuje dyrektywy, znajdujące się wewnątrz. Pozwala to skutecznie na zdecentralizowaną konfigurację serwera WWW, który jest często używany do realizacji przepisywania adresów URL, ograniczenia dostępu, autoryzacji i uwierzytelniania, nawet buforowanie polityki.

Chociaż w powyższych przykładach wszystko można ustawić w głównym pliku konfiguracyjnym serwera Apache, .htaccess pliki mają kilka ważnych zalet. Po pierwsze, ponieważ są one interpretowane za każdym razem, gdy znajdują się na drodze żądania, są realizowane natychmiast bez przeładowywania serwera. Po drugie, to sprawia, że można pozwolić nieuprzywilejowanych użytkownikom kontrolować niektóre aspekty własnej treści internetowej, nie dając im kontrolę nad całym plikiem konfiguracyjnym.

Zapewnia to łatwą drogę do określonego oprogramowania internetowego, podobnie jak systemy zarządzania treścią, aby skonfigurować swoje środowisko bez zapewnienia dostępu do centralnego pliku konfiguracyjnego. To jest również wykorzystywane przez dostawców usług hostingowych, aby zachować kontrolę nad podstawową konfiguracją, jednocześnie dając klientom kontrolę nad ich konkretnymi katalogami.

Nginx

Nginx nie interpretuje .htaccess plików, ani nie zawiera żadnego mechanizmu do oceny każdego katalogu konfiguracji spoza głównego pliku konfiguracyjnego. To może być mniej elastyczne niż model Apache, ale ma swoje zalety.

Najbardziej zauważalną poprawę w stosunku do .htaccess systemu konfiguracji katalogu poziomu zwiększa wydajność. Dla typowej konfiguracji Apache, który może umożliwić .htaccess w dowolnym katalogu, serwer będzie sprawdzać obecność tych plików w każdym z katalogów nadrzędnych, prowadzących do żądanego pliku dla każdego żądania. Jeśli jeden lub kilka .htaccess plików znajdują się w procesie wyszukiwania, muszą być odczytywane i interpretowane. Nie pozwalając zastąpienia katalogów, Nginx może obsługiwać żądania szybciej robiąc jedne wyszukiwanie katalogów i plików dla każdego żądania odczytu (zakładając, że plik znajduje się w konwencjonalnej strukturze katalogów).

Kolejną zaletą jest bezpieczeństwo. Dystrybucja dostępu do konfiguracji poziomu katalogu dystrybuuje również odpowiedzialność za bezpieczeństwo  dla użytkowników indywidualnych, którzy nie mogą być wiarygodne, aby poradzić sobie z tym zadaniem dobrze. Zapewnienie, że administrator kontroluje cały serwer WWW może zapobiec niektóre błędy bezpieczeństwa, które mogą wystąpić, gdy dostęp jest podana do innych osób.

Należy pamiętać, że możliwe jest wyłączenie .htaccess interpretacji w Apache, jeśli te problemy zdarzą się z Tobą.

Przejdź do następnej części poradnika Apache lub Nginx: Praktyczne rozważania – Część 2.