Tämän artikkelin muokkaamaton versio julkaistiin alun perin ja julkaistu täällä hänen luvalla .
Kerron sinulle pähkinänkuoressa, kuinka PHP-FPM voidaan parhaiten määrittää suorituskyvyn lisäämiseksi, viiveen vähentämiseksi ja suorittimen ja muistin johdonmukaisemmaksi käyttämiseksi. Oletusarvoisesti PHP-FPM:n PM (prosessinhallinta) -rivi on dynaaminen, ja jos sinulla ei ole tarpeeksi muistia, on parempi asentaa OnDemand. Verrataan kahta ohjausvaihtoehtoa php.net-dokumentaation perusteella ja katsotaan kuinka suosikkini eroaa niistä staattinen pm vilkkaalle liikenteelle:
pm = dynaaminen — aliprosessien määrä konfiguroidaan dynaamisesti seuraavien ohjeiden perusteella: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand - Prosesseja luodaan pyynnöstä (toisin kuin dynaaminen luominen, kun pm.start_servers käynnistetään palvelun käynnistyessä).
pm = staattinen — alatason prosessien määrä on kiinteä ja se ilmoitetaan parametrilla pm.max_children.
Katso lisätietoja .
Samankaltaisuudet PHP-FPM-prosessinhallinnan ja CPU-taajuusohjaimen välillä
Tämä saattaa tuntua offtopicilta, mutta linkitän tämän aiheeseen PHP-FPM konfigurointi. Kukapa ei ole kokenut prosessorin hidastumista ainakin kerran – kannettavalla tietokoneella, virtuaalikoneella tai erillisellä palvelimella. Muistatko suorittimen taajuuden skaalauksen? Nämä vaihtoehdot ovat käytettävissä nix ja Windows voivat parantaa järjestelmän suorituskykyä ja reagointikykyä muuttamalla prosessorin kaasuasetusta OnDemand päälle esitys*. Tällä kertaa verrataan kuvauksia ja katsotaan yhtäläisyyksiä:
kuvernööri=ondemand — prosessorin taajuuden dynaaminen skaalaus nykyisen kuormituksen mukaan. Hyppää nopeasti maksimitaajuudelle ja vähentää sitä sitten, kun toimettomuusjaksot lisääntyvät.
kuvernööri=konservatiivi= dynaaminen taajuuden skaalaus nykyisen kuormituksen mukaan. Lisää ja laskee taajuutta tasaisemmin kuin ondemand.
Kuvernööri = suorituskyky – taajuus on aina maksimi.
Katso lisätietoja .
Näetkö yhtäläisyydet? Halusin näyttää tämän vertailun vakuuttaakseni, että sitä on parasta käyttää pm staattinen PHP-FPM:lle.
Prosessorin säätimen parametrille suorituskyky auttaa turvallisesti lisäämään suorituskykyä, koska se on lähes täysin riippuvainen palvelimen suorittimen rajoituksesta. Tämän lisäksi on tietysti myös tekijöitä, kuten lämpötila, akun lataus (kannettavassa tietokoneessa) ja muita sivuvaikutuksia, jotka liittyvät prosessorin jatkuvaan 100% toimintaan. Suorituskykyasetus varmistaa prosessorin nopeimman suorituskyvyn. Lue esim , jonka kanssa RPi-paneeli käyttää säädintä suorituskyky, jossa suorituskyvyn parannus on havaittavampi prosessorin alhaisen kellonopeuden vuoksi.
Käytä pm staticia palvelimen maksimaalisen suorituskyvyn saavuttamiseksi
PHP-FPM vaihtoehto pm staattinen riippuu pitkälti palvelimen vapaasta muistista. Jos muisti on vähissä, on parempi valita OnDemand tai dynaaminen. Toisaalta, jos sinulla on muistia, voit välttää PHP-prosessinhallinnan yleiskustannukset asettamalla pm staattinen palvelimen enimmäiskapasiteettiin. Toisin sanoen, jos kaikki on laskettu hyvin, sinun on perustettava pm.staattinen PHP-FPM-prosessien enimmäismäärään, joka voidaan suorittaa, luomatta ongelmia vähäisen muistin tai välimuistin kanssa. Mutta ei niin korkea, että se ylikuormittaisi prosessorit ja kerää joukon PHP-FPM-toimintoja, jotka odottavat suorittamista.
Yllä olevassa kuvakaappauksessa palvelimella on pm = staattinen ja pm.max_children = 100, ja tämä vie noin 10 Gt käytettävissä olevasta 32:sta. Kiinnitä huomiota korostettuihin sarakkeisiin, kaikki on selvää täällä. Tässä kuvakaappauksessa oli noin 200 aktiivista käyttäjää (yli 60 sekuntia) Google Analyticsissa. Tällä tasolla noin 70 % PHP-FPM:n lapsiprosesseista on edelleen käyttämättömänä. Tämä tarkoittaa, että PHP-FPM on aina asetettu palvelinresurssien enimmäismäärään nykyisestä liikenteestä riippumatta. Joutoprosessi odottaa liikenteen huippuja ja reagoi välittömästi. Sinun ei tarvitse odottaa, kunnes pm luo aliprosesseja ja lopettaa ne sitten, kun ajanjakso umpeutuu pm.process_idle_timeout. Asetin arvon erittäin korkeaksi pm.max_requestskoska tämä on toimiva palvelin, jossa ei ole muistivuotoja PHP:ssä. Voit asentaa pm.max_requests = 0 staticin kanssa, jos olet täysin varma olemassa olevista ja tulevista PHP-skripteistä. Mutta on parempi ajaa skriptit uudelleen ajan myötä. Aseta suuri määrä pyyntöjä, koska haluamme välttää turhia pm-kuluja. Esimerkiksi ainakin pm.max_requests = 1000 - määrästä riippuen pm.max_children ja pyyntöjen määrä sekunnissa.
Kuvakaappauksessa näkyy komento , suodatetaan u (käyttäjä) ja PHP-FPM-käyttäjätunnuksen perusteella. Vain noin 50 ensimmäistä prosessia näytetään (en laskenut tarkasti), mutta pääosin top näyttää tärkeimmät tilastot, jotka mahtuvat pääteikkunaan. Tässä tapauksessa lajiteltu % CPU:n mukaan (%CPU). Näet kaikki 100 PHP-FPM-prosessia suorittamalla komennon:
top -bn1 | grep php-fpmMilloin käyttää pm ondemand ja dynaaminen
Jos käytät pm dynaaminen, tapahtuu tällaisia virheitä:
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 childrenYritä muuttaa parametria, virhe ei poistu, kuten . Tässä tapauksessa pm.min-arvo oli liian pieni, ja koska verkkoliikenne vaihtelee niin paljon ja sillä on korkeat huiput ja syvät laaksot, pm-arvoa on vaikea säätää riittävästi dynaaminen. Yleensä pm on käytössä OnDemand, . Mutta tämä on vielä pahempaa, koska OnDemand lopettaa käyttämättömät prosessit nollaan, kun liikennettä on vähän tai ei ollenkaan, ja joudut silti joutumaan liikenteen muuttamiseen. Ellei tietenkään aseta suurta odotusaikaa. Ja sitten on parempi käyttää pm.staattinen + korkea luku pm.max_requests.
PM dynaaminen ja erityisesti OnDemand voi olla hyödyllistä, jos sinulla on useita PHP-FPM-pooleja. Isännöit esimerkiksi useita cPanel-tilejä tai useita verkkosivustoja eri pooleissa. Minulla on palvelin, jossa on esimerkiksi yli 100 cpanel-tiliä ja noin 200 verkkotunnusta, ja pm.static tai jopa dynaaminen ei pelastaisi minua. Kaikki mitä tarvitset täällä on OnDemand, loppujen lopuksi yli kaksi kolmasosaa verkkosivustoista saa vähän tai ei ollenkaan liikennettä, ja OnDemand kaikki lapsiprosessit putoavat, mikä säästää meille paljon muistia! Onneksi cPanel-kehittäjät huomasivat tämän ja asettivat arvon oletusarvoon OnDemand. Aikaisemmin, kun oletusarvo oli dynaaminen, PHP-FPM ei sovellu kiireisille jaetuille palvelimille ollenkaan. Monet ovat käyttäneet suPHP, koska pm dynaaminen kulutti muistia jopa käyttämättömien poolien ja cPanel PHP-FPM -tilien kanssa. Todennäköisesti, jos liikenne on hyvää, sinua ei ylläpidetä palvelimella, jossa on suuri määrä PHP-FPM-pooleja (jaettu hosting).
Johtopäätös
Jos käytät PHP-FPM:ää ja liikenne on raskasta, prosessipäälliköt OnDemand и dynaaminen PHP-FPM:n suorituskyky on rajoitettu niiden luontaisten yleiskustannusten vuoksi. Ymmärrä järjestelmäsi ja määritä PHP-FPM-prosessit palvelimen enimmäiskapasiteetin mukaan. Ensimmäinen setti pm.max_children riippuen pm maksimikäytöstä dynaaminen tai OnDemand, ja nosta sitten tätä arvoa tasolle, jolla muisti ja prosessori toimivat ilman ylikuormitusta. Huomaat sen kanssa pm staattinen, koska sinulla on kaikki muistissa, liikennepiikit aiheuttavat vähemmän CPU-piikkejä ajan myötä ja palvelimen ja suorittimen kuormituksen keskiarvot tasoittuvat. Keskimääräinen PHP-FPM-prosessin koko riippuu verkkopalvelimesta ja vaatii manuaalisen konfiguroinnin, joten automatisoidumpia prosessien johtajia ovat dynaaminen и OnDemand - suositumpi. Toivottavasti artikkelista oli hyötyä.
UPD Vertailukaavio lisätty . Jos PHP-FPM-prosessit ovat muistissa, suorituskyky kasvaa muistin kulutuksen kustannuksella, missä ne istuvat ja odottavat. Löydä itsellesi paras vaihtoehto.
Lähde: will.com