5 manieren om PHP prestaties te verhogen-Tideways

5 manieren om PHP-prestaties te verhogen

BONUS: we hebben dit onderwerp besproken met een expert in de PHP-gemeenschap in onze podcast:

uit het spreekwoordelijke kader biedt PHP fatsoenlijke prestaties. Echter, er zijn verschillende dingen die we, als PHP ontwikkelaars en systeembeheerders, kunnen doen om de prestaties nog verder te verhogen; soms voor bijna geen moeite.

in dit bericht, Ik ga stap door vijf van die manieren. Tegen de tijd dat je klaar bent met lezen, moet je op zijn minst een opmerkelijke toename zien in de prestaties van je PHP applicatie. Laten we beginnen.

gebruik PHP 7

een van de beste manieren om PHP ‘ s prestaties te verbeteren is door de nieuwste versie (PHP 7) uit te voeren. Het biedt een aanzienlijke verbetering van de snelheid ten opzichte van elke vorige versie. Nu, de resultaten zullen altijd variëren, als geen twee toepassingen zijn ooit hetzelfde. Op basis van rapporten van verschillende ontwikkelaars en opmerkelijke hostingbedrijven zijn de prestatieverbeteringen echter aanzienlijk.

hier is een klein voorbeeld:

• officiële PHP benchmarks rapporteren dat PHP 7 twee keer zoveel aanvragen per seconde kan uitvoeren in vergelijking met PHP 5.6.
• Kinsta ‘ s PHP performance benchmarks laten zien dat WordPress 5.0 3x zoveel transacties kan uitvoeren als PHP 5.6; en
• Pantheon rapporteerde dat PHP 7 een 64% verbetering gaf ten opzichte van versie 5.3.

als dat niet genoeg is voor u, controleer uw benchmarks en zie wat ze zeggen.

daarnaast werd PHP 7.0.0 uitgebracht op 3 December 2015, en de laatste stabiele versie, 7.3.6, werd uitgebracht op 30 mei dit jaar.

wat meer is, de definitieve release van PHP 5, 5.6, ging EOL (End of Life) 7 maanden geleden, op 31 Dec 2018. Dus, als je dat nog niet hebt gedaan, is het ver voorbij de tijd dat je de overgang naar PHP 7. Maak de upgrade en, zoals Rasmus zei op phpCE 2018, ga groen (er) door het verlagen van uw hosting kosten.

Xdebug

verwijderen het volgende wat u moet controleren is dat Xdebug niet is geïnstalleerd op uw productieservers. Zeker, Xdebug is een van de meest geavanceerde en uitgebreide profilers en debuggers voor PHP, maar het mag nooit worden ingeschakeld (zelfs geà nstalleerd) op een productie-server, in ieder geval tot Xdebug 3 is vrijgegeven en je moet bij ons in het ondersteunen van Derick om te werken aan het.

hoewel de prestatiebenchmarks variëren (dat doen ze altijd), liet één rapport over Stack Overflow een prestatieverhoging van 50% zien door Xdebug volledig te verwijderen. Wat meer is, is het belangrijk om op te merken dat hoewel Xdebug op de server is geïnstalleerd — het was niet eens ingeschakeld!

Xdebug performance benchmark

om te controleren of het is geïnstalleerd, voer php -m | grep -i xdebug uit of controleer het beheerpaneel van uw hostingprovider. En als je meer wilt weten over hoe Xdebug werkt, bekijk dan de Xdebug documentatie.

use Composer Optimize Autoloader

hoewel we waarschijnlijk allemaal bekend zijn met het gebruik van Composer om pakketbeheer voor ons af te handelen, zullen onze applicaties niet zo goed mogelijk presteren als we overwegen de configuratie die het genereert te optimaliseren.

hier is een citaat uit de composer documentatie die uitlegt waarom:

vanwege de manier waarop PSR-4 en PSR-0 autoloading regels worden ingesteld, moet it Composer het bestandssysteem controleren voordat een class naam definitief wordt opgelost. Dit vertraagt de zaken nogal, maar het is handig in ontwikkelomgevingen, omdat wanneer u een nieuwe klasse toevoegt, het onmiddellijk kan worden ontdekt/gebruikt zonder dat u de autoloader configuratie opnieuw moet opbouwen.

om de prestaties te verbeteren, biedt Composer drie optimalisatieniveaus; deze zijn:

• Klasse kaart generatie
• gezaghebbende klasse kaarten
• APCu cache

1: Class map generation

deze strategie zet PSR-4/PSR-0 regels om in classmap regels. Deze strategie is sneller omdat de classmap direct het volledige pad naar bekende bestanden kan retourneren en een bestandssysteem stat operatie vermijdt.

voer het volgende commando uit om dit optimalisatieniveau in te schakelen:

composer dump-autoload --optimize 

2/A: Gezaghebbende class maps

naast het automatisch inschakelen van Niveau 1, zal de autoloader bij gebruik van dit niveau, als een klasse niet gevonden wordt in de gegenereerde classmap, niet proberen om het bestandssysteem te bekijken volgens de PSR-4 regels. Voer het volgende commando uit om dit optimalisatieniveau in te schakelen:

composer dump-autoload --classmap-authoritative 

2/B: APCu-cache

dit niveau voegt een APCu-cache toe als terugval voor de klasse-kaart. Echter, het genereert niet de classmap. Gegeven dat, niveau één zou moeten handmatig worden ingeschakeld. Voer het volgende commando uit om dit optimalisatieniveau in te schakelen:

composer dump-autoload --apcu 

er zijn Trade-Offs

terwijl elk van deze niveaus de prestaties van applicaties kan verbeteren, hebben ze elk trade-offs die moeten worden begrepen voordat ze worden gebruikt. Zorg ervoor dat u de Composer documentatie te raadplegen voordat u ze gebruikt.

gebruik een OPcache

aangezien PHP een geà nterpreteerde, niet gecompileerde taal is, moet de PHP runtime de broncode converteren naar uitvoerbare byte code, voordat het kan worden uitgevoerd. En aangezien PHP een shared-nothing architectuur is, moet dit proces bij elke aanvraag gebeuren.

echter, met een opcode-cache (OPcache) hoeft deze stap slechts één keer te gebeuren voor elk bestand, omdat de gegenereerde Opcodes in het gedeelde geheugen kunnen worden opgeslagen en er in plaats daarvan naar kunnen worden verwezen.

dus, zoals je je kunt voorstellen, is een OPCACHE een van de minst intensieve manieren om de prestaties van een PHP applicatie te verbeteren, omdat er geen code hoeft te veranderen. Sommige rapporten laten een snelheidsverbetering van 70% zien.

er zijn verschillende Opcode caches voor PHP door de jaren heen. OPCache (voorheen Zend Cache) is gebundeld met PHP sinds versie 5.5 — en is standaard ingeschakeld in PHP 7.

om er meer over te weten, bekijk de opcache documentatie. Om meer te weten over de prestaties tweaken OPcache, check out Hayden James ‘uitstekende artikel evenals Tideway’ s post op tuning it.

gebruik PHP 7 Preloading

als je nog niet gehoord hebt van PHP 7.4 ‘ s nieuwe preloading functie, is het erg cool! In een notendop, de functie neemt opcache functionaliteit verder dan zijn ooit eerder gegaan.

om snel samen te vatten, moet de eerste keer dat een PHP bronbestand wordt aangetroffen, worden ontleed en vervolgens gecompileerd in machine-afhankelijke bytecode, voordat de Zend Engine het kan uitvoeren. Opcaches verminderen de overhead van dit proces aanzienlijk, omdat na de eerste keer dat de broncode wordt ontleed en gecompileerd de bytecodes vervolgens worden opgeslagen in een opcode-cache in gedeeld geheugen.

de volgende keer dat een verzoek voor dat bestand wordt aangetroffen, controleert PHP of de opcode-cache bytecodes heeft voor het bestand. Als dat zo is, worden ze teruggebracht en gebruikt. Zo niet (of als het bronbestand is veranderd sinds de bytecodes zijn gecompileerd), wordt het bronbestand ontleed, gecompileerd en gecached. Dit geeft een opmerkelijke prestatie boost aan PHP.

laten we nu eens kijken hoe het vooraf laden werkt. Om de uitvoerende RFC te citeren:

bij het opstarten van de server-voordat een applicatie code wordt uitgevoerd – kunnen we een bepaalde set van PHP-bestanden te laden in het geheugen-en maken hun inhoud “permanent beschikbaar” voor alle volgende verzoeken die zullen worden bediend door die server. Alle functies en klassen gedefinieerd in deze bestanden zullen beschikbaar zijn voor aanvragen uit de doos, precies als interne entiteiten. Vooraf laden zorgt ervoor dat:

• alle functies en de meeste klassen, gedefinieerd in deze bestanden zullen permanent worden geladen in PHP functie en klasse tabellen en permanent beschikbaar in de context van een toekomstige aanvraag.
• PHP Lost klasse afhankelijkheden en koppelingen met parent, interfaces, en eigenschappen (iets dat niet gebeurt met Opcode caching).
• PHP verwijdert onnodige includes en voert andere optimalisaties uit.

door de code voor een hele toepassing, inclusief het framework (zoals Zend Expressive, Symfony en Laravel) vooraf in het geheugen te laden, code die alleen gewijzigd is bij het opnieuw opstarten van de server, zullen de meeste toepassingen aanzienlijk beter presteren.

dat gezegd hebbende, vooraf laden heeft een paar, potentiële, nadelen die u moet weten over:

• een server HERSTART is vereist wanneer bronbestanden veranderen.
• vooraf laden werkt niet in gedeelde hostingomgevingen.
• Laden zal niet werken als er meerdere versies van dezelfde toepassing zijn.

laden is niet magisch. Zowel uw code als deployment processen zullen moeten worden geherformuleerd om te profiteren van het. Bijvoorbeeld, iemand zal een aangepaste loader script te ontwikkelen om te bepalen welke bestanden te laden bij het opstarten van de server, en dat script zal moeten worden uitgevoerd bij het opstarten van de server. Hoe dan ook, het is een aanzienlijke verbetering, een de moeite waard om te investeren in!

Gebruik nu een Profiler

voor een optie die iets meer werk zal vergen dan een van de vorige vijf. Vaak springen we in en proberen te raden waar de prestaties knelpunten in onze toepassingen zijn, met behulp van intuïtie en opgeleide gissingen.

hoewel deze kunnen werken, zijn ze niet de meest efficiënte aanpak. In plaats daarvan kunnen we code profilers gebruiken om onze code te analyseren en te laten zien waar de knelpunten zijn. Specifiek, ze helpen bij het beantwoorden van vragen zoals de volgende:

• hoe vaak werd elke methode gebeld?
• wat was de maximale uitvoeringstijd van elke methode?
• wat was de gemiddelde uitvoeringstijd van elke methode?
• hoe vaak is een bestand opgenomen?
• welk pad heeft een aanvraag door een toepassing geleid (van het eerste tot het laatste codebestand)?

door in de resultaten van een profiler te boren, kunt u vaak aangenaam verrast zijn, hoewel meer waarschijnlijk geschokt, om te ontdekken dat uw applicatie code paden en klassen uitvoert die u nooit had verwacht.

op basis van de informatie in het profiler-rapport kunnen u en uw team dan beter beginnen te begrijpen wat uw toepassing doet en geïnformeerde refactorings maken om het te wijzigen, waar en waar nodig.

als je net begonnen bent met profileren, zijn er verschillende opties beschikbaar voor PHP. De meest gebruikte zijn:

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

concluderend

en dat zijn vijf manieren om de kwaliteit van uw PHP applicaties te verbeteren. Elk van hen op hun eigen zal leveren u een opmerkelijke prestatieverbetering. Echter, wanneer gebruikt samen, moet je verwachten dat een aanzienlijke prestaties te zien, niet te vergeten kwaliteit, verbetering.