5 způsobů, jak zvýšit výkon PHP-Tideways

5 Způsoby, jak zvýšit výkon PHP

BONUS: diskutovali jsme o tomto tématu s odborníkem v komunitě PHP v našem podcastu:

z příslovečné krabice poskytuje PHP slušný výkon. Existuje však několik věcí, které my, jako vývojáři PHP a správci systémů, můžeme udělat, abychom ještě více zvýšili jeho výkon; někdy téměř bez námahy.

v tomto příspěvku se chystám projít pěti z těchto způsobů. Než dokončíte čtení, měli byste vidět alespoň výrazný nárůst výkonu vaší PHP aplikace. Začněme.

použijte PHP 7

jedním z nejlepších způsobů, jak zlepšit výkon PHP, je spustit nejnovější verzi (PHP 7). Nabízí výrazné zlepšení rychlosti oproti jakékoli předchozí verzi. Nyní se výsledky budou vždy lišit, protože žádné dvě aplikace nejsou vždy stejné. Na základě zpráv řady různých vývojářů a významných hostingových společností jsou však zlepšení výkonu významná.

zde je malý vzorek:

• Oficiální PHP benchmarky uvádějí, že PHP 7 může spustit dvakrát tolik požadavků za sekundu ve srovnání s PHP 5.6.
• Kinsta výkonnostní benchmarky PHP ukazují, že WordPress 5.0 může provádět 3x tolik transakcí jako PHP 5.6; a
• Pantheon oznámil, že PHP 7 dalo 64% zlepšení oproti verzi 5.3.

pokud vám to nestačí, zkontrolujte své standardy a podívejte se, co říkají.

kromě toho byl PHP 7.0.0 vydán 3. Prosince 2015 a nejnovější stabilní verze 7.3.6 byla vydána 30. května tohoto roku.

a co víc, konečné vydání PHP 5, 5.6, šlo EOL (konec života) před 7 měsíci, 31. prosince 2018. Takže, pokud jste tak již neučinili, je to dávno, co jste provedli přechod na PHP 7. Proveďte upgrade a, jak řekl Rasmus na phpCE 2018, jděte zeleně (er) snížením nákladů na hostování.

odinstalujte Xdebug

další věc, kterou je třeba zkontrolovat, je, že Xdebug není nainstalován na vašich produkčních serverech. Jistě, Xdebug je jedním z nejsofistikovanějších a nejkomplexnějších profilerů a debuggerů pro PHP, ale nikdy by neměl být povolen (dokonce nainstalován) na produkčním serveru, alespoň dokud nebude vydán Xdebug 3 a měli byste se k nám připojit při podpoře Dericka, aby na něm pracoval.

zatímco výkonnostní standardy se liší (vždy se liší), jedna zpráva o přetečení zásobníku ukázala 50% zvýšení výkonu úplným odstraněním Xdebugu. A co víc, je důležité si uvědomit, že i když byl Xdebug nainstalován na serveru-nebyl ani povolen!

Xdebug performance benchmark

Chcete-li zkontrolovat, zda je nainstalován, spusťte php -m | grep -i xdebug nebo zkontrolujte administrační panel poskytovatele hostingu. A pokud se chcete dozvědět více o tom, jak Xdebug funguje, podívejte se na dokumentaci Xdebug.

Use Composer Optimize Autoloader

i když jsme všichni pravděpodobně velmi dobře obeznámeni s používáním Composer pro správu balíčků pro nás, pokud neuvažujeme o optimalizaci konfigurace, kterou generuje, naše aplikace nebudou fungovat co nejlépe.

zde je citát z dokumentace skladatele, který vysvětluje proč:

vzhledem k tomu, jak PSR-4 a PSR-0 autoloading pravidla jsou nastaveny, it skladatel musí zkontrolovat souborový systém před vyřešením název třídy přesvědčivě. To trochu zpomaluje věci, ale je to výhodné ve vývojových prostředích, protože když přidáte novou třídu, lze ji okamžitě objevit/použít, aniž byste museli znovu sestavovat konfiguraci automatického nabíjení.

pro zlepšení výkonu nabízí Composer tři úrovně optimalizace; jedná se o:

• generování map tříd
• autoritativní mapy tříd
• apcu cache

1: generování map tříd

tato strategie převádí pravidla PSR-4 / PSR-0 na pravidla classmap. Tato strategie je rychlejší, protože classmap může okamžitě vrátit úplnou cestu ke známým souborům a vyhnout se operaci souborového systému stat.

Chcete-li povolit tuto úroveň optimalizace, spusťte následující příkaz:

composer dump-autoload --optimize 

2/v: Autoritativní mapy tříd

kromě automatického povolení úrovně 1 se při použití této úrovně, pokud třída není nalezena v generované mapě tříd, autoloader nepokusí hledat na souborovém systému podle pravidel PSR-4. Chcete-li povolit tuto úroveň optimalizace, spusťte následující příkaz:

composer dump-autoload --classmap-authoritative 

2/B: mezipaměť APCu

tato úroveň přidává mezipaměť APCu jako záložní pro mapu třídy. Negeneruje však classmap. Vzhledem k tomu by úroveň jedna musela být povolena ručně. Chcete-li povolit tuto úroveň optimalizace, spusťte následující příkaz:

composer dump-autoload --apcu 

existují kompromisy

zatímco každá z těchto úrovní může zlepšit výkon aplikace, každá z nich má kompromisy, které je třeba pochopit před jejich použitím. Před použitím se ujistěte, že jste si přečetli dokumentaci skladatele.

použijte OPcache

protože PHP je interpretovaný, nikoli kompilovaný jazyk, musí PHP runtime převést zdrojový kód na spustitelný bajtový kód, než může být spuštěn. A protože PHP je architektura sdílená-nic, tento proces se musí stát na každém požadavku.

S mezipamětí Opcode (OPcache) se však tento krok musí stát pouze jednou pro každý soubor, protože generované Opcodes mohou být ukládány do sdílené paměti a místo toho tam odkazovány.

takže, jak si dokážete představit, OPcache je jedním z nejméně intenzivních způsobů, jak zlepšit výkon PHP aplikace, protože žádný kód se nemusí měnit. Některé zprávy ukazují až 70% zlepšení rychlosti.

v průběhu let existovalo několik mezipaměti Opcode pro PHP. OPCache (dříve Zend Cache) je dodáván s PHP od verze 5.5 – a je ve výchozím nastavení povolen v PHP 7.

Chcete-li se o tom dozvědět více, podívejte se na dokumentaci OPcache. Chcete-li se dozvědět více o vylepšení výkonu OPcache, podívejte se na vynikající článek Haydena Jamese a příspěvek Tidewaye o jeho ladění.

použijte předpětí PHP 7

pokud jste ještě neslyšeli o nové funkci předpětí PHP 7.4, je to velmi cool! Stručně řečeno, tato funkce posouvá funkčnost Opcache dále, než kdy předtím.

Chcete-li rychle shrnout, při prvním setkání se zdrojovým souborem PHP musí být analyzován a poté zkompilován do bytekódu závislého na stroji, než jej Motor Zend může spustit. Opcaches výrazně snížit režii tohoto procesu, jako po prvním, že zdrojový kód je analyzován a kompilován dolů bytecodes jsou pak uloženy v mezipaměti Opcode ve sdílené paměti.

při příštím požadavku na tento soubor PHP zkontroluje, zda mezipaměť Opcode má bytekódy souboru. Pokud ano, jsou vráceny a použity. Pokud tomu tak není (nebo pokud se zdrojový soubor změnil od zkompilování bytekódů), zdrojový soubor je analyzován, zkompilován a uložen do mezipaměti. To dává PHP pozoruhodný výkon.

nyní se podívejme, jak funguje Předběžné načítání. Citovat implementující RFC:

při spuštění serveru-před spuštěním libovolného kódu aplikace – můžeme do paměti načíst určitou sadu PHP souborů – a jejich obsah “trvale zpřístupnit” všem následným požadavkům, které budou serverem doručeny. Všechny funkce a třídy definované v těchto souborech budou k dispozici požadavkům po vybalení z krabice, přesně jako interní entity. Předpětí zajišťuje, že:

• všechny funkce a většina tříd definovaných v těchto souborech budou trvale načteny do tabulek funkcí a tříd PHP a budou trvale dostupné v souvislosti s jakýmkoli budoucím požadavkem.
• PHP řeší závislosti tříd a vazby s rodiči, rozhraními a vlastnostmi (něco, co se při ukládání do mezipaměti Opcode nestane).
• PHP odstraňuje zbytečné zahrnuje a provádí další optimalizace.

tím, že kód pro celou aplikaci, včetně jejího rámce (jako je Zend expresivní, Symfony a Laravel) předem načten do paměti, kód, který se změnil pouze při restartu serveru, bude většina aplikací fungovat výrazně lépe.

to znamená, že předběžné načítání má několik potenciálních nevýhod, o kterých byste měli vědět:

• při změně zdrojových souborů je nutný restart serveru.
• Předběžné načítání nebude fungovat v prostředí sdíleného hostingu.
• Předběžné načítání nebude fungovat, pokud existuje více verzí stejné aplikace.

Předběžné načítání není magické. Váš kód i procesy nasazení budou muset být přepracovány, aby bylo možné jej využít. Například někdo bude muset vyvinout vlastní skript zavaděče, aby určil, které soubory se mají načíst při spuštění serveru, a tento skript bude muset být spuštěn při spuštění serveru. Bez ohledu na to je to významné zlepšení, do kterého stojí za to investovat!

Nyní použijte Profiler

pro možnost, která zabere trochu více práce než kterákoli z předchozích pěti. Často skočíme a pokusíme se odhadnout, kde jsou překážky výkonu v našich aplikacích, pomocí intuice a vzdělaných odhadů.

i když to může fungovat, nejsou to nejúčinnější přístupy. Místo toho můžeme pomocí profilerů kódu analyzovat náš kód a ukázat, kde jsou úzká místa. Konkrétně pomáhají odpovídat na otázky, jako jsou následující:

• kolikrát byla každá metoda nazývána?
• jaká byla maximální doba provedení každé metody?
• jaká byla průměrná doba provedení každé metody?
• kolikrát byl soubor zahrnut?
• jakou cestou prošel požadavek aplikací(od prvního do posledního souboru kódu)?

vrtáním do výsledků profileru můžete být často příjemně překvapeni, i když spíše šokováni, když zjistíte, že vaše aplikace provádí kódové cesty a třídy, které jste nikdy neočekávali.

na základě informací ve zprávě profiler můžete vy a váš tým začít lépe porozumět tomu, co vaše aplikace dělá, a informovaně refaktorovat, abyste ji změnili podle potřeby.

pokud s profilováním teprve začínáte, je pro PHP k dispozici několik možností. Nejčastěji používané jsou:

• Xdebug profiler
• rozšíření XHProf Tideway (& XHGui)
• spx Profiler
• forp

na závěr

a to je pět způsobů, jak zlepšit kvalitu vašich PHP aplikací, zejména. Každý z nich sám o sobě vám přinese výrazné zlepšení výkonu. Při společném používání byste však měli očekávat významný výkon, nemluvě o kvalitě, zlepšení.