Jak wybrać, którego Apache MPM użyć?

To jest kanoniczne pytanie dotyczące wyboru odpowiedniego serwera Apache httpd MPM.

Jestem trochę zdezorientowany między różnymi MPM oferowanymi przez Apache - „pracownik”, „wydarzenie”, „prefork” itp.

Jakie są główne różnice między nimi i jak mogę zdecydować, który będzie najlepszy dla danego wdrożenia?

Istnieje szereg modułów MPM (moduły Multi-Processing), ale zdecydowanie najbardziej powszechnie stosowane (przynajmniej na platformach * nix) to trzy najważniejsze z nich: prefork, worker, i event. Zasadniczo reprezentują ewolucję serwera WWW Apache oraz różne sposoby, w jakie serwer został zbudowany do obsługi żądań HTTP w ramach ograniczeń czasowych w swojej długiej (pod względem oprogramowania) historii.

prefork

mpm_preforkjest… cóż… jest kompatybilny ze wszystkim. Oddziela szereg procesów potomnych do obsługi żądań, a procesy potomne obsługują tylko jedno żądanie na raz. Ponieważ proces serwera tam siedzi, jest gotowy do działania i nie musi zajmować się zbieraniem wątków, jest tak naprawdę szybszy niż bardziej nowoczesne MPM z wątkami, gdy masz do czynienia tylko z jednym żądaniem na raz - ale cierpią jednocześnie, ponieważ muszą czekać w kolejce, aż proces serwera będzie wolny. Ponadto, próbując zwiększyć liczbę procesów potomnych przygotowanych wcześniej, łatwo zassiesz trochę poważnej pamięci RAM.

Prawdopodobnie nie zaleca się używania prefabrykatów, chyba że potrzebujesz modułu, który nie jest bezpieczny dla wątków.

Użyj jeśli: Potrzebujesz modułów, które psują się, gdy używane są wątki, np mod_php. Nawet wtedy rozważ użycie FastCGI i php-fpm.

Nie używaj, jeśli: Twoje moduły nie przerywają wątków.

worker

mpm_workerużywa wątkowania - co stanowi dużą pomoc dla współbieżności. Pracownik odwraca niektóre procesy potomne, które z kolei wydzielają wątki potomne; podobnie jak prefork, niektóre zapasowe wątki są w miarę możliwości gotowe do obsługi połączeń przychodzących. Takie podejście jest o wiele milsze w przypadku pamięci RAM, ponieważ liczba wątków nie ma bezpośredniego wpływu na użycie pamięci, tak jak liczba serwerów w przygotowaniu. Obsługuje również współbieżność znacznie łatwiej, ponieważ połączenia muszą tylko czekać na wolny wątek (który zwykle jest dostępny) zamiast zapasowego serwera w przygotowaniu.

Użyj, jeśli: korzystasz z Apache 2.2 lub 2.4 i korzystasz głównie z protokołu SSL.

Nie używaj, jeśli: Naprawdę nie możesz się pomylić, chyba że potrzebujesz wstępnego przygotowania do kompatybilności.

Pamiętaj jednak, że stopnie są dołączone do połączeń, a nie do żądań - co oznacza, że ​​połączenie podtrzymujące zawsze utrzymuje wątek do momentu jego zamknięcia (co może trwać długo, w zależności od konfiguracji). Dlatego mamy ..

event

mpm_eventstrukturalnie jest bardzo podobny do pracownika; właśnie został przeniesiony ze statusu „eksperymentalnego” do „stabilnego” w Apache 2.4. Dużą różnicą jest to, że używa dedykowanego wątku do obsługi utrzymywanych połączeń i przekazuje żądania do wątków potomnych tylko wtedy, gdy żądanie zostało faktycznie wykonane (pozwalając tym wątkom na zwolnienie kopii zapasowej natychmiast po zakończeniu żądania). Jest to świetne w przypadku współbieżności klientów, którzy niekoniecznie wszyscy są aktywni jednocześnie, ale okazjonalnie wysyłają żądania i kiedy klienci mogą mieć długi limit czasu podtrzymania aktywności.

Wyjątkiem są tutaj połączenia SSL; w takim przypadku zachowuje się identycznie jak pracownik (przyklejanie danego połączenia do danego wątku, dopóki połączenie nie zostanie zamknięte).

Użyj jeśli: korzystasz z Apache 2.4 i lubisz wątki, ale nie lubisz, gdy wątki oczekują na bezczynne połączenia. Wszyscy lubią wątki!

Nie używaj, jeśli: Nie korzystasz z Apache 2.4 lub potrzebujesz wstępnej wersji dla kompatybilności.

W dzisiejszym świecie slowlori , AJAX i przeglądarek, które lubią multipleksować 6 połączeń TCP (oczywiście z utrzymaniem aktywności) do serwera, współbieżność jest ważnym czynnikiem wpływającym na poprawienie skalowania i skalowania serwera. Historia firmy Apache ma to pod tym względem i chociaż nadal nie jest ona na równi z takimi jak nginx lub lighttpd pod względem wykorzystania zasobów lub skali, jasne jest, że zespół programistów pracuje nad zbudowaniem serwera WWW, który nadal jest istotny w dzisiejszym świecie współbieżności.

Oto dobre wyjaśnienie tego, jak działa z gifami:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

W skrócie: jeśli używasz 2.4 i potrzebujesz httpd jako zwrotnego proxy (dyspozytora), więc twój wybór to Event MPM

Od lutego 2018 r. Dokumentacja Apache 2.4 dla Event MPM stwierdza, że ​​użycie Apache jako serwera proxy uniemożliwi poprawioną obsługę połączeń, ponieważ 2.4.24 nie będzie działać zgodnie z przeznaczeniem. Zobacz sekcję Ograniczenia .

Problem polega na tym, że jako serwer proxy pracownik nie może określić, gdzie jest koniec odpowiedzi, i będzie musiał poczekać, aż cała odpowiedź zostanie wyświetlona, ​​zanim zwróci kontrolę nad odbiornikiem.

Z tego powodu wydaje się, że użycie modelu Worker może być najlepszym rozwiązaniem, gdy apache jest używany jako serwer proxy. Nie jest dla mnie do końca jasne, czy model zdarzeń ma zalety w środowisku proxy, ale być może są.

Głównie zależy od tego, które moduły Apache chcesz użyć. Myślę, że pracownik jest zazwyczaj domyślnym wyborem, ale niektóre (starsze) moduły wymagają rozwidlenia i zależą od preforków.

Jeśli nie masz preferencji, radzę wybrać preferowaną zależność od dystrybucji systemu operacyjnego. Na przykład Ubuntu domyślnie instaluje mpm-worker podczas instalacji Apache2.