5 módszer a PHP teljesítményének növelésére – Tideways

5 A PHP teljesítményének növelésének módjai

bónusz: ezt a témát a PHP közösség szakértőjével tárgyaltuk podcastunkban:

a közmondásból, dobozból, a PHP tisztességes teljesítményt nyújt. Azonban van néhány dolog, amit mi, PHP fejlesztők és rendszergazdák tehetünk, hogy növelje a teljesítményt még tovább; néha szinte erőfeszítés nélkül.

ebben a bejegyzésben öt ilyen módon lépek át. Mire befejezte az olvasást, látnia kell legalább a PHP alkalmazás teljesítményének jelentős növekedését. Kezdjük.

PHP 7 használata

a PHP teljesítményének javításának egyik legjobb módja a legújabb verzió futtatása (PHP 7). Jelentős sebességjavulást kínál bármely korábbi verzióhoz képest. Az eredmények mindig változnak,mivel nincs két egyforma alkalmazás. A különböző fejlesztők és neves hosting cégek jelentései alapján azonban a teljesítmény javulása jelentős.

itt egy kis minta:

• a hivatalos PHP referenciaértékek szerint a PHP 7 másodpercenként kétszer annyi kérést képes végrehajtani, mint a PHP 5.6.
• a Kinsta PHP teljesítménymutatói azt mutatják, hogy a WordPress 5.0 3x annyi tranzakciót képes végrehajtani, mint a PHP 5.6; és
• Pantheon arról számolt be, hogy a PHP 7 64% – kal javult az 5.3-as verzióhoz képest.

ha ez nem elég az Ön számára, ellenőrizze a referenciaértékeket, és nézze meg, mit mondanak.

ezenkívül a PHP 7.0.0 December 3-án, 2015-ben jelent meg, a legújabb stabil verzió, a 7.3.6 pedig ez év május 30-án jelent meg.

mi több, a PHP 5, 5.6 végleges kiadása az EOL (End of Life) 7 hónappal ezelőtt, Dec 31, 2018. Tehát, ha még nem tette meg, akkor már jó ideje átállt a PHP 7-re. Végezze el a frissítést, és ahogy Rasmus mondta a phpCE 2018-ban, menjen zöldre(er) a tárhely költségeinek csökkentésével.

Uninstall Xdebug

a következő dolog, hogy ellenőrizze, hogy Xdebug nincs telepítve a termelési szerverek. Persze, az Xdebug az egyik legkifinomultabb és legátfogóbb profilozó és hibakereső a PHP-hez, de soha nem szabad engedélyezni (még telepíteni sem) egy termelési szerveren, legalábbis az Xdebug 3 kiadásáig, és csatlakoznia kell hozzánk a Derick támogatásában.

míg a teljesítmény referenciaértékek változnak (mindig), a verem túlcsordulásáról szóló egyik jelentés 50% – os teljesítménynövekedést mutatott az Xdebug teljes eltávolításával. Mi több, fontos megjegyezni, hogy annak ellenére, hogy az Xdebug telepítve volt a szerverre — még csak nem is volt engedélyezve!

Xdebug performance benchmark

a telepítés ellenőrzéséhez futtassa a php -m | grep -i xdebug parancsot, vagy ellenőrizze a tárhelyszolgáltató adminisztrációs paneljét. Ha pedig többet szeretne tudni az Xdebug működéséről, nézze meg az Xdebug dokumentációját.

Use Composer Optimize Autoloader

bár valószínűleg mindannyian nagyon jól ismerjük a Composer használatát a csomagkezelés kezelésére számunkra, ha nem vesszük figyelembe az általa generált konfiguráció optimalizálását, alkalmazásaink nem fognak a lehető legjobban teljesíteni.

Íme egy idézet a zeneszerző dokumentációjából, amely megmagyarázza, miért:

a PSR-4 és PSR-0 autoloading szabályok beállítása miatt az IT Composer-nek ellenőriznie kell a fájlrendszert, mielőtt véglegesen megoldja az osztálynevet. Ez kissé lelassítja a dolgokat, de fejlesztési környezetekben kényelmes, mert új osztály hozzáadásakor azonnal felfedezhető/használható anélkül, hogy újra kellene építenie az autoloader konfigurációját.

a teljesítmény javítása érdekében a Composer három optimalizálási szintet kínál; ezek a következők:

• Osztálytérkép-generáció
• mérvadó osztálytérképek
• APCu gyorsítótár

1: Class map generation

ez a stratégia átalakítja a PSR-4/PSR-0 szabályokat classmap szabályokká. Ez a stratégia gyorsabb, mert a classmap azonnal vissza tudja adni az ismert fájlok teljes elérési útját, és elkerüli a fájlrendszer stat működését.

az optimalizálási szint engedélyezéséhez futtassa a következő parancsot:

composer dump-autoload --optimize 

2/A: Mérvadó osztálytérképek

az 1. szint automatikus engedélyezése mellett, ha ezt a szintet használja, ha egy osztály nem található a generált osztálytérképben, az autoloader nem próbálja meg a fájlrendszert a PSR-4 szabályok szerint keresni. Az optimalizálási szint engedélyezéséhez futtassa a következő parancsot:

composer dump-autoload --classmap-authoritative 

2/B: APCu gyorsítótár

ez a szint hozzáad egy APCu gyorsítótárat tartalékként az osztálytérképhez. Ez azonban nem generálja a classmap-ot. Tekintettel arra, hogy az első szintet manuálisan kell engedélyezni. Az optimalizálási szint engedélyezéséhez futtassa a következő parancsot:

composer dump-autoload --apcu 

vannak kompromisszumok

bár ezek a szintek javíthatják az alkalmazás teljesítményét, mindegyiknek vannak kompromisszumai, amelyeket meg kell érteni használatuk előtt. Használat előtt feltétlenül olvassa el a zeneszerző dokumentációját.

használjon OPcache-t

mivel a PHP egy értelmezett, nem lefordított nyelv, a PHP futásidejének át kell alakítania a forráskódot végrehajtható bájtkód, mielőtt végrehajtható lenne. Mivel a PHP egy megosztott semmi architektúra, ennek a folyamatnak minden kérésnél meg kell történnie.

Opcode gyorsítótárral (OPcache) azonban ezt a lépést csak egyszer kell végrehajtani minden fájlnál, mivel a generált opkódok gyorsítótárazhatók a megosztott memóriában, és ott hivatkozhatnak.

tehát, ahogy el tudod képzelni, az OPcache az egyik legkevésbé intenzív módszer a PHP alkalmazás teljesítményének javítására, mivel egyetlen kódot sem kell megváltoztatni. Egyes jelentések 70% – os sebességnövekedést mutatnak.

az évek során számos Opcode gyorsítótár volt a PHP számára. Az OPCache (korábbi nevén Zend Cache) az 5.5 — ös verzió óta a PHP-vel van összekötve, és alapértelmezés szerint engedélyezve van a PHP 7-ben.

ha többet szeretne tudni róla, nézze meg az OPcache dokumentációját. Ha többet szeretne tudni a teljesítmény csípés OPcache, nézd meg Hayden James kiváló cikket, valamint Tideway utáni tuning is.

használja a PHP 7 Előtöltését

ha még nem hallottál a PHP 7.4 új előtöltési funkciójáról, mégis nagyon klassz! Dióhéjban, a funkció tovább viszi az Opcache funkcionalitását, mint valaha.

ahhoz, hogy gyorsan összefoglalni, az első alkalommal, amikor egy PHP forrás fájlt találkozott, azt kell elemezni, majd lefordítani gépfüggő bytecode, mielőtt a Zend motor tudja végrehajtani. Az OPcache-ek jelentősen csökkentik ennek a folyamatnak a költségeit, mivel az első alkalommal, amikor a forráskódot elemezték és lefordították, a bájtkódokat egy opcode gyorsítótárban tárolják a megosztott memóriában.

a következő alkalommal, amikor az adott fájlra vonatkozó kérés érkezik, a PHP ellenőrzi, hogy az Opcode gyorsítótárban vannak-e bájtkódok a fájlhoz. Ha igen, visszaküldik és felhasználják. Ha nem (vagy ha a forrásfájl megváltozott a bájtkódok lefordítása óta), akkor a forrásfájl elemzésre, lefordításra és gyorsítótárba kerül. Ez jelentős teljesítménynövekedést jelent a PHP számára.

most nézzük meg, hogyan működik az előfeszítés. A végrehajtó RFC idézése:

a szerver indításakor – mielőtt bármilyen alkalmazáskód futna – betölthetünk egy bizonyos PHP fájlt a memóriába – és tartalmukat “állandóan elérhetővé” tehetjük minden későbbi kérés számára, amelyet az adott szerver kiszolgál. Az ezekben a fájlokban definiált összes függvény és osztály elérhető lesz a dobozon kívüli kérések számára, pontosan úgy, mint a belső entitások. Az előfeszítés biztosítja, hogy:

• az ezekben a fájlokban definiált összes függvény és a legtöbb osztály véglegesen betöltődik a PHP függvény – és osztálytábláiba, és véglegesen elérhetővé válik minden jövőbeli kérés esetén.
• a PHP megoldja az osztályfüggőségeket és a szülővel, az interfészekkel és a tulajdonságokkal való hivatkozásokat (ami nem történik meg az Opcode gyorsítótárazásával).
• a PHP eltávolítja a felesleges includeket, és más optimalizálásokat hajt végre.

azáltal, hogy egy teljes alkalmazás kódját, beleértve annak keretrendszerét (például Zend Expressive, Symfony és Laravel) előre betölti a memóriába, a kód csak a szerver újraindításakor változott meg, a legtöbb alkalmazás jelentősen jobban teljesít.

ennek ellenére az előfeszítésnek van néhány lehetséges hátránya, amelyekről tudnia kell:

• a szerver újraindítása szükséges, ha a forrásfájlok megváltoznak.
• az Előtöltés nem működik megosztott tárhelykörnyezetekben.
• az Előtöltés nem működik, ha ugyanazon alkalmazásnak több verziója van.

az Előtöltés nem varázslatos. Mind a kódot, mind a telepítési folyamatokat újra kell szerkeszteni annak kihasználása érdekében. Például valakinek ki kell dolgoznia egy egyéni betöltő szkriptet annak meghatározásához, hogy mely fájlokat töltse be a kiszolgáló indításakor, és ezt a szkriptet a kiszolgáló indításakor kell futtatni. Függetlenül attól, hogy ez jelentős javulás, érdemes befektetni!

használjon Profilozót

most egy olyan opcióhoz, amely valamivel több munkát igényel, mint az előző öt. Gyakran beugrunk, és intuíció és képzett találgatások segítségével megpróbáljuk kitalálni, hol vannak az alkalmazásaink teljesítménybeli szűk keresztmetszetei.

bár ezek működhetnek, nem a leghatékonyabb megközelítések. Ehelyett kódprofilokat használhatunk a kódunk elemzésére, és megmutathatjuk, hol vannak a szűk keresztmetszetek. Kimondottan, segítenek a következő kérdések megválaszolásában:

• hányszor hívták az egyes módszereket?
• mennyi volt az egyes módszerek maximális végrehajtási ideje?
• mennyi volt az egyes módszerek átlagos végrehajtási ideje?
• hányszor szerepelt egy fájl?
• milyen utat tett meg egy kérés egy alkalmazáson keresztül (az elsőtől az utolsóig) kódfájl)?

a profilozó eredményeibe való fúrással gyakran kellemesen meglepődhet, bár valószínűleg megdöbbenve tapasztalhatja, hogy az alkalmazás olyan kódútvonalakat és osztályokat hajt végre, amelyekre soha nem számított.

a profiler jelentésben szereplő információk alapján Ön és csapata jobban megértheti, hogy mit csinál a jelentkezése, és tájékozott refaktorokat készíthet annak megváltoztatására, ha szükséges.

ha csak most kezded el a profilozást, számos lehetőség áll rendelkezésre a PHP számára. A leggyakrabban használt:

• Xdebug a profiler
• Tideway a XHProf extension (& XHGui)
• spx Profiler
• forp

összefoglalva

és ezek öt módon minőségének javítása a PHP alkalmazások nevezetesen. Ezek közül bármelyik a saját szállít egy figyelemre méltó teljesítmény javítása. Ha azonban együtt használják, akkor számíthat arra, hogy jelentős teljesítményt fog látni, nem is beszélve a minőségről, a javulásról.