A PHP mindenhol megtalálható, és vitathatatlanul az az Internet által a legszélesebb körben alkalmazott nyelv.


Ugyanakkor nem ismert pontosan a nagy teljesítményű képességei miatt, különösen, ha nagyon erősen párhuzamos rendszerekről van szó. És ez az oka annak, hogy ilyen speciális felhasználási esetekben olyan nyelveket, mint a Node (igen, tudom, hogy ez nem egy nyelv), a Go és az Elixir veszik át.

Ennek ellenére van egy csomó tennivaló a PHP teljesítményének javításához a szerveren. Ez a cikk a dolgok php-fpm oldalára fókuszál, amely a szerver konfigurálásának természetes módja, ha Nginx-et használ.

Ha tudja, mi a php-fpm, nyugodtan ugorjon az optimalizálással foglalkozó szakaszra.

Mi a php-fpm??

Kevés fejlesztőt érdekli a DevOps a dolgok oldalán, és még azok között is, akik ezt teszik, nagyon kevés tudja, mi folyik a motorháztető alatt. Érdekes, hogy amikor a böngésző kérést küld egy PHP-t futtató kiszolgálónak, akkor nem az első kapcsolattartó a PHP; ehelyett a HTTP szerver, amelyek közül a legfontosabb az Apache és az Nginx. Ezeknek a „webszervereknek” akkor el kell dönteniük, hogyan kell csatlakozniuk a PHP-hez, és továbbítaniuk kell a kérés típusát, az adatokat és a fejléceket.

A kérés-válasz ciklus PHP esetén (Kép jóváírása: ProinerTech)

A modern PHP alkalmazásokban a fenti „fájl keresése” rész az index.php, amelyet a szerver úgy konfigurált, hogy minden kérést delegáljon a.

Most, hogy pontosan hogyan kapcsolódik a webszerver a PHP-hez, ez a cikk hosszan felrobban, ha beleszámolnánk az összes rosszindulatú dolgot. Durván szólva, abban az időben, amikor az Apache uralta a választott webszervert, a PHP egy modul volt a kiszolgálón belül.

Tehát, amikor egy kérés érkezett, a szerver új eljárást indít, amely automatikusan magában foglalja a PHP-t, és végrehajtásra készteti. Ezt a módszert mod_php néven hívták, rövidítve: „php as a module”. Ennek a megközelítésnek megvannak a korlátai, amelyeket Nginx legyőzött a php-fpm-rel.

A php-fpm-ben a PHP-kezelés felelőssége, a folyamatok a kiszolgálón belüli PHP-programra hárulnak. Más szavakkal, a webszerver (a mi esetünkben Nginx) nem törődik azzal, hogy hol van a PHP és hogyan töltődik be, mindaddig, amíg tudja, hogyan kell adatokat küldeni és fogadni tőle. Ha akarod, akkor ebben az esetben a PHP-re gondolhat, mint önmagában egy másik szerverre, amely kezeli a gyermek PHP egyes folyamatait a bejövő kérésekhez (tehát van egy kérés, amely egy kiszolgálóra érkezik, amelyet egy szerver fogadott és továbbított egy szerverre) – nagyon őrült! :-P).

Ha bármilyen Nginx beállítást elvégezett, vagy akár csak beletette őket, akkor valami ilyesmire találkozik:

hely ~ \ .php $ {
try_files $ uri = 404;
fastcgi_split_path_info ^ (. + \. php) (/.+) $;
fastcgi_pass unix: /run/php/php7.2-fpm.sock;
fastcgi_index index.php;
tartalmazza a fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;
}

A vonal, amelyben érdekel, a következő: fastcgi_pass unix: /run/php/php7.2-fpm.sock ;, amely megmondja az Nginxnek, hogy kommunikáljon a PHP folyamattal a php7.2-fpm.sock nevű aljzaton keresztül. Tehát minden bejövő kéréshez az Nginx adatokat ír ezen a fájlon keresztül, és a kimenet megérkezésekor visszaadja a böngészőhöz..

Még egyszer hangsúlyoznom kell, hogy ez nem a legteljesebb vagy legpontosabb kép arról, hogy mi folyik, de a legtöbb DevOps feladat esetében teljesen pontos.

Tekintsük félre az eddig megtanultakat:

  • A PHP nem veszi közvetlenül a böngészők által küldött kéréseket. Az olyan webszerverek, mint az Nginx, először elfogják ezeket.
  • A webszerver tudja, hogyan kell csatlakozni a PHP folyamathoz, és továbbítja az összes kérési adatot (szó szerint mindent átilleszt) a PHP-hez..
  • Amikor a PHP befejezi a részének elvégzését, akkor a választ vissza küldi a webszervernek, amely visszajuttatja az ügyféllel (vagy a legtöbb esetben böngészővel)..

Vagy grafikusan:

Hogyan működik együtt a PHP és az Nginx (Kép jóváírása: DataDog)

Eddig nagyszerű, de most felmerül a millió dolláros kérdés: mi is pontosan a PHP-FPM?

A PHP „FPM” része a „Fast Process Manager” kifejezést jelenti, ami csak egy képzeletbeli módszer annak kijelentésére, hogy a szerveren futó PHP nem egyetlen folyamat, hanem néhány olyan PHP folyamat, amelyet spawnolnak, vezérlnek és megölnek ki ezt az FPM folyamatmenedzser. A webszerver erre a folyamatkezelőre továbbítja a kéréseket.

A PHP-FPM önmagában egy teljes nyúllyuk, ezért nyugodtan fedezze fel, ha szeretné, de céljainkra ez a sok magyarázat megteszi. ��

Miért optimalizálja a php-fpm-et??

Akkor miért aggódni azért, mert ez a helyzet jól működik? Miért nem hagyja a dolgokat úgy, ahogy vannak.

Ironikus módon, pontosan ezt a tanácsot adom a legtöbb használati esetben. Ha a beállítás jól működik, és nincs rendkívüli felhasználási esete, akkor használja az alapértelmezéseket. Ha azonban egyetlen gépen kívül szeretne skálát választani, akkor elengedhetetlen a max kinyomtatása a számítógépről, mivel ez a szerverszámlákat felére (vagy még ennél is többre) csökkentheti..

Egy másik dolog, amit fel kell ismerni, hogy az Nginxet hatalmas munkaterhelés kezelésére építették. Képesek egyidejűleg több ezer kapcsolat kezelésére, de ha ez nem igaz a PHP beállításaira, akkor csak az erőforrások pazarlására lesz szükség, mivel az Nginx-nek meg kell várnia, hogy a PHP befejezze a jelenlegi eljárást, és elfogadja a ezután véglegesen negatív minden olyan előny, amelyet az Nginx épített!

Tehát, ebből az útból nézzük meg, hogy pontosan mit változtatunk meg a php-fpm optimalizálásakor.

Hogyan lehet optimalizálni a PHP-FPM-t??

A php-fpm konfigurációs fájl helye a kiszolgálón különbözhet, ezért a helymeghatározáshoz külön kutatást kell végeznie. Használhatja a find parancsot, ha a UNIX rendszeren van. Az Ubuntu-n az elérési út /etc/php/7.2/fpm/php-fpm.conf. A 7.2-es természetesen a PHP verziója, amelyet futtatok.

Így néz ki a fájl első néhány sora:

;;;;;;;;;;;;;;;;;;;;;
; FPM konfiguráció;
;;;;;;;;;;;;;;;;;;;;;

; A konfigurációs fájl összes relatív elérési útja a PHP telepítéséhez viszonyítva
; előtag (/ usr). Ezt az előtagot dinamikusan meg lehet változtatni a
; ‘-p’ argumentum a parancssorból.

;;;;;;;;;;;;;;;;;;
; Globális opciók;
;;;;;;;;;;;;;;;;;;

[globális]
; Pid fájl
; Megjegyzés: az alapértelmezett előtag a / var
; Alapértelmezett érték: nincs
pid = /run/php/php7.2-fpm.pid

; Hiba naplófájl
; Ha ez be van állítva "syslog", A naplót a syslogd-hez kell elküldeni, nem pedig írásba
; egy helyi fájlba.
; Megjegyzés: az alapértelmezett előtag a / var
; Alapértelmezett érték: log / php-fpm.log
error_log = /var/log/php7.2-fpm.log

Néhány dolognak azonnal nyilvánvalónak kell lennie: a pid = /run/php/php7.2-fpm.pid sor megmondja, hogy melyik fájl tartalmazza a php-fpm folyamat azonosítóját.

Azt is látjuk, hogy a /var/log/php7.2-fpm.log az, ahol a php-fpm tárolja a naplóit.

Adjon hozzá további három változót ehhez a fájlhoz:

vészhelyzeti_indítási_küszöb 10
sürgősségi_indítási_intervallum 1m
process_control_timeout 10s

Az első két beállítás óvatos, és azt mondják a php-fpm folyamatnak, hogy ha tíz gyermek folyamat egy perc alatt meghibásodik, akkor a fő php-fpm folyamatnak újra kell indulnia..

Lehet, hogy ez nem tűnik robusztusnak, de a PHP rövid élettartamú folyamat, amely memóriaszivárog, tehát a fő folyamat újraindítása nagy hiba esetén sok problémát megoldhat..

A harmadik lehetőség, a process_control_timeout, azt mondja a gyermek folyamatainak, hogy várjanak ennyi ideig, mielőtt végrehajtják a szülő folyamatból kapott jelet. Ez akkor hasznos, ha a gyermekfolyamatok valami közepén vannak, amikor a szülõi folyamatok például KILL jelet küldenek. Tíz másodperc elteltével nagyobb esélyük lesz arra, hogy elvégezzék feladataikat és kecsesen kilépjenek.

Meglepő módon nem ez a php-fpm konfiguráció húsa! Ennek oka az, hogy a webes kérések kiszolgálására a php-fpm új folyamatok készletet hoz létre, amelynek külön konfigurációja lesz. Az én esetemben a készlet neve www-nak bizonyult, és a szerkeszteni kívánt fájl az /etc/php/7.2/fpm/pool.d/www.conf volt..

Nézzük meg, hogy kezdődik ez a fájl:

; Indítson el egy új „www” nevű medencét.
; a változó $ pool felhasználható bármilyen irányelvben, és helyébe a
; medence neve (‘www’ itt)
[Www]

; Medencénként előtag
; Csak a következő irányelvekre vonatkozik:
; – ‘access.log’
; – „slowlog”
; – ‘hallgassa’ (unixsocket)
; – „chroot”
; – „chdir”
; – ‘php_values’
; – ‘php_admin_values’
; Ha nincs beállítva, akkor a globális előtag (vagy / usr) alkalmazandó.
; Megjegyzés: Ez az irányelv a globális előtaghoz viszonyítva is vonatkozhat.
; Alapértelmezett érték: nincs
előtag = / elérési út / a / pool / $ poolhoz

; Unix felhasználó / folyamatok csoportja
; Megjegyzés: A felhasználó kötelező. Ha a csoport nincs beállítva, akkor az alapértelmezett felhasználói csoport
; használva lesz.
felhasználó = www-data
csoport = www-adatok

A fenti részlet gyors áttekintése megoldja azt a rejtélyt, hogy a szerver folyamata miért működik www-data néven. Ha webhelyének felállításakor szembesült fájlokkal kapcsolatos engedélyezési problémákkal, akkor valószínűleg a könyvtár tulajdonosát vagy csoportját www-data-ra változtatta, így lehetővé téve a PHP-folyamat számára, hogy naplófájlokba tudjon írni és dokumentumokat feltölteni stb..

Végül megérkezzünk az ügy forrásához, a folyamatmenedzser (pm) beállításához. Az alapértelmezett beállításokat általában így fogja látni:

pm = dinamikus
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

Szóval, mit jelentdinamikusItt érted? Úgy gondolom, hogy a hivatalos dokumentumok ezt magyarázzák a legjobban (úgy értem, hogy ennek már részenek kell lennie a szerkesztett fájlnak, de itt reprodukáltam, csak akkor, ha nem):

; Válassza ki, hogy a folyamatkezelő hogyan vezérli a gyermekfolyamatok számát.
; Lehetséges értékek:
; statikus – rögzített szám (pm.max_children) a gyermekfolyamatokból;
; dinamikus – a gyermekfolyamatok száma dinamikusan van beállítva a
; a következő irányelveket. Ezzel a folyamatmenedzsmenttel lesz
; mindig legalább 1 gyerek.
; pm.max_children – a maximálisan elérhető gyermekek száma
; élj ugyanakkor.
; pm.start_servers – az indításkor létrehozott gyermekek száma.
; pm.min_spare_servers – az alapjárati gyermekek minimális száma
; állapot (feldolgozásra vár). Ha a szám
; Az “alapjárati” folyamatok kevesebb ennél
; számot, akkor néhány gyermek létrejön.
; pm.max_spare_servers – az alapjáratban élő gyermekek maximális száma
; állapot (feldolgozásra vár). Ha a szám
; Az „alapjárati” folyamatok ennél nagyobb
; akkor néhány gyermeket megölnek.
; ondemand – indításkor nem teremnek gyermekek. A gyerekek akkor válnak villára, amikor
; új kérelmek kapcsolódnak. A következő paraméter kerül felhasználásra:
; pm.max_children – a gyermekek maximális száma
; ugyanakkor életben is lehet.
; pm.process_idle_timeout – Az utóbbi másodpercek száma
; egy alapjárati folyamat meghal.
; Megjegyzés: Ez az érték kötelező.

Tehát látjuk, hogy három lehetséges érték létezik:

  • Statikus: A PHP folyamatok rögzített számát függetlenül attól tartják fenn.
  • Dinamikus: Meg kell határoznunk a folyamatok minimális és maximális számát, amelyeknek a php-fpm egy adott időpontban életben marad.
  • igény szerint: A folyamatokat igény szerint hozzák létre és megsemmisítik.

Szóval, hogy számítanak ezek a beállítások?

Egyszerűen fogalmazva: ha alacsony forgalmú weboldala van, akkor a „dinamikus” beállítás nagyrészt erőforrások pazarlása. Feltételezve, hogy a pm.min_spare_servers 3-ra van állítva, három PHP folyamat lesz létrehozva és karbantartva akkor is, ha nincs forgalom a webhelyen. Ilyen esetekben az „ondemand” jobb megoldás, ha hagyja, hogy a rendszer eldöntse, mikor indít új folyamatokat.

Másrészt az olyan webhelyek, amelyek nagy forgalmúak, vagy amelyeknek gyorsan reagálniuk kell, büntetésre kerülnek ebben a beállításban. Egy új PHP folyamat létrehozása, a készlet részévé tétele és a figyelemmel kísérése extra felesleget jelent, amelyet a legjobb elkerülni.

A pm = statikus használata rögzíti a gyermekfolyamatok számát, lehetővé téve a maximális rendszer erőforrások felhasználását a kérelmek kiszolgálására, ahelyett, hogy a PHP-t kezelné. Ha megteszi ezt az utat, vigyázz, hogy megvannak az iránymutatásai és a hibái. Meglehetősen sűrű, de nagyon hasznos cikk róla itt.

Záró szavak

Mivel a webes teljesítményről szóló cikkek háborúkat idézhetnek elő vagy zavarhatják az embereket, úgy érzem, hogy néhány szó helyes, mielőtt bezárnánk ezt a cikket. A teljesítmény-hangolás annyira a találgatásokra és a sötét művészetekre vonatkozik, mint a rendszer ismerete.

Még ha szívből is ismeri az összes php-fpm beállítást, a siker nem garantált. Ha fogalma sincs a php-fpm létezéséről, akkor nem kell pazarolnia az időt az aggodalomra. Csak folytasd azt, amit már csinálsz, és folytatd tovább.

Ugyanakkor kerülje az előadás-drogos játék végét. Igen, még jobb teljesítmény érhető el, ha a PHP-t újrafordítja a semmiből, és eltávolítja az összes olyan modult, amelyet nem használ, de ez a megközelítés nem elég ésszerű a termelési környezetben. Valamelyik optimalizálás célja az, hogy megvizsgálja, hogy az igényei eltérnek-e az alapértelmezettől (amit ritkán tesznek!), És szükség szerint végezzen kisebb módosításokat..

Ha még nem hajlandó időt költeni a PHP-kiszolgálók optimalizálására, akkor fontolhatja meg egy megbízható platform kihasználását, például Kinsta akik gondoskodnak a teljesítmény optimalizálásáról és biztonságáról.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me