Multi-Processing Modules (MPMs)

botond küldte be 2019. 10. 22., k – 19:40 időpontban

Tartalom

 

Ismertető

Az Apache HTTP szervert rugalmas és hatékony webszervernek tervezték, amely nagyon sokféle platformon képes működni különféle környezetekben. A különböző platformok és környezetek gyakran eltérő funkciókat igényelnek, vagy ugyanannak a szolgáltatásnak a különböző módon történő megvalósítását teszik szükségessé a leghatékonyabb működés érdekében. Moduláris felépítésének köszönhetően a webmestereknek lehetőségük van kiválasztani, hogy mely szolgáltatások működjenek a kiszolgálón, és hogy ezek fordítási időben, vagy futási időben kerüljenek betöltésre.

Az Apache 2.0 változata kiterjeszti ezt a moduláris felépítést a webszerver legalapvetőbb funkcióira. A szerver különféle modulokat tartalmaz, amelyek több gyermekfolyamatot indítva hatékonyabban tudják kiszolgálni a beérkező kéréseket (Multi-Processing Modules, MPM). Ezek a modulok felelősek a számítógép hálózati portjaihoz történő kapcsolódásért, a kérések fogadásáért és a gyermek processzek (child process) elindításáért, amik aztán kezelik a beérkező kéréseket.

Felhasználói szinten az MPM-ek úgy jelennek meg, mint ahogyan az Apache többi modulja. A fő különbség az, hogy az MPM modulok közül egy és egyszerre csak egy MPM-nek mindig be kell lennie töltve a szerverre.

 

 

Előnyök

A moduláris felépítés a kiszolgáló ezen szintjére történő kiterjesztésének két fontos előnye van:

  • Az Apache HTTPd sokkal tisztábban és hatékonyabban támogatja az operációs rendszerek széles választékát. A szervernek különösen a Windows verziója lett hatékonyabb, mivel az mpm_winnt natív hálózati funkciókat használhat a korábbi Apache HTTPd 1.3-ban használt POSIX réteg helyett. Ez az előny kiterjed más operációs rendszerek esetére is, amelyek speciális MPM-eket használnak.
  • A szerver jobban testre szabható a rajta futtatott webhelyek igényeihez. Például azoknál a webhelyeknél, amelyeknek nagy skálázhatóságra van szükségük, használhatók a több szálon futó MPM-ek, mint például a Worker, vagy az Event, míg a régi szoftverekkel való nagyobb fokú kompatibilitást igénylő webhelyekhez pedig célszerűbb a régebbi Prefork MPM-et választani.

Ismert MPM-ek

Az Apache az alábbi MPM-eket különbözteti meg operációs rendszerek szerint:

  • Netware: mpm_netware
  • OS/2: mpmt_os2
  • Unix: mpm_prefork, mpm_worker, mpm_event
  • Windows: mpm_winnt

Az Unix alatt itt az Unix-szerű operációs rendszerek értendők, mint például a Linux, BSD, Solaris, Mac OS X, stb.

Az Unix-szerű rendszerek esetében a megfelelő MPM kiválasztásának a döntése két kérdésen alapul:

  1. Támogatja-e a rendszer szálak kezelését (threads) ?
  2. Támogatja-e a rendszer a szál-biztos lekéréseket (konkrétan a kqueue és az epoll funkciókat) ?

Ha mindkét kérdésre a válasz "igen", akkor a megfelelő MPM az Event. Ha az 1. kérdésre a válasz igen, de a másodikra nem, akkor a megfelelő MPM a Worker. Ha mindkét kérdésre a válasz "nem", akkor a megfelelő MPM a Prefork. A gyakorlatban pedig mindez azt jelenti, hogy a megfelelő MPM szinte mindig az Event lesz, mivel minden modern operációs rendszer támogatja ezt a két funkciót.

 

Linuxon működő MPM-ek bemutatása

Ahogy már ismeretes, az Apache a 2.0-ás verziójától kezdve többféle operációs rendszer számára is kínál különféle MPM megoldásokat. Ebben a fejezetben a Linuxon használható változatokat ismerhetjük meg közelebbről.

Az Apache 2.4-es verziója előtt csak a Prefork és a Worker MPM-ek voltak stabilként definiálva, míg az Event pedig még kísérleti állapotban volt. Majd az Apache 2.4-es verziójától már az Event MPM-et is stabilnak nyilvánították, így éles használatra is alkalmassá vált.

Prefork MPM

Ez a többprocesszes (vagy folyamatalapú) modul egy nem több szálon működő, "pre-fork" webszervert valósít meg. Minden szerverfolyamat egyetlen bejövő kérést tud kezelni, és egy szülő folyamat kezeli a szerverkészlet méretét. Ez a módszer megfelelő az olyan weboldalak számára, amelyeknek kompatibilitási okok miatt el kell kerülniük a szálak kezelését, hogy együttműködhessenek az olyan nem több szálon működő modulokkal, mint például a mod_php. Ez a legjobb MPM az egyes kérelmek elkülönítéséhez, melynek során az egyik kéréssel kapcsolatos probléma nem érinti a másikat.

A Prefork MPM nagyon önszabályzó, ezért ritkán kell módosítani a konfigurációs beállításait. A legfontosabb, hogy a MaxRequestWorkers értéke elég nagy legyen ahhoz hogy eleget tegyen annyi egyidejű kérésnek, amennyit a szerver várhatóan fogad, de elég kicsi ahhoz, hogy az összes szerverfolyamat elférjen a fizikai memóriában.

Az Apache megpróbál fenntartani több tartalék (spare servers) vagy tétlen szervert (idle servers), amelyek készen állnak a bejövő kérések kiszolgálására. Ilyen módon a klienseknek nem kell várniuk, amíg egy újabb gyermek folyamat létrejön, mielőtt a kéréseket kiszolgálják. Ezért is nevezik pre-fork-nak ezt az MPM-et.

Az Apache webkiszolgáló telepítésekor ez az alapértelmezetten használt MPM.

Kapcsolódó Apache modulok: mpm_prefork, php (vagy php7.0 / php7.2 / php7.3 telepített PHP-től függően)

Előnyök

  • A Prefork gyorsabb, ha nincsenek párhuzamos kérések a szerveren.
  • Kompatibilis a régebbi, nem több szálon működő modulokkal, mint például a mod_php.
  • A gyermek folyamatok (child processes) előre be vannak töltve a memóriába, így gyorsabb a kérések kiszolgálása.

Hátrányok

  • Egyszerre csak egy kérést tud feldolgozni egy időben.
  • Ennél fogva a Prefork lassabb, ha több, egyidejű kérés érkezik a szerverre (a gyakorlatban egy nagyobb forgalmú szerver esetén ez rendszeresen előfordulhat).
  • Erőforrás igényes. Minden szerverfolyamat számára le kell foglalni a szükséges fizikai memóriát.
  • Ha egy kérés CPU igényes, akkor könnyen feltorlódhatnak az utána lévő kérések
  • Nem támogatja a HTTP/2 protokollt.

 

 

Worker MPM

Ez a többfolyamatos MPM egy hibrid többfolyamatú és többszálú szervert valósít meg. A kérések kiszolgálásakor a szálak felhasználásával képes nagyszámú kérelem teljesítésére kevesebb rendszer erőforrással, mint egy folyamat-alapú (Prefork) szerver. Ugyanakkor megőrzi a folyamat-alapú szerverek stabilitását is, mivel több alfolyamatot fenntartva, mindegyik sok szállal rendelkezik.

A legfontosabb paramétere ennek az MPM-nek a ThreadsPerChild, amely az alfolyamatok során létrehozandó szálak számát szabályozza, és a MaxRequestWorkers, amely az összesen indítható szálak maximális számát szabályozza.

A Worker MPM megteremtette a többszálas, többfolyamatos feldolgozás alapját az Apache webkiszolgálókban, amely az Apache 2.2-es verziójától kezdve vált stabillá.

Kapcsolódó Apache modulok: mpm_worker, proxy_fcgi

Előnyök

  • Gyorsabb a Prefork MPM-nél, mert egyidejűleg több kérést tud feldolgozni. Ezáltal több látogatót tud kiszolgálni az ezzel működtetett weboldal.
  • Kompatibilis a HTTP/2 protokollal.

Hátrányok

  • Nem kompatibilis a nem több szálon működő modulokkal, mint például a mod_php.

Event MPM

Az Event MPM a korábbi, Worker MPM forráskódjára alapozva készült, így ugyanazokat a direktívákat használja, mint a Worker. Az Event MPM Szinte ugyanúgy működik, mint a Worker, kivéve, amikor a KeepAlive kérések kezelésére van szükség. Az MPM Event dedikált figyelő szálat (Listen thread) használ minden gyermekfolyamatban. Ez a figyelő szál felel a bejövő kérések egy elérhető Worker szálhoz irányításáért. Ez megoldja az MPM Worker problémáját, amely a teljes szálakat a KeepAliveTimeout várakozásra korlátozza. Az MPM Event Listener megközelítése biztosítja, hogy a Worker szálak ne maradjanak "beragadva", amíg a KeepAliveTimeout lejár. Ez a módszer megtartja a Worker szálak maximális mennyiségét, melyek így a lehető legtöbb kérelmet tudják kezelni.

Az Event MPM-et csak az Apache 2.4 verziójától felfelé tekintik stabil változatnak, a korábbi verziókban kísérleti jellegűnek tartották, és nem volt kompatibilis az Apache régebbi verzióinak néhány moduljával.

Kapcsolódó Apache modulok: mpm_event, proxy_fcgi

Előnyök

  • Gyorsabb a Prefork MPM-nél, mert egyidejűleg több kérést tud feldolgozni. Ezáltal több látogatót tud kiszolgálni az ezzel működtetett weboldal.
  • Gyorsabb és hatékonyabb a Worker MPM-nél is, mivel folyamatonként meglévő Listen szál segítségével a worker szálaknak nem kell megvárniuk a KeepAliveTimeout eseményt, ezáltal hamarabb tudják fogadni a következő kérést.
  • Kompatibilis a HTTP/2 protokollal.

Hátrányok

  • Nem kompatibilis a nem több szálon működő modulokkal, mint például a mod_php.
  • Az Apache 2.4 előtti verziókban még csak kísérleti állapotban volt, így ha régebbi webkiszolgálót használunk, akkor előfordulhatnak hibák (természetesen ma már mindenhol használható az Apache 2.4).

 

 

Váltás az MPM-ek között

Ha át szeretnénk váltani az aktuálisan használt MPM-ről egy másikra, akkor először meg kell tudni, hogy az Apache melyik verzióját és melyik MPM-et futtatja a szerver. Ezt az alábbi parancs segítségével lehet a legegyszerűbben lekérdezni:

apache2ctl -V | grep -i 'version\|mpm'
Server version: Apache/2.4.38 (Debian)
Server MPM:     event

Ebben a Debian 10-es példában tehát a szerver Egy 2.4.38-as Apache-ot futtat Event MPM-el.

Az átkapcsoláshoz először az a2dismod parancs segítségével ki kell kapcsolni az aktuális MPM-el kapcsolatos modulokat (fentebb, az MPM-eknél felsorolt modulok). Majd az a2enmod paranccsal pedig be kell kapcsolni a cél MPM szükséges moduljait. Végül újra kell indítani az Apache-ot.

Egy példa az MPM Prefork-ról MPM Eventre történő átkapcsolásra:

a2dismod php
a2dismod mpm_prefork
a2enmod mpm_event
a2enmod proxy_fcgi
systemctl restart apache2

A modulok kapcsolgatása közben a rendszer tájékoztat a különböző függőségi problémákról, amik a megfelelő modulok ki-és bekapcsolása után rendeződnek.