5 måder at øge PHP-ydeevne på

5 måder at øge PHP ydeevne

BONUS: Vi har diskuteret dette emne med en ekspert i PHP samfund i vores podcast:

ud af den legendariske, boks, PHP giver anstændig ydeevne. Der er dog flere ting, som vi som PHP-udviklere og systemadministratorer kan gøre for at øge dens ydeevne yderligere; nogle gange for næsten ingen indsats.

i dette indlæg vil jeg gå gennem fem af disse måder. Når du er færdig med at læse, skal du i det mindste se en bemærkelsesværdig stigning i ydelsen af din PHP-applikation. Lad os begynde.

brug PHP 7

en af de bedste måder at forbedre PHP ‘ s ydeevne på er at køre den nyeste version (PHP 7). Det giver en betydelig hastighedsforbedring i forhold til enhver tidligere version. Nu vil resultaterne altid variere, da ingen to applikationer nogensinde er ens. Baseret på rapporter fra en række forskellige udviklere og bemærkelsesværdige hostingfirmaer er præstationsforbedringerne imidlertid betydelige.

her er en lille prøve:

• officielle PHP benchmarks rapporterer, at PHP 7 kan udføre dobbelt så mange anmodninger pr.
• Kinstas PHP-præstationsbenchmarks viser, at 5.0 kan udføre 3 gange så mange transaktioner som PHP 5.6; og
• Pantheon rapporterede, at PHP 7 gav en forbedring på 64% i forhold til version 5.3.

hvis det ikke er nok for dig, skal du kontrollere dine benchmarks og se, hvad de siger.

derudover blev PHP 7.0.0 udgivet den 3.December 2015, og den seneste stabile version, 7.3.6, blev udgivet den 30. maj i år.

hvad mere er, den endelige udgivelse af PHP 5, 5.6, gik EOL (End of Life) 7 måneder siden, den Dec 31, 2018. Så hvis du ikke allerede har gjort det, er det godt forbi tid, du har lavet overgangen til PHP 7. Foretag opgraderingen, og som Rasmus sagde på phpCE 2018, Gå grøn(er) ved at reducere dine hostingomkostninger.

Afinstaller

den næste ting at kontrollere er, at ikke er installeret på dine produktionsservere. Sikker på, at er en af de mest sofistikerede og omfattende profiler og debuggere til PHP, men det bør aldrig aktiveres (selv installeret) på en produktionsserver, i det mindste indtil 3 er frigivet, og du bør være med til at støtte Derick til at arbejde på det.

mens præstationsbenchmarks varierer (de gør det altid), viste en rapport om stakoverløb en 50% ydelsesforøgelse ved helt at fjerne . Hvad mere er, er det vigtigt at bemærke, at selvom blev installeret på serveren — det var ikke engang aktiveret!

Kdebug performance benchmark

for at kontrollere, om det er installeret, skal du køre php -m | grep -i xdebug eller tjekke din hostingudbyders administrationspanel. Og hvis du gerne vil vide mere om, hvordan fungerer, så tjek dokumentationen.

brug Composer Optimer Autoloader

mens vi alle sandsynligvis er meget fortrolige med at bruge Composer til at håndtere pakkehåndtering for os, hvis vi ikke overvejer at optimere den konfiguration, den genererer, vil vores applikationer ikke fungere så godt som muligt.

her er et citat fra komponistdokumentationen, der forklarer hvorfor:

på grund af den måde PSR-4 og PSR-0 autoloading regler er sat op, it Composer skal kontrollere filsystemet før løse et klassenavn endegyldigt. Dette bremser tingene ganske lidt, men det er praktisk i udviklingsmiljøer, fordi når du tilføjer en ny klasse, kan den straks opdages/bruges uden at skulle genopbygge autoloader-konfigurationen.

for at forbedre ydeevnen tilbyder Composer tre optimeringsniveauer; disse er:

• klasse kort generation
• autoritative klasse kort
• apcu cache

1: klasse kort generation

denne strategi konverterer PSR-4/PSR-0 regler i classmap regler. Denne strategi er hurtigere, fordi classmap øjeblikkeligt kan returnere den fulde sti til kendte filer og undgår en filsystemstat-operation.

for at aktivere dette optimeringsniveau skal du køre følgende kommando:

composer dump-autoload --optimize 

2/A: Autoritative klassekort

ud over Automatisk aktivering af Niveau 1, når du bruger dette niveau, hvis en klasse ikke findes i det genererede klassekort, vil autoloaderen ikke forsøge at se på filsystemet i henhold til PSR-4 regler. For at aktivere dette optimeringsniveau skal du køre følgende kommando:

composer dump-autoload --classmap-authoritative 

2/B: APCu cache

dette niveau tilføjer en APCu cache som en fallback for klassen kortet. Det genererer dog ikke klassekortet. I betragtning af det skal niveau et aktiveres manuelt. For at aktivere dette optimeringsniveau skal du køre følgende kommando:

composer dump-autoload --apcu 

der er afvejninger

mens hvert af disse niveauer kan forbedre applikationsydelsen, har de hver især afvejninger, som skal forstås, før de bruges. Sørg for at konsultere Komponistdokumentationen, før du bruger dem.

brug en OPcache

da PHP er et fortolket, ikke et kompileret sprog, skal PHP runtime konvertere kildekode til eksekverbar byte-kode, før den kan udføres. Og da PHP er en delt-intet arkitektur, skal denne proces ske på hver anmodning.

men med en Opcode cache (opcache) behøver dette trin kun at ske en gang for hver fil, da de genererede opcodes kan cachelagres i delt hukommelse og refereres der i stedet.

så som du kan forestille dig, er en opcache en af de mindst intensive måder at forbedre ydelsen på en PHP-applikation, fordi ingen kode skal ændres. Nogle rapporter viser op til en 70% hastighedsforbedring.

der har været flere Opcode caches til PHP gennem årene. OPcache er blevet samlet med PHP siden version 5.5 — og er som standard aktiveret i PHP 7.

for at vide mere om det, tjek OPcache-dokumentationen. Hvis du vil vide mere om ydeevne finjustering OPcache, tjek Hayden James’ fremragende artikel samt Tidevej indlæg på tuning det.

brug PHP 7 Preloading

hvis du ikke har hørt om PHP 7.4 nye preloading funktion, endnu, det er meget cool! I en nøddeskal tager funktionen Opcache-funktionalitet længere end den nogensinde er gået før.

for hurtigt at opsummere, første gang en PHP-kildefil opstår, skal den analyseres og derefter kompileres til maskinafhængig bytekode, før end-motoren kan udføre den. Opcaches reducerer omkostningerne ved denne proces betydeligt, da efter første gang kildekoden analyseres og kompileres, gemmes bytekoderne derefter i en opcode-cache i delt hukommelse.

næste gang en anmodning om den pågældende fil opstår, kontrollerer PHP, om opcode-cachen har bytekoder til filen. Hvis det gør det, bliver de returneret og brugt. Hvis ikke (eller hvis kildefilen er ændret siden bytekoderne blev kompileret), analyseres kildefilen, kompileres og cachelagres. Dette giver en bemærkelsesværdig ydeevne boost til PHP.

lad os nu se på, hvordan preloading fungerer. For at citere den implementerende RFC:

ved serverstart-før en applikationskode køres – kan vi indlæse et bestemt sæt PHP-filer i hukommelsen-og gøre deres indhold “permanent tilgængeligt” for alle efterfølgende anmodninger, der vil blive betjent af den pågældende server. Alle de funktioner og klasser, der er defineret i disse filer, vil være tilgængelige for anmodninger ud af boksen, nøjagtigt som interne enheder. Forudindlæsning sikrer, at:

• alle funktioner og de fleste klasser, der er defineret i disse filer, indlæses permanent i PHP ‘ s funktions-og klassetabeller og bliver permanent tilgængelige i forbindelse med enhver fremtidig anmodning.
• PHP løser klasseafhængigheder og links til forældre, grænseflader og træk (noget der ikke sker med opcode caching).
• PHP fjerner unødvendige omfatter og udfører andre optimeringer.

ved at have koden til en hel applikation, inklusive dens rammer (f.eks.

når det er sagt, har preloading et par potentielle ulemper, som du bør vide om:

• en server genstart er påkrævet, når kildefiler ændres.
• forudindlæsning fungerer ikke i delte hostingmiljøer.
• forudindlæsning fungerer ikke, når der er flere versioner af den samme applikation.

forudindlæsning er ikke magisk. Både din kode og implementeringsprocesser skal refactoreres for at drage fordel af den. For eksempel bliver nogen nødt til at udvikle et brugerdefineret loader-script for at bestemme, hvilke filer der skal indlæses ved serverstart, og dette script skal køres ved serverstart. Uanset hvad, det er en betydelig forbedring, en værd at investere i!

brug en Profiler

nu til en mulighed, der vil tage lidt mere arbejde end nogen af de foregående fem. Ofte hopper vi ind og forsøger at gætte, hvor præstationsflaskehalsene i vores applikationer er, ved hjælp af intuition og uddannede gæt.

selvom disse kan fungere, er de ikke de mest effektive tilgange. I stedet kan vi bruge kodeprofilere til at analysere vores kode og vise, hvor flaskehalsene er. Specifikt hjælper de med at besvare spørgsmål som følgende:

• hvor mange gange blev hver metode kaldt?
• hvad var den maksimale udførelsestid for hver metode?
• hvad var den gennemsnitlige udførelsestid for hver metode?
• hvor mange gange blev en fil inkluderet?
• hvilken sti tog en anmodning gennem en applikation (fra den første til den sidste kodefil)?

ved at bore ned i en profilers resultater kan du ofte blive glædeligt overrasket, men mere sandsynligt chokeret, for at finde ud af, at din ansøgning udfører kodestier og klasser, som du aldrig forventede.

baseret på oplysningerne i profiler-rapporten kan du og dit team derefter begynde at forstå bedre, hvad din ansøgning laver, og foretage informerede refactorings for at ændre den, når og hvor det er nødvendigt.

hvis du lige er kommet i gang med profilering, er der flere muligheder til rådighed for PHP. De mest almindeligt anvendte er:

• profil
• Prof udvidelse (& Hgui)
• Forp

afslutningsvis

og det er fem måder at forbedre kvaliteten af dine PHP-applikationer især. Enhver af dem på egen hånd vil give dig en bemærkelsesværdig præstationsforbedring. Men når det bruges sammen, bør du forvente at se en betydelig præstation, for ikke at nævne kvalitet, forbedring.