Kešování HTML výstupu

Furt se to snažím pochopit a moc mi to nejde.

Kešováním pomocí: $presenter->lastModified($modified[, $etag, [, $expire]])

bych chtěl dosáhnout toho, aby když uživatel přijde na stránku, tak se pro něho zakešovala na xx sekund, asi že?

Tzn expires bych nastavil na těch xx sekund, ale na co mám nastavit $modified? Na now?

Neni mi totiž jasná tahle část:

Metoda jednak nastaví hlavičku Last-Modified, ale především zkontroluje, zda se klient neptá hlavičkou If-Modified-Since, jestli se stránka od určitého času nezměnila … Pokud se nezměnila, je presenter ukončen metodou terminate(). Ušetří se čas generování stránky a přenesený objem dat na straně serveru i klienta.

Konkrétně se píše „jestli se stránka od určitého času nezměnila“ Od jakého času? Od toho co byl prohlížeči nastaven v hlavičce last modified?

Tu cache na straně serveru bych použil při nakechování celé stránky třeba po pěti minutách pro všechny uživatele, to chápu.

Editoval veena (14. 8. 2008 9:34)

Jinými slovy: $modified by se měl nastavit na čas modifikace nejnovějšího prvku na stránce.

Pokud mám tedy na stránce třeba prvky: článek, blok s novinkami a anketu, článek byl naposledy modifikován včera, do bloku s novinkami přišla poslední zpráva před půl hodinou a počet hlasů v anketě se změnil před minutou, tak to nastavím na čas modifikace (tzn. posledního hlasu) té ankety. Pokud bych pak upravil článek, ale nevytvořil bych žádnou novinku a nikdo by mi nezahlasoval do ankety, tak to musím nastavit na datum modifikace článku.

Konkrétní řešení by vypadalo třeba definicí nového rozhraní (a k tomu rovnou třeba i abstraktní komponentu, která by část práce udělala za programátora), které by nakazovalo implementovat metodu třeba getLastModificationTime. Ta by vracela čas poslední modifikace. Všechny prvky na stránce, které by se mohly změnit, by implementovaly toto rozhraní/dědily od komponenty. Ve vhodný okamžik (tzn. v moment, kdy už všechny komponenty budou znát datum své poslední modifikce – záleží na konkrétní aplikaci, pravděpodobně by to však mělo být před renderováním, nebo na konci metody render{view}()) by se prošly a našel by se čas poslední modifikace. Pokud by stránka s nějakou komponentou raději neměla být kešována, tak stačí, aby její LastModified() vždy vracelo now.

Panda napsal(a):

Pokud by stránka s nějakou komponentou raději neměla být kešována, tak stačí, aby její LastModified() vždy vracelo now.

Co se stane, když sem nastavil LastModified(time()-120) ?

Zakešuje mi to po prvním přístupu na 2 minuty v prohlížeči?

Mě to mozek prostě nějak furt nebere :-(

Editoval veena (21. 8. 2008 23:18)

David Grudl napsal(a):

Metoda lastModified pracuje jen na produkčním serveru, tedy když Environment::isProduction() vrátí FALSE. To lze ovlivnit přes Environment::setMode('production', TRUE).

Sice to je takhle napsáno i v dokumentaci, ale není to překlep? Já měl za to, že na produkčním serveru by mělo Environment::isProduction() být TRUE

FALSE by vrátilo jen na localhostu, pokud nastavím prostředí PRODUCTION a dojde na detekci módu

Environment::setName(Environment::PRODUCTION);
Environment::isProduction(); // FALSE

protože mód production se určuje podle adresy serveru.

Proto radši používám takovéto nastavení v bootstrapu

// Environment::setName(Environment::DEVELOPMENT);
Environment::setName(Environment::PRODUCTION);

$config = Environment::loadConfig();

Environment::setMode('production', Environment::getName() == Environment::PRODUCTION  ? TRUE : FALSE);
Environment::setMode('debug', Environment::getName() == Environment::DEVELOPMENT ? TRUE : FALSE);

Debug::enable(NULL, NULL, $emailHeaders);
// parametr logování chyb je NULL, takže se rozhodne podle autodetekce z Environment podle řežimu production, tzn: Environment::isProduction() ? 'logovat' : 'zobrazovat'

if (Environment::getName() == Environment::DEVELOPMENT) { Debug::enableProfiler(); }

// a možná se bude hodit i automatické zachytávání výjimek
$application = Environment::getApplication();
$application->catchExceptions = Environment::getName() == Environment::PRODUCTION ? TRUE : FALSE;

// nebo klidně takto, protože Environment::isProduction() již vrací TRUE
$application->catchExceptions = Environment::isProduction() ? TRUE : FALSE;

kde výběr prostředí a tím i chování aplikace (zachytávání/zobrazování výjimek a logování) provádím jen zakomentováním jednoho ze dvou řádků pro nastavení jména prostředí, vše ostatní se už pak odvíjí od toho, takže pokud teď chci na localhostu nasimulovat chování v produkčním prostředí, správně se mi nastvaví i mód production.

Pokud to uznáte za přínosné, může se to doplnit jako tip do dokumentace.

David Grudl napsal(a):

Můžeš si pro každé prostředí dát do config.ini

[production]
mode.production = yes

[development]
mode.production = false

a mód se ti bude nastavovat už při Environment::loadConfig().

Tím se to hezky zjednodušuje, mělo mě trknout podívat se do examples :)

To bych nedělal. To bude fungovat jen v případě, že používáš právě tyto dvě prostředí. Jakmile budeš potřebovat více prostředí, narazíš na problém.

Na tom je to založené, zatím mi stačila tyto dvě prostředí. Jde spíš jen o takovou automatizaci, kdy hodně často měním tyto dva režimy a testuju, ať nemusím přepisovat nebo komentovat na více místech.

Možná bude lepší ale použití

if (!Environment::isProduction()) { Debug::enableProfiler(); }

Editoval romansklenar (14. 9. 2008 20:59)

romansklenar napsal(a):

Nevíte někdo jak vyhazovat/zpracovávat vyjímky při zaplém output bufferingu z úvodního postu tak, aby k ukončení aplikace a nezůstala viset na prázdné bílé obrazovce a zároveň aby se logovaly? (logování mám vyřešeno v ErrorPresenteru, tzn stačilo by mi to předat nějak na něj, s vyplým output bufferingem to vše funguje, vyjímka se předá a zpracuje v ErrorPresenteru). Any ideas?

Imho to nebude chyba output bufferingu. Mně to funguje naprosto v pohodě. Nejčastěji jsem na bílou obrazovku smrti narazil, když se mi vyskytla chyba, která spustila přesměrování na ErrorPresenter a při tomto přesměrování nastala další chyba.

Zdravim vas…

Mam problem. Ve startup() zapnu ob_start(); dale v shutdown() si stahnu data z bufferu $content = ob_get_flush(); a nejak s nima pracuji.

Vse je OK do chvile kdy dojde na strance k presnerovani. V tu chvili mi to vyhodi vyjimku, ze nemuze modifikovat hlavicky, protoze radek s $content = ob_get_flush(); pry odeslal nejaky vystup.

Kde je problem?

Dalo by se to obejit, kdyby slo nejak detekovat zda nedoslo k presmerovani, ale jak na to jsem neprisel.

Dle doporuceni jsem zacal kesovat ve startup(), driv to snad krome konstruktoru nejde. A resit logiku pohledu ve startup se mi nechce.

Nebo je vhodne OB zapnout az na konci prepareXzy() nebo beforeRender()? Logicke by mi prislo kesovat od beforeRender() po afterRender(), ale pokud se nepletu tak v dobe volani afterRender jeste neni vyrenderovan cely layout, ale jen scena.

Pokud myslis https://forum.nette.org/…iewtopic.php?… tak bohuzel uz to nejde stahnout:(( Nemas to nekde?

Nedari se… Vpodstate to mam stejne. Zapnu OB, vypnu OB ziskam data a vypisu. Pri redirectu zadna data nejsou. Overeno:

$content = ob_get_flush();
echo "'".$content."'";	// vypise ''
die();

Tak at mi to netvrdi, ze byl nejaky vystup vygenerovan!!! Uz me napada jedine BUG v PHP.

To je opsane od Davida viz nahore. Navic potrebuji vysledek pro sebe (cache) a zaroven poslat uzivateli:)

Tak jo asi bug v php protoze:

// nejde
$content = ob_get_flush();

// jde
$content = ob_get_clean();
echo $content;

I kdyz principelne by to melo byt totozne ne?

kravco napsal(a):

Narážal som tým najmä na toto, predtým som neúplne citoval…
Totiž ob_get_flush() výstup odosiela, po jeho volaní sú už hlavičky odoslané.

Takze to odesle i nic? To bych povazoval za BUG:)

_Martin_ napsal(a):

Těžko říct takhle, co se tam přesně děje, ale doporučuji používat fci ob_get_clean() – jinak by jsi – pokud dojde k přesměrování na další kešovaný presenter – spustil v metodě startup nové bufferování, aniž by jsi předchozí ukončil.

Novy request po presmerovani by nemel ovlivnit predchozi, ohledne OB. Kazdy reqest zacina s cistou pameti, krome session:) Leda ze myslis vnitrni Nette predani.

Mezi ob_get_flush() a ob_get_clean() je zásadní rozdíl – clean obsahu bufferu jen vrátí, flush do vypíše a vrátí.

Chybou je, že jsem v uvedeném řešení s přesměrováním nepočítal. Nenapadlo mě to. Šlo by to upravit takto:

	protected function shutdown()
	{
		if ($this->cacheKey) {
			$content = ob_get_clean();
			if ($content) {
				echo $content;
				...
			}
		}
	}

Ale ani to není úplně ideální – cache by totiž neměla v případě chyby nic ukládat. Takže jsem upravil Presenter, aby metodě shutdown() předával případnou zachycenou výjimku.