Eng onverännert Versioun vun dësem Artikel gouf ursprénglech publizéiert op an hei mat hirer Erlaabnis publizéiert .
Ech soen Iech an enger Nossschuel wéi Dir am beschten PHP-FPM konfiguréieren fir den Duerchgang ze erhéijen, d'Latenz ze reduzéieren an d'CPU an d'Erënnerung méi konsequent ze benotzen. Par défaut ass d'PM (Prozess Manager) Linn an PHP-FPM dynamesch, a wann Dir net genuch Erënnerung hutt, dann ass et besser ze installéieren op Ufro. Loosst eis 2 Kontrolloptiounen op Basis vun der php.net Dokumentatioun vergläichen a kucken wéi mäi Favorit vun hinnen ënnerscheet Statesch ass pm fir Héichvolumen Traffic:
pm = dynamesch - d'Zuel vun de Kannerprozesser gëtt dynamesch konfiguréiert op Basis vun den folgenden Direktiven: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand - Prozesser ginn op Nofro erstallt (am Géigesaz zu dynamescher Kreatioun, wann pm.start_servers lancéiert ginn wann de Service ufänkt).
pm = statesch - d'Zuel vun de Kannerprozesser ass fixéiert a gëtt vum Parameter uginn pm.max_Kanner.
Fir Detailer, kuckt .
Ähnlechkeeten tëscht dem PHP-FPM Prozessmanager an dem CPU Frequenzkontroller
Dëst kann offtopic schéngen, mee ech wäert dëst op d'Thema vun PHP-FPM Configuratioun Link. Wien huet net op d'mannst eemol e Prozessor verlangsamen erlieft - op engem Laptop, virtueller Maschinn oder dedizéierten Server. Erënneren CPU Frequenz Skala? Dës Optioune sinn fir nix a Windows kënnen d'Systemleistung an d'Reaktiounsfäegkeet verbesseren andeems d'Prozessor Drossel-Astellung geännert gëtt op Ufro op Leeschtung *. Dës Kéier, loosst eis d'Beschreiwunge vergläichen an d'Ähnlechkeeten kucken:
Gouverneur = ondemand - dynamesch Skaléierung vun der Prozessorfrequenz ofhängeg vun der aktueller Belaaschtung. Spréngt séier op maximal Frequenz a reduzéiert se dann wéi Perioden vun Inaktivitéit eropgoen.
Gouverneur=konservativ= dynamesch Frequenzskaléierung ofhängeg vun der aktueller Belaaschtung. Erhéicht a reduzéiert d'Frequenz méi glat wéi op Ufro.
Gouverneur = Leeschtung - Frequenz ass ëmmer maximal.
Fir Detailer, kuckt .
Gesinn d'Ähnlechkeeten? Ech wollt dëse Verglach weisen fir Iech ze iwwerzeegen datt et am beschten ass ze benotzen pm statesch fir PHP-FPM.
Fir de Prozessor regulator Parameter Leeschtung hëlleft d'Performance sécher ze erhéijen, well et bal ganz ofhängeg vun der CPU Limit vum Server ass. Zousätzlech zu dësem ginn et natierlech och Faktore wéi Temperatur, Batterieladung (an engem Laptop) an aner Nebenwirkungen fir de Prozessor stänneg op 100% ze lafen. D'Performance Astellung garantéiert déi schnellsten Prozessor Leeschtung. Liesen, zum Beispill, iwwer , mat deem d'RPi Panel de Reguléierer benotzt Leeschtung, wou d'Leeschtungsverbesserung méi bemierkbar ass wéinst der gerénger CPU Auergeschwindegkeet.
Benotzt pm statesch fir maximal Serverleistung z'erreechen
PHP-FPM Optioun pm statesch hänkt gréisstendeels vun der fräier Erënnerung um Server of. Wann d'Erënnerung niddereg ass, ass et besser ze wielen op Ufro oder dynamesch. Op der anerer Säit, wann Dir Erënnerung hutt, kënnt Dir de PHP-Prozessmanager iwwerhead vermeiden andeems Dir pm setzt Statesch ass op déi maximal Serverkapazitéit. An anere Wierder, wann alles gutt berechent ass, musst Dir etabléieren pm.statesch op de maximalen Volume vu PHP-FPM Prozesser déi ausgefouert kënne ginn, ouni Problemer mat niddereg Erënnerung oder Cache schafen. Awer net sou héich datt et d'Prozessoren iwwerwältegt an eng Rëtsch PHP-FPM Operatiounen accumuléiert fir auszeféieren.
Am Screenshot hei uewen huet de Server pm = statesch an pm.max_children = 100, an dat hëlt ongeféier 10 GB aus dem verfügbaren 32. Opgepasst op déi markéiert Sailen, hei ass alles kloer. An dësem Screenshot waren et ongeféier 200 aktive Benotzer (méi wéi 60 Sekonnen) an Google Analytics. Op dësem Niveau sinn ongeféier 70% vun PHP-FPM Kannerprozesser nach ëmmer idle. Dëst bedeit datt PHP-FPM ëmmer op de maximalen Betrag u Serverressourcen gesat gëtt onofhängeg vum aktuellen Traffic. En Idle Prozess waart op Traffic Peaks a reagéiert direkt. Dir musst net waarden bis pm wäert Kannerprozesser erstellen an se dann ofschléissen wann d'Period eriwwer ass pm.process_idle_timeout. Ech hunn de Wäert op ganz héich gesat pm.max_requestswell dëst en funktionnéierende Server ass ouni Gedächtnisleck an PHP. Dir kënnt installéieren pm.max_requests = 0 mat statesch wann Dir ganz zouversiichtlech an bestehend an zukünfteg PHP Scripten sinn. Awer et ass besser d'Skripte mat der Zäit nei auszeféieren. Setzt eng grouss Unzuel un Ufroen, well mir wëllen onnéideg pm Käschten vermeiden. Zum Beispill, op d'mannst pm.max_requests = 1000 - ofhängeg vun der Quantitéit pm.max_Kanner an d'Zuel vun Demanden pro Sekonn.
De Screenshot weist de Kommando , gefiltert duerch u (Benotzer) a PHP-FPM Benotzernumm. Nëmmen déi éischt 50 oder sou Prozesser ginn gewisen (ech hunn net genau gezielt), awer am Wesentlechen Top weist déi Top Statistiken déi an d'Terminalfenster passen. An dësem Fall sortéiert duerch % CPU (% CPU). Fir all 100 PHP-FPM Prozesser ze gesinn, fuert de Kommando:
top -bn1 | grep php-fpmWéini pm ondemand an dynamesch ze benotzen
Wann Dir pm benotzt dynamesch, Feeler wéi dës geschéien:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total childrenProbéiert de Parameter z'änneren, de Feeler wäert net fortgoen, wéi . An dësem Fall war de pm.min Wäert ze kleng, a well de Webverkéier sou vill variéiert an héich Peaks an déif Däller huet, ass et schwéier den pm adequat unzepassen dynamesch. Normalerweis gëtt pm benotzt op Ufro, . Awer dëst ass nach méi schlëmm, well op Ufro terminéiert Idle Prozesser op Null wann et wéineg oder guer kee Traffic ass, an Dir wäert ëmmer nach mat der Overhead vum Ännere vum Verkéier ophalen. Ausser Dir hutt natierlech eng rieseg Waardezäit festgeluecht. An dann ass et besser ze benotzen pm.statesch + héich Zuel pm.max_requests.
PM dynamesch a besonnesch op Ufro kann praktesch kommen wann Dir méi PHP-FPM Pools hutt. Zum Beispill, hutt Dir verschidde cPanel Konten oder verschidde Websäiten a verschiddene Poolen. Ech hunn e Server mat, soen, 100+ cpanel Konten an ongeféier 200 Domainen, an pm.static oder souguer dynamesch géif mech net retten. Alles wat Dir braucht hei ass op Ufro, No all, méi wéi zwee Drëttel vun Websäite kréien wéineg oder guer kee Verkéier, a mat op Ufro all Kand Prozesser falen aus, déi wäert eis vill Erënnerung spueren! Glécklecherweis hunn d'cPanel Entwéckler dëst gemierkt an de Wäert op Standard gesat op Ufro. Virdrun, wann de Standard war dynamesch, PHP-FPM war guer net gëeegent fir beschäftegt gedeelt Serveren. Vill hunn benotzt suPHP, well pm dynamesch verbraucht Erënnerung souguer mat Idle Poolen an cPanel PHP-FPM Konten. Wahrscheinlech, wann de Traffic gutt ass, wäert Dir net op engem Server mat enger grousser Zuel vu PHP-FPM Pools (shared Hosting) gehost ginn.
Konklusioun
Wann Dir PHP-FPM benotzt an Äre Traffic schwéier ass, Prozessmanager op Ufro и dynamesch fir PHP-FPM gëtt limitéiert Duerchgang wéinst hirem inherenten Overhead. Verstinn Äre System a konfiguréiert PHP-FPM Prozesser no der maximaler Serverkapazitéit. Éischte Set pm.max_Kanner ofhängeg vun der maximaler pm Benotzung dynamesch oder op Ufro, an Erhéijung dann dëse Wäert zu engem Niveau wou d'Erënnerung an Prozessor ouni iwwerlaascht Aarbecht wäert. Dir wäert feststellen, datt mat pm statesch, well Dir hutt alles an Erënnerung, Verkéier Spikes verursaache manner CPU Spikes iwwer Zäit, an Server an CPU Laascht Duerchschnëtt wäert Niveau aus. Déi duerchschnëttlech PHP-FPM Prozessgréisst hänkt vum Webserver ab a erfuerdert manuell Konfiguratioun, sou datt méi automatiséiert Prozessmanager sinn dynamesch и op Ufro - méi populär. Ech hoffen den Artikel war nëtzlech.
DUP Benchmark Chart bäigefüügt . Wann PHP-FPM Prozesser sinn an Erënnerung, Leeschtung Erhéijunge op Käschte vun Erënnerung Konsum wou se sëtzt a waarden. Fannt déi bescht Optioun fir Iech selwer.
Source: will.com