Celkem často lidé u svých stránek používají kešování či gzip, ale neuvědomují si, že je možné stránky urychlit už v samém začátku. Při generování. A proto si o tom dnes něco povíme.
Oč tu běží? Jaká to je metoda?
Abych nějak začal. Pokud používáte PHP tak asi tušíte, jak funguje.
Při načítání stránky se zpracuje několik PHP souborů, ty něco udělají a vyplivnou výsledek. A tohle dělají pořád dokola. Takže při jednom načtení této stránky se například zpracuje 10 PHP souborů, které vyšlou nějakých 20 dotazů do databáze. Ta odešle požadované informace a poté se vám zobrazí tato stránka.
To vše třeba za nějakých 200 milisekund.
A pak znovu a znovu. V ten moment si možná uvědomíte, že na hlášce „Zkraťte dobu odezvy serveru“ v PageSpeed Insights asi něco bude. Zjistíte, že existuje něco jako opcode cache
a najdete na vašem hostingu APC (Alternative PHP Cache). A o tom bude tento článek. O tom, jak zkrátit dobu odezvy svého webu pomocí Alternative PHP Cache.
Co je to APC? Nechytám se…
Rád bych tento článek věnoval konkrétnímu návodu a proto budu velmi stručný. Snad se nebudete zlobit.
APC je opcode cache
pro PHP. Je to keš jako každá jiná. Můžete si to představit tak, že se zkrátka již připravený kód uloží do keše a díky tomu stránky odpovídají rychleji. Při prvním načtení se prostě vše zpracuje, uloží do keše a další návštěvníci si už užívají rychlejších odpovědí, protože se už nekoná to kolečko popisované na začátku článku.
Stránky mají rychlejší odezvu, šetří se počet dotazů na databázi a výkon serveru. Navíc je toto kešování na straně serveru a tak se nemusíte bát, že se vám po FTP budou povalovat nějaké zvláštní soubory jako při použití pluginů, které vám na stránky ukládají statické HTML soubory. Typicky WP Super Cache či W3 Total Cache.
Jedinou nevýhodou je, že pro použití musíte mít PHP 5.2.4 a novější, podporu APC a používat redakční systém WordPress. Bez této kombinace máte smůlu a můj návod vám asi na moc věcí nebude. Bohužel.
Podporu APC snadno zjistíte…
Na technické podpoře či v souboru PHPInfo. Pokud tedy máte to štěstí a APC váš hosting podporuje, stačí ho v administraci svého hostingu zapnout a můžete pokračovat dále. Většinou řádek obsahuje něco jako apc.enabled
. Tak správnou volbu bezpečně poznáte.
Pro ilustraci ještě přidávám obrázek z administrace hostingu Savana.
Nyní si stáhněte APC Object Cache
To je plugin, který se vám postará o to, že všechny náročné věci, které WordPress provádí budou kešovány. Díky tomu budou stránky odpovídat rychleji a ušetří se opakující se dotazy do databáze.
Plugin si můžete stáhnout z oficiálních stránek či přímo z mého blogu pod tímto odkazem (ZIP, 2,94 kB).
Po rozbalení už jen stačí postupovat dle návodu.
Což znamená nakopírovat soubor object-cache.php
do složky, kde máte pluginy a šablony (standardně /wordpress/wp-content/
.
Od této chvíle by měl plugin fungovat. Všimněte si ovšem, že plugin nepatří (!) do složky plugins
jako ostatní, ale je přímo ve složce wp-content
. Také ho není třeba nijak aktivovat. Začne fungovat ihned po umístění.
A jak si tedy ověřím jeho funkčnost?
Nabízí se 2 možnosti. Tou první je stažení pluginu PHP Code Widget a následné umístění widgetu někam do postranního menu. Ideálně co možná nejníže v kódu.
Do widgetu poté vložte tento kód:
Počet dotazů na databázi: <?php echo get_num_queries();?>.
Ten by vám měl zobrazovat počet dotazů na databázi vašeho webu do aktuálního umístění v kódu. Ověření plyne z toho, že obyčejné PHP bez svého kešování bude zobrazovat stále stejné číslo. V mém případě při načtení hlavní stránky 22 dotazů na databázi. A toto číslo se nebude měnit.
Ale pokud kešování díky APC funguje, číslo by mělo při druhém načtení klesnout, protože se některé složité operace již načítají z mezipaměti. V mém případě se tedy nyní při načtení hlavní stránky posílá dotazů na databázi jen 8. Což značí, že mi plugin funguje správně.
Pro lepší představu vám zde ještě ukážu srovnávací obrázek, který porovnává počet dotazů na DB přes a po použití APC.
Druhou možností je klasické pozorování a porovnávání. Můžete si kupříkladu udělat vzorek průměrné odezvy vašich stránek před aktivováním APC a totéž udělat i po aktivaci. Výsledky pak porovnáte a okamžitě uvidíte, zda pro vás tato metoda má smysl a jestli přinesla tížené zlepšení.
Já toto udělal, a proto bych se zde rád podělil o výsledky. Přijdou mi totiž poměrně zajímavé.
V testu jsem měřil rychlost hlavní stránky tohoto blogu. Pro nováčky připomenu – toto jsou čísla doby odezvy. To znamená, jak dlouho serveru trvalo požadavek zpracovat, aby mi byl schopen poslat zmiňovanou stránku nazpět. Čísla jsou v milisekundách.
Při vypnutém APC jsem došel k těmto číslům:
390, 330, 419, 297, 431, 312… – tedy 355 milisekund průměrně.
Po zapnutí APC a nahrání pluginu byla čísla:
173, 208, 164, 142, 195, 233… – tedy 183 milisekund průměrně.
Takže nyní v průměru ušetřím 0.172 sekundy každým načtením.
Někomu se to může zdát málo, ale pokud přihlédneme k možnostem této metody, jde o skvělé hodnoty. Jedná se totiž o celou polovinu té původní (bez použití APC). A rychlá odezva serveru je hodně důležitá.
To mi jistě dáte za pravdu.
{ Komentáře k článku }
Proč používat normální dev stack, když můžu mít PHP, kam pro rozumný výkon musím dolepovat tisíc podobných berliček.
Proč PHP v základu funguje tak, že dělá kompletní analýzu kódu pro každý request a pak všechno zase zahodí? To nechápe nikdo :).
Ještě by chtělo zmínit, že nejnovější PHP 5.5 již obsahuje OP CACHE.
Jsem rád, že ses vrátil k psaní. Tvé články o optimalizaci webových stránek a jejich zrychlování velice rád čtu :).
[1] Myslím si, že někdy v roce 1995, když se PHP začalo tvořit nikoho nenapadlo, že budou i weby s návštěvností nějakých 70.000 unikátních návštěvníků a že bude třeba nějak zařídit, aby se každou sekundu vyřídilo co možná nejvíce požadavků. Nějak moc bych jim to za zlé neměl.
Instalace APC není tak těžká a člověk, který tu práci dělá má k dispozici na oficiálních stránkách pěkný a podrobný návod.
[2] Jo, tak to má kupříkladu hosting od Blueboard. Ono je v podstatě jedno, jaké řešení člověk použije. Hlavně, že se kód ukládá do nějaké keše a je tak PHP rychlejší.
[3] Díky za kompliment. Jsem za to rád. Ale tento článek byl spíše výjimkou. Okolo zrychlování webu už v podstatě není o čem psát. To důležité jsem totiž již sepsal a o všeobecných doporučeních se tu zmiňovat nechci. Toho je na internetu všude dost.
Ale psát budu pochopitelně dál. Když bude čas a nálada.
Tomas davam ti palec hore a naozaj chválim článok. Super že si spet a neriešiš blbosti ako online hry s nulovim prínosom pre tvojich čitatelov.
Díky za článek. Netušil jsem, že existuje něco jako kešování PHP výstupu a že nějak jde ovlivnit rychlost odpovědí serveru.
Napíšu na podporu svého hostingu a uvidím. Snad toto podporují. Bylo by to super.
Komentáře jsou pro tento článek již uzavřeny.