WebToDate/Cachování/Reference

Přehled možných režimů cache

Existuje několik režimů cache, které se od sebe liší tím, jakým způsobem se vyhodnocuje, zda se má použít verze uložená v cache nebo zda se má stránka znovu sestavit a do cache uložit její nová verze. Tyto možné režimy jsou shrnuty v následující tabulce.

Režim	Popis
Řízení podle času	Existuje-li v cache příslušný soubor, použije se, není-li jeho čas modifikace starší než zadaný interval. Nastaví-li se interval na jednu hodinu, bude se celou jednu hodinu zobrazovat stejná podoba stránky, po uplynutí této hodiny se soubor v cache vždy přepíše (v momentě zobrazení zprávy) aktualizovanou podobou stránky. Výhodou tohoto režimu je to, že se v případě, že se načítá zpráva z cache principiálně prezentační skript vůbec nemusí připojit k SQL databázi, což je z hlediska optimalizace výkonu samozřejmě nejlepší stav. Nevýhodou je to, že pokud dojde k modifikaci zprávy, je po nějakou dobu i nadále návštěvníkům zobrazována předchozí verze zprávy.
Řízení podle data modifikace zpráv	Při zobrazení stránky se skript připojí k databázi a zjistí, zda datum modifikace zprávy je starší než datum příslušného souboru v cache. Zpráva se tak zobrazuje v neustále stejné podobě po neomezenou dobu do té doby, než někdo zmodifikuje danou zprávu. Výhodou je zde to, že systém okamžitě reaguje na změnu obsahu zprávy, nevýhodou je nutnost připojit se k databázi. I když se v tomto případě jedná o nenáročný dotaz, který pouze vyhledává v jedné tabulce jedno datum, existuje nezanedbatelná režie pro připojení k databázi a odpojení, tudíž v tomto režimu není optimalizační efekt tak velký jako v předchozím případě.
Řízení podle času a data modifikace zpráv	Jde o kombinaci předchozích dvou režimů, tedy vždy se ověřuje, že zpráva nebyla modifikována a i v případě, že k modifikaci nedošlo se soubor v cache obnovuje po uplynutí daného časového intervalu.

Zdůrazněme zde, že skutečnost, že zpráva nebyla modifikována v principu není totožná se skutečností, že se nemá změnit stránka zprávu zobrazující. Pokud jde o samotný text zprávy, je mezi těmito dvěma skutečnostmi přímá souvislost, změny ale mohou nastat v ostatních částech stránky. Zejména jde o následující možnosti:

• Změnil se obsah seznamu souvisejících zpráv – v databázi zpráv se objevila nová zpráva vyhovující kritériu v daném seznamu typu propojení.
• V zdroji připojeném ke zprávě byl změněn nějaký soubor. Datum modifikace zprávy se změní v případě, že přidáme nebo odstraníme nějakou přílohu, nezmění se ale v případě, že tuto přílohu vyměníme za jiný soubor (např. upravíme na straně serveru existující obrázek).
• Změnila se struktura stromu kategorií a s tím související navigační nabídky – tato změna opět nijak nepoznamená datum modifikace zprávy, ale měla by znamenat, že automaticky generované navigační nabídky na stránce zobrazující zprávu by se mohly změnit.
• Změnil se předloha (šablona) pro zprávu.

Konfigurační parametry

Následující tabulka obsahuje přehled konfiguračních parametrů cache, které se nacházejí v souboru global.php.

CACHE_REGIME	Režim cache. Vysvětlení těchto režimů je v předchozí kapitole, možné hodnoty jsou: 0 – cache je vypnuta 1 – řízení podle času 2 – řízení podle data modifikace zpráv 3 – řízení podle času a data modifikace zpráv
CACHE_REFRESH_INTERVAL	Interval v minutách udávající dobu platnosti položky v cache. Smysl má pro režimy 1 a 3, v ostatních případech se ignoruje.
ALLWAYS_USE_CONNECTION	Vynucené připojení k databázi. Při zobrazení zprávy se skript připojí k databázi, i když by to z hlediska režimu cache nebylo nutné (tj. používá se režim 1). Tuto hodnotu je třeba nastavit na true v případě, že jsou instalovány další extenze, které používají databázi a jejichž výstup není vhodné nebo z principu nemůže být cachován. Z dodávaných krabicových modulů se jedná o: Diskuze (pokud používáte diskuze pod článkem) Ankety (pokud používáte ankety ve zprávách) Neveřejná část Započítávání shlédnutí zpráv pomocí extenze /scripts/modules/artviews/_artview_post_inc.php
PATH_TO_CACHE	Cesta k adresáři, kde se ukládají soubory cache. Ve výchozím nastavení se jedná o adresář offlinedata/artcache/.

Cachování pouze částí stránek

Princip extenzí WebToDate a vlastního cachování speciálně znamená, že neplatí, že se musí nutně cachovat celý HTML kód stránky se zprávou. Může dojít i k tomu, že se pro každou zprávu cachuje jen část kódu a zbytek se doplní až při žádosti o zobrazení.

Princip se nejlépe objasní na následujícím příkladu. Stránka zobrazující zprávu může zobrazovat různé položky (pole) databáze zpráv a další objekty. Na obrázku níže se jedná o tyto vybrané objekty:

• Nadpis zprávy
• Popis
• Tělo včetně obrázků či jiných souborů vložených z databáze zdrojů
• Seznam souvisejících zpráv
• Seznam příloh ke stažení
• Seznam diskuzních příspěvků ke zprávě

Jako výchozí objekt pro zobrazení takové stránky se nalezne odpovídající předloha (šablona) stránky. Předloha obsahuje pro každý z výše zmíněných objektů jedno klíčové slovo, za které se má dosadit obsah. Prezentační skript pro zprávy má funkce pro načtení odpovídající předlohy, vložení polí zprávy jako nadpis či tělo, vložení souborů ze zdrojů i vytvoření seznamů souvisejících zpráv či příloh. Nemá však žádné funkce pro diskuze, přesto se zde diskuze mohou zobrazit. To se stane díky otevřené architektuře WebToDate - do procesu sestavování celé stránky je zapojena tzv. extenze, která je součástí modulu Diskuze a jejímž jediným úkolem je nahradit jediné klíčové slovo (značku) vyhrazené v předloze zprávy odpovídajícím obsahem - stromem diskuzních příspěvků.

Z hlediska zpracování tedy dojde k následujícím krokům:

1. Sestaví se celý kód HTML stránky kromě diskuzí
2. Spustí se extenze pro diskuze a doplní se seznam diskuzních příspěvků
3. Výsledný kód se odešle do prohlížeče.

Neplatí při tom, že pod bodem 2. se může skrývat spuštění jen jednoho kódu. Dalším příkladem jednoho z krabicových rozšíření je vložení hlasovací ankety; do procesu si můžete vložit i vlastní extenzi - PHP kód, který např. podle jména autora zprávy doplní do stránky jeho fotografii, vypíše do stránky aktuální datum a čas zobrazení nebo provádí jakékoliv další operace se sestaveným HTML kódem. Přitom všechny tyto extenze jsou na stejné logické úrovni jako extenze pro cachování a jejich volání se nachází v souboru /config/_modules_inc.php.

Z toho vyplývá, že na pořadí volání extenzí zde v tomto případě velmi záleží. Pokud vezmeme příklad uvedený výše, můžeme kódy volat v pořadí

Sestavení zprávy - uložení do cache - sestavení diskuzí.

To v tomto případě vede k žádoucímu výsledku - při načtení obsahu z cache nebude stránka obsahovat diskuze, spustí se extenze pro diskuze a doplní aktuální seznam příspěvků. Pokud ovšem pořadí pozměníme:

Sestavení zprávy - sestavení diskuzí - uložení do cache,

bude výsledek patrně nežádoucí. Soubory v cache budou obsahovat HTML kódy stránek včetně stromu diskuzních příspěvků. Při novém načtení se extenze pro diskuze sice spustí, ale tento kód zjistí, že ve stránce žádné klíčové slovo pro seznam příspěvků není a odešle stránku dál, výsledkem bude, že všichni návštěvníci dostanou stejný seznam příspěvků a vložení nějakého příspěvku se po určitou dobu (v extrémním případě v režimu 2 nikdy) neprojeví.

Proto je žádoucí vložit extenzi pro zápis do cache před všechny extenze, které poskytují z principu dynamický obsah. Neplatí to samozřejmě univerzálně - pokud máte vlastní extenzi doplňující fotografii autora, budete patrně očekávat, že všichni uživatelé zobrazující stejnou zprávu uvidí stejnou fotografii stejného autora, tudíž výstup takové extenze je naopak velmi vhodné do cache uložit.

Analogicky toto platí i pro extenzi čtení z cache v souboru _preprocess_inc.php. I zde se musíte rozhodnout, které kódy je třeba spustit před případným čtením z cache - jakmile je jednou kód stránky z cache načten, vlastní kód pro sestavení stránky se nespouští a pokračuje se dalšími extenzemi.

Plánovaná úloha na mazání cache

K čemu je úloha pro mazání obsahu cache

Součástí rozšíření je i úloha pro Plánovač úloh, která slouží k mazání obsahu cache. Z principů vytváření obsahu cache uvedených v předchozích kapitolách vyplývá, že položka se do cache přidává nebo se mění ve chvíli zobrazení nějaké zprávy. Tento proces ale neřeší případné odstranění položek z cache. Tato potřeba může nastat v následujících případech:

• Chcete odstranit z cache soubory, které vznikly před delší dobou (např. z důvodů šetření diskové kapacity). Pokud je zapnuta cache a došlo k jednomu zobrazení nějaké zprávy např. před týdnem, je taková zpráva v cache v některých režimech v podstatě nepotřebná – pokud je režim cache jiný než 2, je patrně nastaven interval obnovy v konstantě CACHE_REFRESH_INTERVAL menší než jeden týden a tudíž by při dalším zobrazení této zprávy došlo k znovusestavení stránky a přepsání této položky v cache.
• Změnil se design serveru ve smyslu úprav v předlohách pro zprávy a je třeba zajistit, aby se změny okamžitě promítly na celý web.

V prvním případě bude vhodné úlohu spouštět plánovaně (např. jednou za noc nebo jednou za několik dní), v druhém případě bude vhodné úlohu spustit interaktivně z administračního rozhraní WebToDate.

Popis funkce Plánovač úloh, způsob vytváření plánovaných úloha apod. naleznete v Referenční příručce WebToDate.

Konfigurace plánované úlohy

V nastavení plánované úlohy Expirace cache jsou k dispozici následující parametry.

Stáří souboru	Maximální stáři položek v cache v minutách. Po spuštění budou soubory starší než zadaný počet minut smazány. Pokud nechcete tuto možnost použít, zadejte hodnotu -1.
Velikost cache	Maximální velikost cache v kB. Soubory budou smazány tak, aby velikost cache byla maximálně tento údaj. Soubory se mažou dle data modifikace od nejstarších k novějším. Pokud nechcete tuto možnost použít, zadejte hodnotu -1.

Soubor:Image004.jpg

Pokud jsou nastaveny oba parametry, bude výsledek takový, že budou smazány zprávy starší než daný počet minut, pakliže velikost cache i nadále bude přesahovat stanovený objem, dojde k dalšímu odmazávání souborů, než bude dosaženo stanovené velikosti.

Pokud chcete kompletně smazat celý obsah cache, zadejte do obou parametrů hodnotu 0.

Vlastností funkce Plánovač úloh je to, že jedna úloha může být použita ve více sekvencích s různým časováním. Můžete tedy jednou za několik dní pomocí jedné sekvence zmenšovat velikost cache na požadovanou velikost a zároveň mít připravenou pro ruční spuštění sekvenci, která v případě potřeby odstraní celý obsah cache.

Které stránky se cachují

Cachují se jen zprávy a jen ta zobrazení zpráv, kde jediným parametrem je ID zprávy. Jedná se tedy o stránky s URL /scripts/detail.php?id=xxx (pokud používáte např. modul mod_rewrite serveru Apache pro změny těchto URL, nemá to na požadovanou funkčnost vliv, pro PHP skript je to transparentní a volání typu např. /clanekxxx.htm, které se pomocí mod_rewrite interně překládá na /scripts/detail.php?id=xxx se cachuje rovněž).

Naopak se stránky necachují v případě, že je uveden jakýkoliv jiný parametr než id. V praxi je nejběžnější varianta /scripts/detail.php?pgid=xxx (dynamické zobrazení stránky) nebo /scripts/detail.php?id=xxx&tmplid=yyy (vynucení jiné šablony stránky např. pro účely tisku).

Tuto vlastnost můžete využít i pro účely ladění stránek. Pokud připravujete design webu a testujete jeho funkčnost a přitom je cache zapnuta, používejte URL např. ve tvaru /scripts/detail.php?id=34262&cache=no, pak máte zajištěno, že se stránka z cache nenačítá a zobrazuje se aktuální podoba zprávy.

Související funkce WebToDate

Ke smazání zprávy z cache dojde vždy v případě, kdy se zpráva upravuje a dojde ke změně jejího stavu z Publikováno na jiný stav. Pokud zprávy není ve stavu Publikováno, v cache se tedy nenachází:

1. Dokud se zpráva připravuje a je v jiném stavu, lze ji zobrazovat jen přes náhled a tudíž se necachuje.
2. Když je zpráva publikovaná a její stav je změněn na jiný, z cache se odstraní.

Tento mechanismus brání tomu, aby se z cache nenačítaly nepublikované zprávy a tudíž nedošlo k jejich nechtěnému zobrazování.

Za změnu stavu se v tomto případě považuje i úplné vymazání zprávy z databáze, takže i tomto případě je zpráva okamžitě odstraněna z cache.