5 sätt att öka PHP-prestanda-Tideways

5 sätt att öka PHP-prestanda

BONUS: Vi har diskuterat detta ämne med en expert i PHP-communityn i vår podcast:

ur den ordspråkiga rutan ger PHP anständigt prestanda. Det finns dock flera saker som vi, som PHP-utvecklare och systemadministratörer, kan göra för att öka dess prestanda ytterligare; ibland för nästan ingen ansträngning.

i det här inlägget kommer jag att gå igenom fem av dessa sätt. När du är klar med läsningen bör du se åtminstone en märkbar ökning av prestandan för din PHP-applikation. Låt oss börja.

använd PHP 7

ett av de bästa sätten att förbättra PHP: s prestanda är att köra den senaste versionen (PHP 7). Det ger en betydande hastighet förbättring jämfört med någon tidigare version. Nu kommer resultaten alltid att variera, eftersom inga två applikationer någonsin är desamma. Men baserat på rapporter från en rad olika utvecklare och anmärkningsvärda värdföretag är prestandaförbättringarna betydande.

här är ett litet urval:

• officiella PHP-riktmärken rapporterar att PHP 7 kan utföra dubbelt så många förfrågningar per sekund jämfört med PHP 5.6.
• Kinstas PHP prestanda riktmärken visar WordPress 5.0 kan utföra 3x så många transaktioner som PHP 5.6; och
• Pantheon rapporterade att PHP 7 gav en 64% förbättring jämfört med version 5.3.

om det inte räcker för dig, kolla dina riktmärken och se vad de säger.

dessutom släpptes PHP 7.0.0 den 3 December 2015 och den senaste stabila versionen, 7.3.6, släpptes den 30 maj i år.

dessutom gick den slutliga utgåvan av PHP 5, 5.6, EOL (End of Life) för 7 månader sedan, den 31 december 2018. Så om du inte redan har gjort det är det väl förbi tiden du gjorde övergången till PHP 7. Gör uppgraderingen och, som Rasmus sa på phpCE 2018, gå grönt(er) genom att minska dina värdkostnader.

Avinstallera Xdebug

nästa sak att kontrollera är att Xdebug inte är installerat på dina produktionsservrar. Visst, Xdebug är en av de mest sofistikerade och omfattande profilerna och felsökarna för PHP, men det ska aldrig aktiveras (även installerat) på en produktionsserver, åtminstone tills Xdebug 3 släpps och du bör gå med oss för att stödja Derick för att arbeta med det.

medan prestandamärkena varierar (de gör alltid), visade en rapport om Stack Overflow en 50% prestationsökning genom att helt ta bort Xdebug. Dessutom är det viktigt att notera att även om Xdebug installerades på servern — var det inte ens aktiverat!

xdebug performance benchmark

för att kontrollera om det är installerat, kör php -m | grep -i xdebug eller kontrollera din värdleverantörs administrationspanel. Och om du vill veta mer om hur Xdebug fungerar, kolla in xdebug-dokumentationen.

använd Composer Optimize Autoloader

medan vi alla är mycket bekanta med att använda Composer för att hantera pakethantering för oss, om vi inte överväger att optimera konfigurationen som den genererar, kommer våra applikationer inte att fungera så bra som möjligt.

här är ett citat från kompositörens dokumentation som förklarar varför:

på grund av hur PSR-4 och PSR-0 autoloading regler ställs in, måste It Composer kontrollera filsystemet innan lösa ett klassnamn slutgiltigt. Detta saktar ner saker ganska, men det är bekvämt i utvecklingsmiljöer eftersom när du lägger till en ny klass kan den omedelbart upptäckas/användas utan att behöva bygga om autoloader-konfigurationen.

för att förbättra prestanda erbjuder Composer tre optimeringsnivåer; dessa är:

• klass karta generation
• auktoritativa klass kartor
• APCu cache

1: klass karta generation

denna strategi konverterar PSR-4/PSR-0 regler i classmap regler. Denna strategi är snabbare eftersom classmap kan omedelbart returnera hela sökvägen till kända filer och undviker ett filsystem stat operation.

för att aktivera denna optimeringsnivå, kör följande kommando:

composer dump-autoload --optimize 

2/A: Auktoritativa klasskartor

förutom att automatiskt aktivera Nivå 1, när du använder denna nivå, om en klass inte hittas i den genererade classmap, autoloader kommer inte att försöka titta på filsystemet enligt PSR-4 Regler. För att aktivera denna optimeringsnivå, kör följande kommando:

composer dump-autoload --classmap-authoritative 

2/B: APCu cache

denna nivå lägger till en APCu cache som en reserv för klassen kartan. Det genererar dock inte classmap. Med tanke på att nivå ett måste aktiveras manuellt. För att aktivera denna optimeringsnivå, kör följande kommando:

composer dump-autoload --apcu 

det finns avvägningar

medan var och en av dessa nivåer kan förbättra applikationsprestanda, har de var och en avvägningar som måste förstås innan de används. Se till att du läser kompositörens dokumentation innan du använder dem.

använd en OPcache

eftersom PHP är ett tolkat, inte ett kompilerat språk, måste PHP runtime konvertera källkod till körbar byte-kod innan den kan köras. Och eftersom PHP är en delad-ingenting arkitektur, måste denna process ske på varje begäran.

men med en Opcode cache (OPcache) behöver detta steg bara ske en gång för varje fil, eftersom de genererade Opkoderna kan cachas i delat minne och refereras där istället.

så, som du kan föreställa dig, är en OPcache ett av de minst intensiva sätten att förbättra prestanda för en PHP-applikation, eftersom ingen kod behöver ändras. Vissa rapporter visar upp till 70% hastighet förbättring.

det har funnits flera Opcode cachar för PHP under åren. OPCache (tidigare Zend Cache) har buntats med PHP sedan version 5.5 — och är aktiverat som standard i PHP 7.

för att veta mer om det, kolla in OPcache-dokumentationen. För att veta mer om prestanda tweaking OPcache, kolla in Hayden James utmärkta artikel samt Tideways inlägg om att ställa in det.

använd PHP 7 förspänning

om du inte har hört talas om PHP 7.4 nya förspänning funktion, men det är väldigt cool! I ett nötskal tar funktionen Opcache-funktionalitet längre än någonsin tidigare.

för att snabbt sammanfatta, första gången en PHP-källfil påträffas, måste den analyseras och sedan kompileras till maskinberoende bytekod innan Zend-motorn kan köra den. Opcaches avsevärt minska overhead av denna process, som efter den första gången som källkoden analyseras och sammanställs ner bytecodes lagras sedan i en Opcode cache i delat minne.

nästa gång en begäran om den filen påträffas kontrollerar PHP om opcode-cachen har bytekoder för filen. Om det gör det, returneras de och används. Om inte (eller om källfilen har ändrats sedan bytecodes sammanställdes), källfilen tolkas, kompileras och cachas. Detta ger en anmärkningsvärd prestationsökning för PHP.

låt oss nu titta på hur förladdning fungerar. För att citera implementeringen av RFC:

vid Serverstart-innan någon programkod körs – kan vi ladda en viss uppsättning PHP – filer i minnet-och göra innehållet “permanent tillgängligt” för alla efterföljande förfrågningar som kommer att serveras av den servern. Alla funktioner och klasser som definieras i dessa filer kommer att vara tillgängliga för förfrågningar ur lådan, precis som interna enheter. Förspänning säkerställer att:

• alla funktioner och de flesta klasser, definierade i dessa filer kommer att laddas permanent i PHP: s funktions-och klasstabeller och blir permanent tillgängliga i samband med framtida begäran.
• PHP löser klassberoenden och länkar med förälder, gränssnitt och egenskaper (något som inte händer med Opcode caching).
• PHP tar bort onödiga inkluderar och utför andra optimeringar.

genom att ha koden för en hel applikation, inklusive dess ramverk (som Zend Expressive, Symfony och Laravel) förinstallerad i minnet, kod som bara ändrats vid omstart av servern, kommer de flesta applikationer att fungera betydligt bättre.

som sagt, förspänning har några, potentiella, nackdelar som du borde veta om:

• en omstart av servern krävs när källfilerna ändras.
• förladdning fungerar inte i delade värdmiljöer.
• förladdning fungerar inte när det finns flera versioner av samma applikation.

förladdning är inte magisk. Både din kod och distributionsprocesser måste refactored att dra nytta av det. Till exempel måste någon utveckla ett anpassat loader-skript för att bestämma vilka filer som ska laddas vid Serverstart, och det skriptet måste köras vid Serverstart. Oavsett, det är en betydande förbättring, en värt att investera i!

använd en Profiler

nu för ett alternativ som tar lite mer arbete än någon av de tidigare fem. Ofta hoppar vi in och försöker gissa var prestandaflaskhalsarna i våra applikationer är, med hjälp av intuition och utbildade gissningar.

även om dessa kan fungera är de inte de mest effektiva metoderna. Istället kan vi använda kodprofilerare för att analysera vår kod och visa var flaskhalsarna är. Specifikt hjälper de att svara på frågor som följande:

• hur många gånger kallades varje metod?
• vad var den maximala exekveringstiden för varje metod?
• vad var den genomsnittliga exekveringstiden för varje metod?
• hur många gånger har en fil inkluderats?
• vilken väg tog en begäran genom en applikation (från den första till den sista kodfilen)?

genom att borra ner i en profilers resultat kan du ofta bli positivt överraskad, men mer sannolikt chockad, för att upptäcka att din ansökan kör kodvägar och klasser som du aldrig förväntade dig.

baserat på informationen i profilerapporten kan du och ditt team sedan börja förstå bättre vad din ansökan gör och göra informerade refactorings för att ändra det, efter behov.

om du precis har börjat med profilering finns det flera alternativ tillgängliga för PHP. De vanligaste är:

• xdebugs profiler
• Tideways xhprof-förlängning (& XHGui)
• spx Profiler
• forp

Sammanfattningsvis

och det är fem sätt att förbättra kvaliteten på dina PHP-applikationer särskilt. Någon av dem på egen hand kommer att ge dig en anmärkningsvärd prestationsförbättring. Men när du används tillsammans bör du förvänta dig att se en betydande prestanda, för att inte tala om kvalitet, förbättring.