5 Tapoja lisätä PHP suorituskykyä-Tideways

5 Tapoja lisätä PHP: n suorituskykyä

BONUS: olemme keskustelleet aiheesta PHP-yhteisön asiantuntijan kanssa podcastissamme:

pois sananparresta, box, PHP tarjoaa ihmisarvoisen suorituskyvyn. Kuitenkin, on olemassa useita asioita, että me, PHP kehittäjät ja järjestelmien ylläpitäjät, voi tehdä lisätä sen suorituskykyä entisestään; joskus lähes mitään vaivaa.

tässä viestissä aion astua läpi viisi niistä tavoista. Kun olet lopettanut lukemisen, sinun pitäisi nähdä ainakin merkittävä kasvu suorituskykyä PHP-sovelluksen. Aloitetaan.

käytä PHP 7

yksi parhaista tavoista parantaa PHP: n suorituskykyä on ajaa uusin versio (PHP 7). Se tarjoaa merkittävän nopeuden parannuksen aiempaan versioon verrattuna. Nyt tulokset vaihtelevat aina, sillä mikään kaksi hakemusta ei ole koskaan sama. Useiden eri kehittäjien ja merkittävien hosting-yritysten raporttien perusteella suorituskyvyn parannukset ovat kuitenkin merkittäviä.

tässä pieni otos:

• PHP: n viralliset vertailuarvot kertovat, että PHP 7 voi suorittaa kaksi kertaa niin monta pyyntöä sekunnissa kuin PHP 5.6.
• Kinstan PHP: n suorituskykyvertailut osoittavat, että WordPress 5.0 voi suorittaa 3x yhtä monta tapahtumaa kuin PHP 5.6; ja
• Pantheon ilmoitti, että PHP 7 antoi 64% parannuksen versioon 5.3 verrattuna.

jos se ei riitä sinulle, tarkista vertailukohtasi ja katso, mitä ne sanovat.

lisäksi PHP 7.0.0 julkaistiin 3. joulukuuta 2015, ja viimeisin vakaa versio, 7.3.6, julkaistiin 30.toukokuuta tänä vuonna.

What ‘ s more, PHP 5, 5.6, viimeinen julkaisu meni EOL (End of Life) 7 kuukautta sitten, 31.12.2018. Niin, jos et ole jo, se on hyvin ohi aika teit siirtymisen PHP 7. Tee päivitys ja, kuten Rasmus sanoi phpCE 2018: ssa, go green(er) vähentämällä hosting-kustannuksia.

Uninstall Xdebug

seuraavaksi tarkistetaan, että Xdebugia ei ole asennettu tuotantopalvelimille. Toki Xdebug on yksi kehittyneimmistä ja kattavimmista PHP: n profiloijista ja debuggereista, mutta sitä ei pitäisi koskaan ottaa käyttöön (edes asentaa) tuotantopalvelimelle, ainakaan ennen kuin Xdebug 3 on julkaistu ja sinun pitäisi liittyä meihin tukemaan Derickiä sen työstämisessä.

vaikka suorituskykyvertailut vaihtelevat (ne vaihtelevat aina), yksi raportti Stack Overflow ‘ sta osoitti 50%: n suorituskyvyn parantuneen poistamalla Xdebugin kokonaan. Lisäksi on tärkeää huomata, että vaikka Xdebug asennettiin palvelimelle — se ei ollut edes käytössä!

Xdebug performance benchmark

voit tarkistaa, onko se asennettu, suorita php -m | grep -i xdebug tai tarkista hosting-palveluntarjoajasi hallintopaneeli. Jos haluat tietää enemmän Xdebugin toiminnasta, tutustu Xdebugin dokumentaatioon.

Use Composer Optimize Autoloader

vaikka olemme kaikki todennäköisesti hyvin perehtynyt käyttämällä Composer käsitellä paketti hallinta meille, jos emme harkitse optimoimalla kokoonpano se luo, sovelluksemme eivät tule toimimaan niin hyvin kuin mahdollista.

tässä lainaus säveltäjän dokumentaatiosta, joka selittää miksi:

koska PSR-4 ja PSR-0 autoloading säännöt on perustettu, it-säveltäjän on tarkistettava tiedostojärjestelmä ennen luokan nimen ratkaisemista lopullisesti. Tämä hidastaa asioita melko vähän, mutta se on kätevä kehitysympäristöissä, koska kun lisäät uuden luokan, se voidaan heti löytää/käyttää ilman rakentaa autoloader kokoonpano.

suorituskyvyn parantamiseksi säveltäjä tarjoaa kolmea optimointitasoa; nämä ovat:

• Luokkakarttasukupolvi
• arvovaltaiset luokkakartat
• APCu-välimuisti

1: Class map generation

tämä strategia muuntaa PSR-4 / PSR-0-säännöt classmap-säännöiksi. Tämä strategia on nopeampi, koska classmap voi heti palauttaa koko polun tunnettuihin tiedostoihin ja välttää tiedostojärjestelmän stat-toiminnon.

tämän optimointitason mahdollistamiseksi suorita seuraava komento:

composer dump-autoload --optimize 

2/A: Arvovaltaiset luokkakartat

sen lisäksi, että taso 1 otetaan automaattisesti käyttöön tätä tasoa käytettäessä, jos luokka ei löydy luodusta luokkakartasta, autoladaaja ei yritä katsoa tiedostojärjestelmää PSR-4-sääntöjen mukaisesti. Jos haluat ottaa tämän optimointitason käyttöön, suorita seuraava komento:

composer dump-autoload --classmap-authoritative 

2/B: APCu-välimuisti

tämä taso lisää APCu-välimuistin luokkakartan varakartaksi. Kuitenkin, se ei luo classmap. Koska, taso yksi olisi otettava käyttöön manuaalisesti. Jos haluat ottaa tämän optimointitason käyttöön, suorita seuraava komento:

composer dump-autoload --apcu 

on olemassa kompromisseja

vaikka jokainen näistä tasoista voi parantaa sovelluksen suorituskykyä, niillä jokaisella on kompromisseja, jotka on ymmärrettävä ennen niiden käyttöä. Varmista, että tutustut säveltäjän dokumentaatioon ennen niiden käyttöä.

käytä opcachea

koska PHP on tulkattu, ei käännetty kieli, PHP: n suoritusaika täytyy muuntaa lähdekoodiksi suoritettavaksi tavukoodiksi, ennen kuin se voidaan suorittaa. Ja koska PHP on jaettu-Ei mitään arkkitehtuuri, tämä prosessi on tapahduttava jokaisen pyynnön.

opcache (opcache) – välimuistissa tämä vaihe tarvitsee kuitenkin tapahtua vain kerran jokaista tiedostoa kohti, sillä luodut Opcodet voidaan tallentaa välimuistiin jaettuun muistiin ja viitata siellä sen sijaan.

joten, kuten voitte kuvitella, OPcache on yksi vähiten intensiivisistä tavoista parantaa PHP-sovelluksen suorituskykyä, koska minkään koodin ei tarvitse muuttua. Joidenkin raporttien mukaan nopeus parani jopa 70 prosenttia.

PHP: lle on vuosien varrella ollut useita Opcode-välimuisteja. OPCache (aiemmin Zend Cache) on ollut nipussa PHP: n kanssa versiosta 5.5 lähtien — ja se on oletusarvoisesti käytössä PHP 7: ssä.

jos haluat tietää siitä enemmän, tutustu Opcachen dokumentaatioon. Tietää enemmän suorituskyvyn säätämistä OPcache, tutustu Hayden James ” erinomainen artikkeli sekä Tideway post tuning se.

käytä PHP 7: n esilatausta

jos et ole kuullut PHP 7.4: n uudesta esilatausominaisuudesta, se on silti hyvin siistiä! Pähkinänkuoressa, ominaisuus vie Opcache toiminnallisuutta pidemmälle kuin sen koskaan mennyt ennen.

jotta PHP-lähdetiedosto voidaan toistaa nopeasti ensimmäisen kerran, se on jäsenneltävä ja sitten käännettävä koneriippuvaiseksi bytecode-koodiksi, ennen kuin Zend-Moottori voi suorittaa sen. Opcaches vähentää merkittävästi tämän prosessin ylimenoa, sillä kun lähdekoodia ensimmäisen kerran jäsennetään ja kootaan alas, tavukoodit tallennetaan opcode-välimuistiin jaettuun muistiin.

seuraavan kerran, kun kyseistä tiedostoa pyydetään, PHP tarkistaa, onko Opcode-välimuistissa tiedostolle bytekoodeja. Jos niin käy, ne palautetaan ja käytetään. Jos ei (tai jos lähdetiedosto on muuttunut sen jälkeen, kun bytekoodit koottiin), lähdetiedosto jäsennetään, kootaan ja tallennetaan välimuistiin. Tämä antaa merkittävän suorituskyvyn boost PHP.

nyt katsotaan, miten esilataus toimii. Lainatakseni täytäntöönpanevaa RFC: tä:

palvelimen käynnistyksessä-ennen kuin mitään sovelluskoodia suoritetaan – voimme ladata tietyn joukon PHP-tiedostoja muistiin-ja tehdä niiden sisällön “pysyvästi saataville” kaikkiin myöhempiin pyyntöihin, joita kyseinen palvelin palvelee. Kaikki näissä tiedostoissa määritellyt toiminnot ja luokat ovat saatavilla pyynnöille laatikosta, aivan kuten sisäiset yksiköt. Esilataus varmistaa, että:

• kaikki näissä tiedostoissa määritellyt toiminnot ja useimmat luokat Ladataan pysyvästi PHP: n funktio-ja luokkataulukoihin ja tulevat pysyvästi saataville tulevien pyyntöjen yhteydessä.
• PHP ratkaisee luokan riippuvuudet ja yhteydet vanhempaan, rajapintoihin ja piirteisiin (jotain, mitä ei tapahdu Opcode-välimuistissa).
• PHP poistaa tarpeettomat sisällöt ja suorittaa muita optimointeja.

kun kokonaisen sovelluksen koodi, mukaan lukien sen puitteet (kuten Zend Expressive, Symfony ja Laravel), ladataan muistiin, koodi, joka muuttui vain palvelimen uudelleenkäynnistyksessä, useimmat sovellukset toimivat huomattavasti paremmin.

sen mukaan esilatauksella on muutamia mahdollisia haittoja, joista sinun tulisi tietää:

• palvelimen uudelleenkäynnistys vaaditaan, kun lähdetiedostot muuttuvat.
• esilataus ei toimi jaetuissa hostausympäristöissä.
• esilataus ei toimi, kun samasta sovelluksesta on useita versioita.

esilataus ei ole maagista. Sekä koodisi että käyttöönottoprosessisi on muokattava uudelleen, jotta voit hyödyntää sitä. Esimerkiksi, joku on kehitettävä mukautetun loader script määrittää, mitkä tiedostot ladata palvelimen käynnistyksen, ja että script on suoritettava palvelimen käynnistyksen yhteydessä. Riippumatta, se on merkittävä parannus, yksi kannattaa investoida!

käytä Profiloijaa

nyt sellaiseen vaihtoehtoon, joka vaatii hieman enemmän työtä kuin mikään aiemmista viidestä. Usein hyppäämme mukaan ja yritämme arvata, missä sovellustemme suorituskyvyn pullonkaulat ovat, intuition ja valistuneiden arvausten avulla.

vaikka nämä voivat toimia, ne eivät ole tehokkaimpia lähestymistapoja. Sen sijaan voimme koodiprofiloijien avulla analysoida koodiamme ja näyttää, missä pullonkaulat ovat. Erityisesti ne auttavat vastaamaan esimerkiksi seuraaviin kysymyksiin:

• kuinka monta kertaa kutakin menetelmää kutsuttiin?
• mikä oli kunkin menetelmän suurin suoritusaika?
• mikä oli kunkin menetelmän keskimääräinen suoritusaika?
• kuinka monta kertaa tiedosto oli mukana?
• mikä polku pyyntö kulki sovelluksen kautta (ensimmäisestä viimeiseen kooditiedostoon)?

poraamalla profiloijan tuloksiin voit usein yllättyä iloisesti, joskin todennäköisemmin järkyttyä huomatessasi, että sovelluksesi toteuttaa koodipolkuja ja-luokkia, joita et koskaan odottanut.

profiloijaraportin tietojen perusteella sinä ja tiimisi voitte sitten alkaa ymmärtää paremmin, mitä sovelluksenne tekee, ja tehdä tietoon perustuvia refaktoreita sen muuttamiseksi tarpeen mukaan.

jos olet vasta aloittelemassa profilointia, PHP: lle on tarjolla useita vaihtoehtoja. Yleisimmin käytettyjä ovat:

• Xdebug ‘s profiler
• Tideway’ s XHProf extension (& XHGui)
• spx Profiler
• forp

in Conclusion

And these are five ways to improve the quality of your PHP applications notifically. Mikä tahansa niistä yksinään antaa sinulle merkittävän suorituskyvyn parantamisen. Yhdessä käytettynä kannattaa kuitenkin odottaa merkittävää suorituskykyä, laadusta puhumattakaan, parannusta.