5 Måter Å Øke PHP Ytelse-Tideways

5 Måter å Øke PHP Ytelse

BONUS: VI har diskutert dette emnet med en ekspert I PHP samfunnet i vår podcast:

Ut av den velkjente, boksen, PHP gir anstendig ytelse. Det er imidlertid flere ting som VI, SOM PHP-utviklere og systemadministratorer, kan gjøre for å øke ytelsen enda lenger; noen ganger for nesten ingen innsats.

I dette innlegget skal jeg gå gjennom fem av disse måtene. Når du er ferdig med å lese, bør du se minst en merkbar økning i ytelsen TIL PHP-applikasjonen din. La oss begynne.

Bruk PHP 7

En av de beste måtene å forbedre PHP ytelse er å kjøre den nyeste versjonen (PHP 7). Det gir en betydelig hastighet forbedring over noen tidligere versjon. Nå vil resultatene alltid variere, da ingen to applikasjoner er like. Men basert på rapporter fra en rekke forskjellige utviklere og bemerkelsesverdige hostingfirmaer, er ytelsesforbedringene betydelige.

her er et lite utvalg:

• Offisielle PHP-referanser rapporterer AT PHP 7 kan utføre dobbelt så mange forespørsler per sekund sammenlignet MED PHP 5.6.
• Kinstas PHP performance benchmarks viser WordPress 5.0 kan utføre 3x så mange transaksjoner SOM PHP 5.6; og
• Pantheon rapporterte AT PHP 7 ga en 64% forbedring over versjon 5.3.

hvis det ikke er nok for deg, sjekk dine referanser og se hva de sier.

I Tillegg BLE PHP 7.0.0 utgitt 3. desember 2015, og den siste stabile versjonen, 7.3.6, ble utgitt 30. Mai i år.

hva mer, den endelige utgivelsen AV PHP 5, 5.6, gikk EOL (Slutten Av Livet) 7 måneder siden, På Desember 31, 2018. Så, hvis du ikke allerede har det, er det vel siste gang du har gjort overgangen TIL PHP 7. Gjør oppgraderingen og, Som Rasmus sa på phpCE 2018, gå grønn(er) ved å redusere hostingkostnadene dine.

Avinstaller Xdebug

den neste tingen å sjekke Er At Xdebug ikke er installert på produksjonsserverne dine. Jada, Xdebug Er En Av DE mest sofistikerte og omfattende profilere og debuggere FOR PHP, men det bør aldri være aktivert (selv installert) på en produksjon server, i hvert fall Til Xdebug 3 er utgitt, og du bør bli med oss i å støtte Derick å jobbe med det.

mens ytelsestestene varierer (de gjør det alltid), viste en rapport Om Stack Overflow en 50% ytelsesforbedring ved å fjerne Xdebug helt. Hva mer, er det viktig å merke seg At Selv Om Xdebug ble installert på serveren — det var ikke engang aktivert!

Xdebug performance benchmark

kjør php -m | grep -i xdebug eller sjekk administrasjonspanelet for vertsleverandøren din for å sjekke om den er installert. Og hvis Du vil vite mer om Hvordan Xdebug fungerer, sjekk ut xdebug-dokumentasjonen.

Bruk Composer Optimize Autoloader

mens Vi alle sannsynligvis er veldig kjent med Å bruke Composer til å håndtere pakkehåndtering for oss, hvis vi ikke vurderer å optimalisere konfigurasjonen den genererer, vil våre applikasjoner ikke fungere så godt som mulig.

her er et sitat fra komponistdokumentasjonen som forklarer hvorfor:

PÅ grunn AV MÅTEN PSR-4 og PSR-0 autoloading regler er satt opp, må it Composer sjekke filsystemet før du løser et klassenavn endelig. Dette senker ting ganske mye, men det er praktisk i utviklingsmiljøer fordi når du legger til en ny klasse, kan den umiddelbart oppdages / brukes uten å måtte gjenoppbygge autolasterkonfigurasjonen.

For å forbedre ytelsen Tilbyr Composer tre optimaliseringsnivåer; disse er:

• klassekartgenerering
• Autoritative klassekart
• APCu cache

1: Klassekartgenerering

denne strategien konverterer PSR-4/PSR-0-regler til classmap-regler. Denne strategien er raskere fordi classmap kan umiddelbart returnere hele banen til kjente filer og unngår en filsystem stat operasjon.

kjør følgende kommando for å aktivere dette optimaliseringsnivået:

composer dump-autoload --optimize 

2/A: Autoritative klassekart

i tillegg til å automatisk aktivere Nivå 1, når du bruker Dette nivået, hvis en klasse ikke er funnet i den genererte classmap, autolaster vil ikke forsøke å se på filsystemet I HENHOLD TIL PSR – 4 regler. For å aktivere dette optimaliseringsnivået, kjør følgende kommando:

composer dump-autoload --classmap-authoritative 

2/B: APCu cache

dette nivået legger Til En APCu cache som en reserve for klassen kartet. Det genererer imidlertid ikke classmap. Gitt det, nivå ett må aktiveres manuelt. For å aktivere dette optimaliseringsnivået, kjør følgende kommando:

composer dump-autoload --apcu 

Det er Avveininger

mens hvert av disse nivåene kan forbedre programytelsen, har de hver avveininger som må forstås før de brukes. Sørg for at Du konsulterer Komponistdokumentasjonen før du bruker dem.

Bruk En OPcache

SIDEN PHP er et tolket, ikke et kompilert språk, MÅ PHP-kjøretiden konvertere kildekoden til kjørbar byte-kode, før DEN kan utføres. OG SOM PHP er en delt-ingenting arkitektur, må denne prosessen skje på hver forespørsel.

men Med En opcode cache (OPcache), trenger dette trinnet bare å skje en gang for hver fil, da de genererte Opcodene kan bufres i delt minne og refereres der i stedet.

Så, som du kan forestille deg, Er En OPcache en av de minst intensive måtene å forbedre ytelsen TIL ET PHP-program, fordi ingen kode må endres. Noen rapporter viser opp til en 70% hastighetsforbedring.

Det har vært Flere Opcode cacher FOR PHP gjennom årene. OPCache (tidligere Zend Cache) har blitt buntet MED PHP siden versjon 5.5 — og er aktivert som standard I PHP 7.

for å vite mer om Det, sjekk ut opcache-dokumentasjonen. For å vite mer om ytelse tweaking OPcache, sjekk Ut Hayden James ‘ utmerket artikkel Samt Tideway innlegg på tuning det.

Bruk PHP 7 Preloading

hvis DU ikke har hørt OM PHP 7.4 nye preloading funksjon, ennå, det er veldig kult! I et nøtteskall tar funksjonen Opcache-funksjonalitet lenger enn den noen gang har gått før.

for å raskt oppsummere, første gang EN PHP-kildefil oppstår, må den analyseres, deretter kompileres til maskinavhengig bytekode, før Zend-Motoren kan utføre den. Opcaches redusere overhead av denne prosessen, som etter første gang at kildekoden analyseres og kompilert ned bytecodes blir deretter lagret I En Opcode cache i delt minne.

NESTE gang en forespørsel om filen oppstår, SJEKKER PHP for å se Om Opcode-hurtigbufferen har bytekoder for filen. Hvis det gjør det, blir de returnert og brukt. Hvis ikke (eller hvis kildefilen er endret siden bytekodene ble kompilert), analyseres, kompileres og bufres kildefilen. DETTE gir EN bemerkelsesverdig ytelse boost TIL PHP.

nå, la Oss se på hvordan preloading fungerer. For å sitere implementering RFC:

Ved serveroppstart – før noen applikasjonskode kjøres-kan vi laste inn et bestemt SETT MED PHP-filer i minnet-og gjøre innholdet “permanent tilgjengelig” for alle påfølgende forespørsler som vil bli betjent av den serveren. Alle funksjonene og klassene som er definert i disse filene, vil være tilgjengelige for forespørsler ut av boksen, akkurat som interne enheter. Preloading sikrer at:

• Alle funksjoner og de fleste klasser, definert i disse filene, vil bli permanent lastet inn I PHPS funksjons-og klassetabeller og bli permanent tilgjengelig i sammenheng med fremtidig forespørsel.
• PHP løser klasseavhengigheter og koblinger med foreldre, grensesnitt og egenskaper(noe som ikke skjer Med opcode caching).
• PHP fjerner unødvendig inkluderer og utfører andre optimaliseringer.

ved å ha koden for en hel applikasjon, inkludert rammen (Som Zend Expressive, Symfony og Laravel) forhåndslastet i minnet, kode som bare endret på serverstart, vil de fleste applikasjoner utføre betydelig bedre.

når det er sagt, har preloading noen, potensielle, ulemper som du bør vite om:

• en server omstart er nødvendig når kildefilene endres.
• Forhåndsinnlasting fungerer ikke i delte vertsmiljøer.
• Forhåndsinnlasting fungerer ikke når det finnes flere versjoner av samme program.

Forhåndsinnlasting er ikke magisk. Både kode-og distribusjonsprosessene må refactoreres for å dra nytte av det. For eksempel må noen utvikle et egendefinert loader-skript for å bestemme hvilke filer som skal lastes ved oppstart av serveren, og det skriptet må kjøres ved oppstart av serveren. Uansett, det er en betydelig forbedring, en verdt å investere i!

Bruk En Profiler

nå For et alternativ Som vil ta litt mer arbeid enn noen av de foregående fem. Ofte hopper vi inn og prøver å gjette hvor ytelsesflaskehalsene i våre applikasjoner er, ved hjelp av intuisjon og utdannede gjetninger.

selv om disse kan fungere, er de ikke de mest effektive tilnærmingene. I stedet kan vi bruke kodeprofiler til å analysere koden vår og vise hvor flaskehalsene er. Spesielt hjelper de med å svare på spørsmål som følgende:

• Hvor mange ganger ble hver metode kalt?
• hva var maksimal kjøretid for hver metode?
• hva var gjennomsnittlig kjøretid for hver metode?
• Hvor mange ganger ble en fil inkludert?
• hvilken vei tok en forespørsel gjennom et program (fra første til siste kodefil)?

ved å bore ned i en profilers resultater, kan du ofte bli hyggelig overrasket, men mer sannsynlig sjokkert, for å finne ut at søknaden din utfører kodebaner og klasser som du aldri forventet.

basert på informasjonen i profiler-rapporten, kan du og teamet ditt begynne å forstå bedre hva søknaden din gjør og ta informerte refactorings for å endre det, etter behov.

HVIS du nettopp har begynt med profilering, er DET flere alternativer tilgjengelig FOR PHP. De mest brukte er:

• Xdebugs profiler
• Tideway ‘ S XHProf extension (& XHGui)
• spx Profiler
• forp

Som Konklusjon

Og det er fem måter å forbedre KVALITETEN på PHP-applikasjonene dine spesielt. Noen av dem på egen hånd vil gi deg en bemerkelsesverdig ytelsesforbedring. Men når det brukes sammen, bør du forvente å se en betydelig ytelse, for ikke å nevne kvalitet, forbedring.