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]
Plikowa czy URI interpretacja
Serwer WWW interpretuje żądania i mapuje je do rzeczywistych zasobów w systemie, ale jest jeszcze jeden obszar, w którym te dwa serwery różnią się.
Apache
Apache daje możliwość interpretowania żądania jako zasobu fizycznego w systemie plików lub jako lokalizacji URI, które mogą wymagać bardziej abstrakcyjnej oceny. Generalnie, w przypadku tych pierwszych Apache używa bloki <Directory> lub <Files>, a jednocześnie wykorzystuje blok <Location> do bardziej abstrakcyjnych zasobów.
Ponieważ Apache został zaprojektowany od podstaw jako serwer WWW, domyślnie zazwyczaj interpretuje żądania jako zasoby systemu plików. Zaczyna się od wyciągania pliku konfiguracyjnego i dodania do części zapytania numer hosta i port, aby spróbować znaleźć rzeczywisty plik. Zasadniczo, hierarchia systemu plików jest reprezentowana w sieci WWW jako drzewo dokumentu.
Apache udostępnia szereg alternatyw w przypadku, gdy wniosek nie jest zgodny z systemem plików bazowych. Na przykład, dyrektywa Alias może być stosowana do mapowania w innej lokalizacji. Za pomocą bloku <Location> jest metoda pracy z samym URI zamiast systemu plików. Istnieją również regularne opcje wyrażeń, które mogą być używane do bardziej elastycznej konfiguracji w całym systemie plików.
W tym czasie jak Apache ma możliwość pracować w głównym systemie plików i przestrzeni WWW, jest mocno skierowany w stronę metod systemu plików. Można to zobaczyć w niektórych rozwiązaniach projektowych, w tym z wykorzystaniem .htaccess plików do konfiguracji katalogu konfiguracyjnego. Apache docs same ostrzegają przed stosowaniem bloków opartych na URI, aby ograniczyć dostęp, gdy żądanie odtwarza podstawowy system plików.
Nginx
Nginx został stworzony dla serwera WWW i serwera proxy. Ze względu na architekturę dla tych dwóch ról, działa głównie URIs, tłumacząc w systemie plików, gdy jest to konieczne.
Można to zobaczyć w niektórych ze sposobów, przez które pliki konfiguracyjne Nginx są budowane i interpretowane. Nginx nie zapewnia mechanizm do określania konfiguracji dla katalogu systemu plików i zamiast tego analizuje sam URI.
Na przykład, podstawowymi blokami konfiguracyjnymi dla Nginx są serwer albo rozmieszczone bloki. Serwer interpretuje host który jest wymagany, w czasie gdy rozmieszczone bloki są odpowiedzialne za dopasowanie części URI, która przychodzi po hostu i portu. W tym momencie, żądanie jest interpretowane jako identyfikator URI, a nie jako lokalizacja w systemie plików.
W przypadku plików statycznych, wszystkie żądania w końcu muszą być przypisane do lokalizacji w systemie plików. Najpierw Nginx wybiera serwer i rozmieszczenie bloków, które będą obsługiwać żądania, a następnie łączy główny dokument z URI, dostosowując wszystko niezbędne zgodnie z określoną konfiguracją.
W przypadku plików statycznych, wszystkie żądania w końcu muszą być przypisane do lokalizacji w systemie plików. Najpierw Nginx wybiera serwer i rozmieszczenie bloków, które będą obsługiwać żądania, a następnie łączy główny dokument z URI, dostosowując wszystko niezbędne zgodnie z określoną konfiguracją.
To może wydawać się podobnym, ale przede wszystkim analizowanie żądania jako URIs zamiast lokalizacji systemu plików pozwala Nginx aby łatwiej funkcjonować jak WWW, poczta, serwer proxy. Nginx jest po prostu skonfigurowany przez układanie jak reagować na różne szablony zapytań. Nginx nie sprawdza system plików, dopóki nie jest gotowy, aby spełnić żądania, co wyjaśnia, dlaczego nie wykorzystuje formę .htaccess plików.
Moduły
Zarówno Nginx i Apache są rozszerzalne za pomocą systemów modułowych, ale sposób pracy znacznie się różni.
Apache
Modułowy system Apache pozwala na dynamiczne ładowanie i zwalnianie modułów w celu zaspokojenia swoich potrzeb w trakcie uruchamiania serwera. Jądro Apache jest zawsze obecne, podczas gdy moduły mogą być włączone lub wyłączone, dodając lub usuwając dodatkowe funkcje i podłączając się do głównego serwera.
Apache wykorzystuje tę funkcję do wielu różnych zadań. Ze względu na dojrzałość platformy, istnieje obszerna biblioteka dostępnych modułów. Mogą one być używane do zmiany niektórych podstawowych funkcji serwera, na przykład mod_php, co osadza interpretator PHP w każdym systemie pracownika.
Jednak moduły nie są ograniczone przetwarzaniem zawartości dynamicznej. Wśród innych funkcji, mogą być wykorzystane do przepisywania adresów URL, uwierzytelniania klientów, hartowania serwera, logowania, buforowania, kompresji, ograniczenia prędkości i szyfrowania. Moduły dynamiczne mogą znacznie rozszerzyć podstawową funkcjonalność bez dużej ilości dodatkowej pracy.
Nginx
Nginx również realizuje modułowy system, ale dość mocno różni się od systemu Apache. W Nginx moduły nie są ładowane dynamicznie, więc muszą być wybrane i opracowane w jądrze oprogramowania.
Dla wielu użytkowników to sprawi wrażenie, że Nginx jest mniej elastyczny. Jest to szczególnie ważne dla użytkowników, którym nie jest wygodne zachowanie własnego skompilowanego oprogramowania poza tradycyjnym systemem pakowania ich dystrybucji. Chociaż dystrybucyjne pakiety zazwyczaj zawierają najczęściej używane modułe, jeżeli potrzebujesz niestandardowy moduł, musisz zbudować serwer z kodu źródłowego samodzielnie.
Moduły Nginx nadal są bardzo przydatne, one pozwalają dyktować co chcesz zrobić z serwerem, tylko poprzez włączenie funkcjonalności którą zamierzasz użyć. Niektórzy użytkownicy mogą również to uważać za bardziej bezpieczne, tak jak dowolne elementy nie mogą być podłączone do serwera. Jednak, jeśli Twój serwer był kiedykolwiek postawiony w takiej sytuacji, gdzie jest to możliwe, prawdopodobnie on jest już zagrożony.
Moduły Nginx mają wiele takich samych możliwości jak moduły Apache. Na przykład, moduły Nginx mogą zapewnić wsparcie proxy, kompresje, ograniczenia prędkości, logowanie, przepisywanie, geolokalizacja, uwierzytelnianie, szyfrowanie transmisji i pocztę.
Wsparcie, kompatybilność, ekosystem, i dokumentacja
Głównym punktem do rozważenia jest to że sam proces uzyskiwania i uruchomienia będzie miał dostępną pomoc i wsparcie wśród innych programów.
Apache
Ponieważ Apache jest bardzo popularny przez długi czas, wsparcie dla serwera jest dość powszechne. Istnieje duża biblioteka dokumentacji dostępnej dla serwera podstawowego i dla scenariuszy na podstawie zadań związanych z połączeniem Apache z innym oprogramowaniem.
Wraz z dokumentacją, wiele narzędzi i projektów internetowych obejmują narzędzia do uruchomienia w środowisku Apache. To może być zawarte w samych projektach lub w pakietach, które są obsługiwane przez zespół pakowania dystrybucji projektów.
Apache w ogóle będzie miał większe wsparcie ze strony innych projektów, ze względu na jego udział w rynku i ilość czasu, on został dostępny. Administratorzy również nieco częściej mają doświadczenie w pracy z Apache nie tylko ze względu na jego powszechności, ale również dlatego, że wiele osób zaczynają pracować na współdzielonym hostingu, który prawie zawsze polega na Apache kosztem .htaccess możliwości rozproszonego sterowania.
Nginx
Nginx odczuwa większe wsparcie, ponieważ więcej użytkowników przyjmie go profil wydajności, ale nadal ma pewne zaległości do nadrobienia w niektórych kluczowych obszarach.
W przeszłości trudno było znaleźć obszerną dokumentację w języku angielskim dotyczącą Nginx ze względu na fakt, że większość z wczesnego rozwoju i dokumentacji były w języku rosyjskim. Ponieważ zainteresowanie projektem wzrosła, dokumentacja została wypełniona, a obecnie istnieje mnóstwo zasobów administracyjnych na miejscu Nginx oraz za pośrednictwem osób trzecich.
W odniesieniu do aplikacji innych firm, wsparcie i dokumentacja stają się coraz bardziej dostępne, pojawiają się obsługujący pakietów, w niektórych przypadkach, w celu uzyskania możliwości wyboru między autokonfiguracji dla Apache i Nginx. Nawet bez wsparcia, konfiguracja Nginx do pracy z alternatywnym oprogramowaniem jest zwykle prosta, tak długo jak sam projekt dokumentuje swoje wymagania (uprawnienia, nagłówki, itp.)
Korzystanie wspólnie Apache z Nginx
Po przeglądaniu zalet oraz wad Apache i Nginx, możesz mieć lepsze wyobrażenie o tym, jaki serwer jest bardziej odpowiedni dla twoich potrzeb. Jednak, wielu użytkowników uważa że jest możliwe aby wykorzystać zalety każdego serwera poprzez używanie ich razem.
Typowa konfiguracja dla tego partnerstwa jest umieszczenie Nginx przed Apache jako reverse proxy. To pozwoli Nginx obsłużyć wszystkie przychodzące żądania od klientów. To ma przewagę szybkości przetwarzania dla Nginx i zdolność do obsługi dużej liczby połączeń jednocześnie.
Dla statycznej treści która przoduje w Nginx, pliki zostaną szybko i bezpośrednio podawane do klienta. Dla dynamicznej treści, na przykład pliki PHP, Nginx będzie wysyłać proxy żądanie do serwera Apache, który może następnie przetwarzać wyniki i zwracać na wyświetlanej stronie. Nginx może następnie przekazać zawartość z powrotem do klienta.
Taka konfiguracja jest wygodna dla wielu użytkowników, ponieważ umożliwia funkcjonowanie Nginx jako maszyny sortującej. Będzie on obsługiwać wszystkie żądania i przekaże to, że nie ma wrodzonej zdolności do obsługiwania. Poprzez ograniczenie żądań serweru Apache zadawanych w obsłudze, możemy złagodzić niektóre z blokadą, która występuje, gdy proces Apache lub wątek jest zajęty.
Taka konfiguracja pozwala także na skalowanie poprzez dodanie dodatkowych wewnętrznych serwerów w razie potrzeby. Nginx może być skonfigurowany tak, aby przejść do dodatkowych serwerów łatwo,zwiększając odporność tej konfiguracji na porażkę i wydajności.
Wniosek
Jak widać, zarówno Apache i Nginx są potężne, elastyczne i zdolne. Podejmując decyzje, jaki serwer jest najlepszy dla Ciebie, zależy w dużej mierze od oceny konkretnych wymagań i testowanie za pomocą szablonów, które można oczekiwać, aby zobaczyć.
Istnieją różnice między tymi projektami, które mają bardzo realny wpływ na wydajność, możliwości i terminy realizacji, niezbędne do uzyskania poszczególnych decyzji. Jednak te są zazwyczaj wynikiem szeregu kompromisów, które nie powinny być przypadkowo opuszczone. W końcu, nie ma jednego uniwersalnego serwera WWW, użyj rozwiązanie, które najlepiej odpowiada Twoim celom.
Przejdź do poprzedniej części poradnika Apache lub Nginx: Praktyczne rozważania – Część 1