Rychlost na produktu řešíme průběžně, nasazujeme různé cache, indexujeme databázi apod. V březnu/dubnu jsme se společně s produkcí čelili problému, kdy bylo potřeba načítat pro e-shop www.slezak-rav.cz velké množství obrázků do kategorií pro horní menu. Vzhledem k tomu, že toto menu je plněno ručně, nebylo možné připravit si data dopředu. Kvůli tomu, že původní řešení obsahovalo načítání obrázků ajaxem bylo rozhodnuto, že se řešení převezme a vytvoří v prostředí e-shopu.
Najednou jsme na testovacím serveru stáli před problémem, kdy najetí na položku menu znamenalo zpoždění i více jak 1s pro načtení vlastního obrázku. Ano, testovací server obsahuje pozapínané nějaké komponenty pro ladění navíc, které mají za následek drobné zpomalení načítání výměnou za rychlejší programování. Nicméně bylo jasné, že při převodu na produkční implementaci bude výkon této úpravy tragický. Bylo nutné tedy vymyslet nějaké funkční řešení. A pokud možno rychle.
Vzhledem k tomu, že optimalizace je proces, kterému se věnujeme průběžně, bylo třeba zkusit něco nového. Něco, co nemáme ozkoušeného. Po delším hledání a procházení mnoha doporučení, která jsou již ozkoušená a popř. i implementovaná, jsme našli článek, který se netýkal optimalizace kódu, ale konfigurací serveru. První věcí, kterou jsme vyzkoušeli, bylo zvětšení realpath cache. Změnou nastavení jsme omezili počet dotazů PHP na umístění souborů. Dostali jsme se tak na testovacím serveru konečně pod vteřinu, cca na 500 - 800 ms a na produkčním prostředí jsme se dostali cca na 400-500 ms. Což už je podstatně rychlejší, stále však lidským okem postřehnutelné.
Druhou možností, pro kterou jsme se rozhodli, byla úprava OPCache, přesněji řečeno její opětovné zapnutí. OPCache na produktu již běžela, nicméně kvůli interní chybě bylo nutné ji vypnout (s odhalením této chyby nám pomáhal náš partner Cluster Design s. r. o.). Nad opětovném zapnutím OPCache jsme uvažovali už delší dobu a teď jsme ji mohli zkusit, a zjistit, jestli nám nepomůže i v našem problému. Testovací prostředí máme vlastní, za které jsme zodpovědní a případné odstavení lokálních implementací není problém (narozdíl od ohrožení byznysu zákazníka). Po tom, co jsme nad celým lokálem aktivovali OPCache, a dostali se na cca 300 ms bylo rozhodnuto, že se pokusíme znovu OPCache zapnout.
OPCache jsme postupně začali zapínat na jednotlivých implementací. Otázkou bylo, jestli úprava nebude mít vliv na stabilitu serveru. OPCache jsme zapínali pro jednotlivé implementace a sledovali jeho chování, zejména v průběhu pravidelných aktualizací. Stejným způsobem jsme prozatím nasazovali úpravu realpath cache. Do implementace www.slezak-rav.cz jsme přidali pár parametrů, které OPCache zapínají a řídí, a dali se testovat. Výsledkem zrychlení na ~100-120 ms, místy i pod 100 ms, což už je okem skoro nepostřehnutelné.
Zapínali jsme ho pro jednotlivé implementace a sledovali jeho chování. Zejména v průběhu pravidelných aktualizací. V současné době máme řešení OPCache nasazené na všech serverech a je výchozím řešením pro všechny implementace.
Na poměrně jednoduchém příkladě vám ukážeme postup této optimalizace v praxi. Zrychlení samozřejmě nemá vliv jen na krátké ajaxové dotazy, ale na rychlost napříč celým e-shopem.
Porovnávali jsme v Universal Analytics od Googlu (dále UA) na dlouhodobém průměru návštěvnosti reálných zákazníků. Celkové zrychlení serveru bylo v řádu 100 ms. E-shop zasílá desítky dotazů a tím se celkové zrychlení pohybovalo od 3 – 12 s. Zaměřili jsme se převážně na obrázky a ty určovaly i přínos.
Ve třetím balíčku tento rok se zaměříme na CCS styly. Budeme řešit rychlejší vykreslení a asynchronní načítání webfontů. Opět se podíváme na obrázky. Čekají nás nové formáty např. webP nebo lazyload. Věříme, že se opět posuneme o kus dál.
Realpath cache: stará se o ukládání cest k souborům do paměti, resp do hashovací tabulky, tedy aplikace ví které soubory kde má a nemusí je pořád hledat, což má velký význam pro frameworky, u kterých se cesty nemění a je jich samozřejmě hodně.
OPCache: stará se o vlastní zacachování souborů, scriptů. PHP je jazyk interpretovaný, nikoliv kompilovaný, resp při každém požadavku je kód zkompilovaný na binární kód (OPcode - z toho také OPCache) a to dále engine interpretuje. To znamená, že při každém zavolání aplikace je třeba nejprve zjistit jaké soubory jsou vyžadovány, ty "spojit" dohromady a převést na strojový kód. O první cachování se stará sama symfony cache, která si přednačte scripty a vytvoří z nich ideálně jeden velký soubor a není potřeba tento vytvářet vždy. Znamená to ale stále otevřít soubor a zkontrolovat, zvalidovat všechny vstupy, proměnné apod. OPCache si ještě scripty ukládá přímo do paměti stroje, proto práce s nimi je mnohem rychlejší, na druhou stranu to byl důvod, proč jsem se nerozhodli nasazovat OPCache rovnou, ale postupně.
