Optimalisering van PHP-FPM vir hoë werkverrigting

PHP is oral en is waarskynlik die taal wat die meeste op die internetweb gebruik word.


Dit is egter nie presies bekend vir sy hoë werkverrigting nie, veral as dit kom by baie gelyktydige stelsels. En dit is die rede dat tale en knope (soos ek weet, dit is nie ‘n taal nie), vir sulke gespesialiseerde gebruiksake, Go en Elixir oorneem.

Dit gesê, daar is baie wat u kan doen om die PHP-prestasie op u bediener te verbeter. Hierdie artikel fokus op die php-fpm-kant van dinge, wat die natuurlike manier is om op u bediener op te stel as u Nginx gebruik.

As u weet wat php-fpm is, moet u gerus na die gedeelte oor optimalisering gaan.

Wat is php-fpm?

Nie baie ontwikkelaars is geïnteresseerd in die DevOps kant van die dinge, en selfs onder diegene wat dit doen, weet baie min wat aangaan onder die enjinkap. Interessant genoeg, as die blaaier ‘n versoek stuur na ‘n bediener met PHP, is dit nie PHP wat die punt vorm wat die eerste kontak is nie; in plaas daarvan is dit die HTTP-bediener, waarvan die belangrikste Apache en Nginx is. Hierdie “webbedieners” moet dan besluit hoe om aan PHP te koppel, en die versoektipe, data en opskrifte daaroor deur te gee.

Die versoek-antwoord-siklus in die geval van PHP (Beeldkrediet: ProinerTech)

In moderne PHP-toepassings is die ‘vind lêer’-gedeelte hierbo die index.php, wat die bediener is opgestel om alle versoeke te delegeer na.

Nou, hoe presies die webbediener wat met PHP verbind word, het ontwikkel, en hierdie artikel sou in ‘n lengte ontplof as ons al die snaakse raak. Ongeveer, in die tyd dat Apache oorheers het as die gekose webbediener, was PHP ‘n module wat in die bediener ingesluit is.

Dus, wanneer ‘n versoek ontvang is, sal die bediener ‘n nuwe proses begin, wat outomaties PHP insluit en dit laat uitvoer. Hierdie metode word mod_php genoem, kort vir “php as a module.” Hierdie benadering het sy beperkings gehad, wat Nginx met php-fpm te bowe gekom het.

In php-fpm is die verantwoordelikheid om PHP te bestuur, prosesse lê by die PHP-program binne die bediener. Met ander woorde, die webbediener (Nginx, in ons geval), gee nie om waar PHP is en hoe dit gelaai word nie, solank hy weet hoe om data daaruit te stuur en te ontvang. As u wil, kan u in hierdie geval aan PHP dink as ‘n ander bediener op sigself, wat sommige kinder-PHP-prosesse vir inkomende versoeke bestuur (dus, ons het die versoek om ‘n bediener te bereik, wat deur ‘n bediener ontvang is en aan ‘n bediener deurgegee is – redelik mal! :-P).

As u enige Nginx-instellings gedoen het, of selfs net daarin gepraat het, sal u op iets soos hierdie te staan ​​kom:

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

Die lyn waarin ons belangstel, is die volgende: fastcgi_pass unix: /run/php/php7.2-fpm.sock; wat aan Nginx sê om met die PHP-proses te kommunikeer via die sok met die naam php7.2-fpm.sock. Dus, vir elke inkomende versoek, skryf Nginx data deur middel van hierdie lêer en stuur dit terug na die blaaier nadat hy die uitset ontvang het.

Ek moet weereens beklemtoon dat dit nie die mees volledige of mees akkurate prentjie is van wat aangaan nie, maar dat dit heeltemal akkuraat is vir die meeste DevOps-take.

Met die eenkant, kom ons kyk wat ons tot dusver geleer het:

  • PHP ontvang nie direk versoeke wat deur blaaiers gestuur word nie. Webbedieners soos Nginx onderskep dit eers.
  • Die webbediener weet hoe om aan te sluit by die PHP-proses, en stuur alle versoekdata (plak letterlik alles oor) aan PHP deur.
  • Wanneer PHP klaar is met sy deel, stuur dit die antwoord terug na die webbediener, wat dit in die meeste gevalle terugstuur na die kliënt (of blaaier).

Of grafies:

Hoe PHP en Nginx saamwerk (Beeldkrediet: DataDog)

Geweldig tot dusver, maar nou kom die vraag oor miljoen dollar: wat presies is PHP-FPM?

Die “FPM” -deel in PHP staan ​​vir “Fast Process Manager”, wat net ‘n deftige manier is om te sê dat die PHP wat op ‘n bediener loop, nie ‘n enkele proses is nie, maar eerder ‘n paar PHP-prosesse wat veroorsaak word, beheerder en doodgemaak word. af deur hierdie FPM-prosesbestuurder. Dit is hierdie prosesbestuurder waarna die webbediener die versoeke deurgee.

Die PHP-FPM is ‘n hele konyngat op sigself. Voel dus vry om te ondersoek as u wil, maar vir ons doeleindes, sal dit baie verduideliking doen. ��

Waarom php-fpm optimaliseer??

So hoekom bekommerd wees oor al hierdie dans as dinge goed werk? Waarom moet u dinge nie net soos hulle is nie?.

Ironies genoeg is dit juis die advies wat ek gee vir die meeste gevalle. As u opset goed werk en geen buitengewone gebruiksgevalle het nie, gebruik dan die verstek. As u egter verder as ‘n enkele masjien wil skaal, is dit noodsaaklik om die maksimum van een uit te druk, aangesien dit die bedienersrekeninge in die helfte kan sny (of selfs meer!).

Nog ‘n ding om te besef is dat Nginx gebou is vir die hantering van groot werklading. Dit kan duisende verbindings tegelyk hanteer, maar as dit nie die geval is met u PHP-opstelling nie, gaan u net hulpbronne vermors, want Nginx sal moet wag totdat PHP klaar is met die huidige proses en die Vervolgens negatief negatiewe voordele wat Nginx gebou het!

Laat ons dus kyk wat ons presies sou verander as ons php-fpm wil optimaliseer.

Hoe om PHP-FPM te optimaliseer?

Die ligging van die konfigurasielêer vir php-fpm kan op die bediener verskil, dus u moet navorsing doen om dit op te spoor. U kan vindopdrag gebruik as dit op UNIX is. Op my Ubuntu is die pad /etc/php/7.2/fpm/php-fpm.conf. Die 7.2 is natuurlik die weergawe van PHP wat ek bestuur.

So lyk die eerste paar reëls van hierdie lêer:

;;;;;;;;;;;;;;;;;;;;;
; FPM-konfigurasie;
;;;;;;;;;;;;;;;;;;;;;

; Al die relatiewe paaie in hierdie konfigurasielêer is relatief tot die installering van PHP
; voorvoegsel (/ usr). Hierdie voorvoegsel kan dinamies verander word deur die
; ‘-p’ argument vanaf die opdragreël.

;;;;;;;;;;;;;;;;;;
; Wêreldwye opsies;
;;;;;;;;;;;;;;;;;;

[Globale]
; Pid-lêer
; Opmerking: die standaardvoorvoegsel is / var
; Standaardwaarde: geen
pid = /run/php/php7.2-fpm.pid

; Fout loglêer
; As dit ingestel is op "syslog", log word na syslogd gestuur in plaas daarvan om geskryf te word
; in ‘n plaaslike lêer.
; Opmerking: die standaardvoorvoegsel is / var
; Standaardwaarde: log / php-fpm.log
error_log = /var/log/php7.2-fpm.log

‘N Paar dinge moet onmiddellik voor die hand liggend wees: die lyn pid = /run/php/php7.2-fpm.pid vertel watter lêer die proses-ID van die php-fpm-proses bevat.

Ons sien ook dat /var/log/php7.2-fpm.log is waar php-fpm sy logboeke gaan stoor.

Voeg nog drie veranderlikes in hierdie lêer by:

emergency_restart_threshold 10
noodstop_interval 1m
proses_kontrol_timeout 10s

Die eerste twee instellings is versigtig en vertel die php-fpm-proses dat indien tien kinderprosesse binne ‘n minuut misluk, die hoof-php-fpm-proses homself weer moet begin.

Dit klink miskien nie robuust nie, maar PHP is ‘n kortstondige proses wat geheue uitlek, en dus, as u die hoofproses begin in gevalle van groot foute, kan u baie probleme oplos..

Die derde opsie, process_control_timeout, sê dat die kind prosesse moet wag vir nog baie tyd voordat die sein wat van die ouerproses ontvang word, uitgevoer word. Dit is nuttig in gevalle waar die kind se prosesse in die middel van iets is wanneer die ouerprosesse byvoorbeeld ‘n KILL-sein stuur. Met tien sekondes op hande het hulle ‘n beter kans om hul take af te handel en grasieus te vertrek.

Verbasend genoeg is dit nie die vleis van php-fpm-konfigurasie nie! Dit is omdat die php-fpm vir die bediening van webaansoeke ‘n nuwe reeks prosesse skep, wat ‘n aparte opset het. In my geval was die naam van die swembad www en die lêer wat ek wou redigeer was /etc/php/7.2/fpm/pool.d/www.conf.

Kom ons kyk hoe hierdie lêer begin:

; Begin ‘n nuwe swembad genaamd ‘www’.
; die veranderlike $ poel kan in enige richtlijn gebruik word en sal vervang word deur die
; swembadnaam (‘www’ hier)
[Www]

; Per swembadvoorvoegsel
; Dit is slegs van toepassing op die volgende riglyne:
; – ‘toegang.log’
; – ‘slowlog’
; – ‘luister’ (unixsocket)
; – ‘chroot’
; – ‘chdir’
; – ‘php_values’
; – ‘php_admin_values’
; As dit nie gestel is nie, is die globale voorvoegsel (of / usr) van toepassing.
; Opmerking: hierdie richtlijn kan ook relatief wees tot die globale voorvoegsel.
; Standaardwaarde: geen
; voorvoegsel = / pad / na / poele / $ swembad

; Unix gebruiker / groep prosesse
; Opmerking: die gebruiker is verpligtend. As die groep nie ingestel is nie, dan is die standaardgebruikersgroep
; sal gebruik word.
gebruiker = www-data
groep = www-data

‘N Vinnige blik aan die einde van die uittreksel hierbo los die raaisel van die rede waarom die bedienerproses as www-data verloop. As u probleme met die toestemming van lêers teëgekom het tydens die opstel van u webwerf, het u waarskynlik die eienaar of groep van die gids in www-data verander, waardeur die PHP-proses in staat is om in loglêers in te skryf en dokumente op te laai, ens..

Uiteindelik kom ons by die bron van die saak, die prosesbestuurder (pm) -instelling. Oor die algemeen sien u die standaard as iets soos dit:

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

Dus, wat beteken “dinamies”Hier bedoel? Ek dink dat die amptelike dokumente dit die beste verduidelik (ek bedoel, dit behoort al deel te wees van die lêer wat u redigeer, maar ek het dit hier gereproduseer, net indien dit nie so is nie):

; Kies hoe die prosesbestuurder die aantal kinderprosesse sal beheer.
; Moontlike waardes:
; staties – ‘n vaste aantal (pm.max_children) van kinderprosesse;
; dinamies – die aantal kinderprosesse word dinamies ingestel op grond van die
; volgende riglyne. Met hierdie prosesbestuur sal daar
; altyd ten minste 1 kinders.
; pm.max_children – die maksimum aantal kinders wat kan
; terselfdertyd lewendig wees.
; pm.start_servers – die aantal kinders wat met die aanvang van die onderneming geskep is.
; pm.min_spare_servers – die minimum aantal kinders in ‘ledig’
; staat (wag om te verwerk). As die nommer
; van ‘ledige’ prosesse is minder as dit
; nommer, dan word ‘n paar kinders geskep.
; pm.max_spare_servers – die maksimum aantal kinders in ‘ledig’
; staat (wag om te verwerk). As die nommer
; van ‘ledige’ prosesse is groter as dit
; nommer dan word sommige kinders doodgemaak.
; ondemand – geen kinders word by die begin geskep nie. Kinders sal gevurk word wanneer
; nuwe versoeke sal aansluit. Die volgende parameter word gebruik:
; pm.max_children – die maksimum aantal kinders wat
; kan terselfdertyd lewendig wees.
; pm.process_idle_timeout – Die aantal sekondes daarna
; ‘n ledige proses sal doodgemaak word.
; Opmerking: hierdie waarde is verpligtend.

Ons sien dus dat daar drie moontlike waardes is:

  • statiese: ‘N Vaste aantal PHP-prosesse sal gehandhaaf word, maak nie saak wat nie.
  • Dinamies: Ons moet die minimum en maksimum aantal prosesse spesifiseer wat php-fpm op enige gegewe tydstip lewendig sal hou.
  • op aanvraag: Prosesse word geskep en vernietig, wel, op aanvraag.

Dus, hoe maak hierdie instellings saak??

In eenvoudige terme, as u ‘n webwerf met min verkeer het, is die “dinamiese” instelling die meeste van die tyd ‘n vermorsing van hulpbronne. As jy aanvaar dat pm.min_spare_servers op 3 is, sal drie PHP-prosesse geskep en onderhou word, selfs al is daar geen verkeer op die webwerf nie. In sulke gevalle is ‘ondemand’ ‘n beter opsie, waardeur die stelsel kan besluit wanneer nuwe prosesse begin word.

Aan die ander kant sal webwerwe wat groot hoeveelhede verkeer hanteer of vinnig moet reageer, gestraf word in hierdie instelling. Die skep van ‘n nuwe PHP-proses, dit deel uitmaak van die swembad en die monitering daarvan, is ekstra koste wat die beste vermy word.

Deur pm = static te gebruik, word die aantal kinderprosesse reggestel, sodat die maksimum stelselhulpbronne gebruik kan word om die versoeke te bedien, eerder as om PHP te bestuur. As u wel hierdie roete gaan, moet u oppas dat dit die riglyne en slaggate het. ‘N Nogal digte, maar baie nuttige artikel daaroor hier.

Finale woorde

Aangesien artikels oor webprestasies oorloë kan veroorsaak of mense kan verwar, voel ek dat ‘n paar woorde in orde is voordat ons hierdie artikel sluit. Prestasietuning gaan net soveel oor raaiwerk en donker kuns as oor stelselkennis.

Selfs al ken u die php-fpm-instellings uiters, is sukses nie gewaarborg nie. As u geen idee gehad het oor die bestaan ​​van php-fpm nie, hoef u nie tyd daaraan te mors nie. Hou aan om te doen wat u reeds doen en gaan aan.

Vermy terselfdertyd die einde van ‘n prestasie-junkie. Ja, u kan nog beter presteer deur PHP van nuuts af te kompompeer en al die modules wat u nie gaan gebruik nie, te verwyder, maar hierdie benadering is nie goed genoeg in produksieomgewings nie. Die hele idee om iets te optimaliseer, is om na te gaan of u behoeftes verskil van die standaard (wat hulle selde doen!) En om kleiner veranderinge aan te bring.

As u nie gereed is om tyd te spandeer aan die optimalisering van u PHP-bedieners nie, kan u dit oorweeg om ‘n betroubare platform soos gebruik te maak Kinsta wat sorg vir prestasieoptimalisering en sekuriteit.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map