Strojenie wydajności Apache’a: MPM Modules

przez
  1. Apache Performance Tuning: Swap Memory
  2. Dostrajanie wydajności Apache: Moduły MPM
  3. Strojenie wydajności Apache’a: Dyrektywy MPM
  4. Dostrajanie wydajności Apache’a: Configuring MPM Directives
  5. How to Enable Piped Logging in Apache

Reading Time: 3 minutes

Kluczem do zrozumienia wydajności serwera Apache są zdecydowanie moduły MPM (Multiprocessing Modules). Moduły te określają podstawę tego, jak Apache radzi sobie z wieloprocesowością. Wieloprocesowość oznacza wykonywanie wielu operacji jednocześnie w systemie z wieloma centralnymi jednostkami obliczeniowymi (CPU Cores).

Istnieje wiele MPM do wyboru; jednak ten artykuł skupia się na najczęściej używanych modułach znalezionych w Liquid Web Linux opartych na serwerach VPS. Te moduły to:

  • MPM Prefork
  • MPM Worker
  • MPM Event
  • Inne MPM
  • Który MPM jest najlepszy?

MPM Prefork

Samoregulujący MPM Prefork wywodzi swoją nazwę od sposobu, w jaki rozwidla się lub kopiuje się w nowe identyczne procesy z wyprzedzeniem, aby czekać na przychodzące żądania. Niewątkowe podejście do wieloprocesowości oparte na procesach, MPM Prefork uruchamia Apache w pojedynczym głównym procesie macierzystym serwera. Ten rodzic jest odpowiedzialny za zarządzanie wszystkimi dodatkowymi serwerami potomnymi, które tworzą jego pulę serwerów. Podczas używania MPM Prefork, każdy serwer-dziecko obsługuje tylko pojedyncze żądanie. To skupienie zapewnia całkowitą izolację od innych żądań obsługiwanych na serwerze. MPM Prefork jest zwykle używany do zapewnienia kompatybilności, gdy wymagane są biblioteki/oprogramowanie niewątkowe, takie jak mod_php (DSO). Z punktu widzenia optymalizacji, MPM Prefork może być bardzo wybrakowany w porównaniu z rozwiązaniami wielowątkowymi, wymagając znacznie więcej zasobów, aby osiągnąć podobny poziom ruchu jak wielowątkowy MPM. Jest zasobochłonny ze względu na potrzebę tworzenia pełnych kopii Apache dla każdego żądania.

Uwaga:
Unikaj używania MPM Prefork kiedy tylko jest to możliwe. Jego niezdolność do dobrego skalowania przy zwiększonym ruchu szybko przerośnie dostępny sprzęt w większości konfiguracji systemowych.

MPM Worker

Hybrydowy pre-forking, wielowątkowy, wieloprocesowy serwer WWW. W ten sam sposób jak MPM Prefork, MPM Worker używa tego samego podejścia z jednym głównym procesem nadrzędnym zarządzającym wszystkimi dziećmi w swojej puli serwerów. Jednakże, w przeciwieństwie do MPM Prefork, te dzieci są procesami wielowątkowymi, które mogą obsługiwać dziesiątki wątków (żądań) jednocześnie. MPM Worker stworzył podstawy dla wielowątkowego przetwarzania w serwerach Apache, które stały się stabilne w Apache 2.2. Konfiguracja wątkowa pozwala Apache’owi z łatwością obsłużyć setki żądań zachowując w pamięci tylko kilkanaście procesów potomnych. MPM Worker jest zarówno rozwiązaniem o wysokiej wydajności jak i niskim zapotrzebowaniu na zasoby dla web service.

Uwaga
Dyrektywa KeepAliveTimeOut obecnie definiuje ilość czasu, przez jaki Apache będzie czekał na żądania. Kiedy używasz KeepAlive z MPM Worker używaj najmniejszego KeepAliveTimeout jak to tylko możliwe (najlepiej 1 sekunda).

MPM Event

Oparty na kodzie źródłowym MPM Worker, MPM Event dzieli dyrektywy konfiguracyjne z MPM Worker. Działa niemal identycznie jak MPM Worker, z wyjątkiem obsługi żądań KeepAlive. MPM Event używa dedykowanego wątku Listener w każdym procesie potomnym. Ten wątek Listening jest odpowiedzialny za kierowanie przychodzących żądań do dostępnego wątku worker. Wątek Listening rozwiązuje problem napotkany przez MPM Worker, który blokuje całe wątki w oczekiwaniu na KeepAliveTimeout. Podejście Listener w MPM Event zapewnia, że wątki robotnicze nie „utknęły” w oczekiwaniu na wygaśnięcie KeepAliveTimeout. Ta metoda utrzymuje maksymalną ilość wątków robotniczych obsługujących tak wiele żądań, jak to tylko możliwe.

Informacje o limicie serwera

Wskazówka:
MPM Event jest stabilny w Apache 2.4, starsze wersje mogą używać MPM Worker jako alternatywy.

Inne MPM

Dostępny jest asortyment dodatkowych MPM. Są one zazwyczaj częścią integracji Apache’a z systemami operacyjnymi innymi niż Unix. Mają one specyficzne MPM, które są wymaganiami lub wykorzystują Apache na ich odpowiednich typach systemów. Te typy MPM są poza zakresem tego artykułu. Możesz znaleźć więcej informacji na temat specyficznych MPM w sekcji MPM Defaults oficjalnej dokumentacji Apache.

Uwaga:
Rekomendujemy trzymanie się z dala od eksperymentalnych i niestabilnych MPM. Niepewna natura tego typu oprogramowania sprawia, że nie można ich wspierać.

Który MPM jest najlepszy?

Podczas rozważań nad optymalizacją, istotne jest zrozumienie, że nie ma czegoś takiego jak uniwersalna konfiguracja Apache. Prawidłowy wybór MPM wymaga analizy wielu ruchomych zmiennych, takich jak ruch, kod strony, typ serwera, PHP Handler i dostępny sprzęt. Każdy serwer jest wyjątkowy, co czyni najlepszy MPM całkowicie subiektywnym wyborem.

Jeśli kod twojej aplikacji nie obsługuje wielowątkowości, wtedy twoim wyborem będzie MPM Prefork, wyłącznie na zasadzie kompatybilności. MPM Prefork zawiera moduły oprogramowania takie jak mod_php (DSO). MPM Worker bez KeepAlive sprawdza się bardzo dobrze, jeśli twoja aplikacja jest wysokowydajnym systemem API z równoważeniem obciążenia. Skalowalność i elastyczność MPM Event jest solidnym wyborem dla hostingu wielu małych i średnich witryn w konfiguracji hostingu współdzielonego.

Większość prostych konfiguracji serwerów działa dobrze pod samozarządzającą się domyślną konfiguracją MPM Event, co czyni ją idealnym punktem wyjścia do optymalizacji. Po dokonaniu wyboru, MPM może przejść do Configuration Directives aby sprawdzić, które ustawienia odnoszą się do wydajności i optymalizacji serwera. Lub sprawdź nasz poprzedni artykuł z tej serii, Strojenie wydajności Apache: Swap Memory.

Nawigacja w serii << Poprzedni artykułNastępny artykuł >>

Dodaj komentarz