Átállás mod_php-ról PHP-FPM-re – miért időszerű, és miért maradt ennyi ideig a régi út?
A PHP futtatási módja az elmúlt húsz évben többször változott, de a rendszergazdai beidegződések lassabban mozognak. Aki valaha telepített LAMP szervert, annak reflexből ugrik be a mod_php, hiszen évtizedekig ez volt a módszer: egyszerű, kiszámítható, az Apache-ba integrált.
A modern webkörnyezet viszont már mást vár: elkülönített processzeket, jobb memóriakezelést, rugalmas terheléselosztást. Itt jön be a képbe a PHP-FPM, amely ma már a legtöbb disztribúciónak a természetes alapja – gyakran úgy, hogy a felhasználók még mindig mod_php-t futtatnak, mert „eddig is jó volt”.
Ez a cikk egy tisztességes, technikailag átgondolt átállást mutat be, valamint azt is, hogy miért érdemes szakítani a mod_php-val, és miért maradhatott ennyi ideig alapértelmezett opció.
Miért jobb a PHP-FPM?
Külön processz – külön felelősség
A PHP-FPM saját processzt futtat, teljesen függetlenül az Apache-tól. Ha a PHP megakad, az nem rántja magával a webkiszolgálót.
Jobb skálázhatóság
A FPM pool jól szabályozható:
- külön felhasználó,
- külön memóriahatárok,
- külön processz-szám.
Ez különösen akkor értékes, amikor több PHP-alapú alkalmazást futtatsz egy rendszeren.
Gyorsabb és takarékosabb
Az Apache modern MPM-jei (mpm_event, mpm_worker) sokkal jobban működnek statikus tartalmaknál, de ezek összeegyeztethetetlenek voltak mod_php-val.
A FPM-mel viszont bármelyik MPM használható → az Apache kevesebb memóriát fogyaszt, és jobban bírja a párhuzamos terhelést.
Biztonságosabb elkülönítés
Alkalmazásonként külön FPM pool: külön jogok, külön PHP beállítások.
Ez a klasszikus „egy WordPress egy webszerveren” módnál kevésbé hangsúlyos, de céges környezetben valós előny.
Akkor miért maradt ilyen sokáig a mod_php?
Tradíció és egyszerűség
A mod_php volt:
- a legegyszerűbb,
- a legtöbb tutorialban szereplő,
- azonnal működő megoldás.
A régi LAMP cikkek, Debian/Ubuntu dokumentációk, sőt még sok régi CMS telepítési leírás is erre épült. Megjegyzem a mod_php fejlesztése 2020 óta stagnál.
A „ha működik, ne piszkáld” attitűd
Rengeteg szerver futott stabilan mod_php-val, évekig újraindítás nélkül.
Nem volt égető kényszer váltani, egészen addig, amíg a modern webalkalmazások és a terhelési igények mást nem diktáltak.
A disztribúciók lassú átállása
A PHP-FPM régóta erősebb konstrukció, de a disztribúciók:
- nem akarták egyik napról a másikra megszokás ellenében tolni az új modellt,
- kompatibilitás miatt sokáig meghagyták mod_php-t telepíthető opcióként.
Mára a helyzet megfordult: az FPM de facto szabvány, a mod_php pedig inkább a kompatibilitás kedvéért maradt meg.
Gyakorlati átállás – az a bizonyos egyperces műtét
Debian/Ubuntu rendszeren az átállás tényleg nem bonyolult. Íme a teljes parancssor, amely a mod_php-ról PHP-FPM-re vált:
sudo apt install php-fpm
sudo a2dismod php8.3
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event proxy proxy_fcgi setenvif
sudo a2enconf php8.3-fpm
sudo systemctl restart apache2.service
Mit csinál mindez?
- telepíti az FPM-et,
- engedélyezi a szükséges modulokat,
- aktiválja a disztribúció által előkészített FPM Apache-konfigurációt,
- kikapcsolja mod_php-t és a régi prefork MPM-et,
- visszaállítja / megerősíti az event alapú MPM-et,
- újraindítja az Apache-t, immár PHP-FPM-mel.
Zárszó – miért érdemes ma már így csinálni?
A PHP-FPM egy tisztes iparosmunka eredménye: kiszámíthatóbb, rugalmasabb és gazdaságosabb lett tőle a PHP-futtatás.
A mod_php hosszú ideig szolgált jól, de a modern web világában már kevésbé illeszkedik a működési modellhez.