WordPress for Speed – avagy WP gyorsítás

A function_cache fügvény kapcsán jött elő a kérdés, hogy mennyit is számít pontosan ez a rendszer teljesítményét figyelembe véve.

A pontos válaszhoz először is azt kell megnéznünk, hogy milyen szinteken lehet egy weblapot cachelni illetve hogy melyik szintnek milyen előnye, hátránya van.

WordPress Cache plugin

Első szint a wp_cache plugin, amit a wordpress belső magja alkalmaz. Fő célja, hogy a többszörösen összetett lekérdezések eredményét eltárolja az adatbázisban és egy egyszerű lekérdezéssel kiváltsa azt. Ez ugyan erősen kiméli az adatbázist és mérhető javulást is hoz, de azért egy csomó számitásnak még itt is le kell futni ahhoz, hogy megkapjuk az eredményt. Ugyanakkor ahol alkalmazzák ezt a cache-t, ott megoldható, hogy az alap adatok változása esetén törlődjön a cache és újra generálódjon, így gyakorlatilag 100%-os találati arányt generál és mindig pontos, konzisztens adatokat szolgáltat.

Function cache

A következő szint a function_cache, ami egyes template függvények HTML kimenetét gyorsítótárazza a szerveren azért, hogy adatbázis műveletek nélkül, a függvény meghívása nélkül, a kapcsolódó objektumok felépítése nélkül produkálja a kimenetet. Előnye a kisebb memória fogyasztás, a gyorsabb végrehajtás. Hátránya, hogy a cache idő fügvényében lemarad a valóságtól és csak periodikusan frissül, ugyan akkor ez bizonyos esetekben teljesen elfogadható (lsd pl. arhívum kezelése).

Statikus HTML kimenet generálása

A harmadik szint az, amikor a lap teljes HTML kimenetét mented el a szerveren. Ekkor ha találat van, a cache-ben gyakorlatilag egyetlen file_get_content hivásból és néhány alap matematikai műveletből meg lehet úszni a teljes lapkiszolgálást, és se adatbáziskapcsolatot, se komolyabb php műveleteket nem kell végezned. Persze mint minden megoldásnak, ennek is van hátránya, mégpedig hogy a lapok cachelésével az oldalsó blokkok frissülése eléggé esetlegessé válik.

De ezt vagy ajax hivásokkal (amik szintén előre legenerált json/xml file-okat hívnak), vagy pedig olyan lapszerkezet felépítéssel lehet megoldani, ami nem tartalmaz a laptól függetlenül frissülő adatokat és így nem lesznek „beragadt” tartalmi elemek. Ilyen kód fut most a tutorial.hu alatt is. A kezdő oldal és a feed-ek teljes HTML cache-ben vannak tárolva, ami egy kis plusz segítséget jelent a szervernek. Az általunk használ megoldás hamarosan publikálva lessz itt a lapon. Ennek alternatívája a WP-Cache2. Ez kicsit átmenet a második és harmadik szint között, de közelebb áll a harmadikhoz.

CDN használata

A negyedik szint akkor következik be, amikor belátjuk, hogy minden trükkünk ellenére sem vagyunk képesek kiszolgálni a bejövő forgalmat. Ha a fenti 3 lehetőség már végigzongoráztuk és még mindig nem működik megfelelően a lap, akkor bátran kijelenthetjük, hogy nem a CPU/memória a kevés, hanem a rendelkezésre álló sávszélesség lesz a szűk keresztmetszet. Ekkor lehet az előző cikkben Benjamin által emlegetett Digg Defender pluginhez fordulni. Ez azonban már nem egyszerű dolog, hiszen a kiszolgálást gyakorlatilag átirányitjuk egy CDN-re (Content Delivery Network, Tartalom Kiszolgáló Hálózat), ami a világ 260 pontján lévő közel 3000 szerverével fog besegíteni a lapunk kiszolgálásba. Ehhez azonban már jóval komolyabb módosítások szükségesek, hiszen a HTML-t át kell jutatni a CDN-re, a képek hivatkozását vagy cserélni kell ebben a lapban, vagy eleve külső site-ra kell hivatkozni (Flickr, PhotuBucket), illetve a bejövő kéréseket egy Apache rewrite szabályal átirányítani a CDN belépő pontjára.

Ha mindezek a trükkök nem elegek a blogunk / lapunk kiszolgálására, akkor jönnek az egyedi felépítésű webrendszerek. Ilyen esetben kérlek keress meg, referenciákkal, több éves tapasztalattal és egy pár fős profi csapattal állok a rendelkezésedre.

Szerző: TLoF (web-solution.hu)