Cache výstupu komponenty BEZ opakovaného volání render() když se čte z cache

1. Chci, aby se to nezdrzovalo renderovanim.
2. Chtel bych, aby to fungovalo jak ma. Chci to pouzit na vice mistech a prakticky lze cachovat pouze staticky obsah :D
3. To co vraci Table (Selection?) cachovat pokud se neco nezmenilo primo nelze bohuzel.

To cachovani primo v sablonach by bylo krasne, super, excelentne genialni, ucinne a jednoduche… kdyby fungovalo..

Tohle vyzkouším, dík :) Pomůže mi to na jiných místech, kde mám šílené cykly, abych to celé přetáhl do pole a zacachoval :)

Jinak tenhle konkrétní případ je opravdu hodně pomalý, proto řeším, aby byl v cache celý ten html výstup. Jsou tam tisíce položek (desetitisíce dotazů napříč desítkami tabulek), php na tom stráví přes 2.5 sec.. (z toho mysql asi 250ms)

A mimo to… proste pocit, ze se neco natahlo z cache a presto se se zobrazenim ceka na funkci, ktera ty data znou nacte a zpracuje aniz by se ty nove data nekde projevily je… :D lehce neprijemny, kdyz se generovani stranky priblizuje bez cache ke trem vterinam a s cache v sablone asi na 2.95 :(

Editoval neznamy_uzivatel (13. 8. 2016 17:00)

neznamy_uzivatel napsal(a):

Tohle vyzkouším, dík :) Pomůže mi to na jiných místech, kde mám šílené cykly, abych to celé přetáhl do pole a zacachoval :)

Jinak tenhle konkrétní případ je opravdu hodně pomalý, proto řeším, aby byl v cache celý ten html výstup. Jsou tam tisíce položek (desetitisíce dotazů napříč desítkami tabulek), php na tom stráví přes 2.5 sec.. (z toho mysql asi 250ms)

A mimo to… proste pocit, ze se neco natahlo z cache a presto se se zobrazenim ceka na funkci, ktera ty data znou nacte a zpracuje aniz by se ty nove data nekde projevily je… :D lehce neprijemny, kdyz se generovani stranky priblizuje bez cache ke trem vterinam a s cache v sablone asi na 2.95 :(

V tom případě je problém asi jinde :-) 3s je dost … MOC

Ty vypisujes celou databazi? Vsech 20M radku?
Deset tisic dotazu pri nacteni jedny stranky?
Specifikuj spis kde mas bottleneck :-) zkus nejakej profiler, treba blackfire.

Data se ti načítají i po keši, protože fetchAll pošle dotaz do mysql a nette/database to zpracuje, bez ohledu na to, zda-li to použiješ.

Můžeš udělat tohle:

class Lazy implements IteratorAggregate {

	private $callback;

	public function __construct(callable $callback) {
		$this->callback;
	}

	public function getIterator() {
		$callback = $this->callback;

		return new ArrayIterator($callback());
	}

}

Rozdíl už je potom jen v presenteru:

$template = $this->template;
$template->setFile(__DIR__ . 'sablona.latte');
$template->tralala = new Lazy(function () {
	$this->database->table('egkategorie')->where('active = 1')->fetchAll();
});

Klidně můžeš vynechat i tu anonymní funkci a předávat Selection a v Lazy volat fetchAll.

Editoval Antik (13. 8. 2016 18:08)

CZechBoY: Nevypisuju celou db, ta komponenta je něco jako menu s kategoriema. Vypisuje se jen část dat v závislosti na dalších tabulkách. Kód uvádělý na začátku je jen ukázka, kterou jsem zkoušel mimo ten projekt, abych si byl jistý, že se to takhle chová i jinde. Jinak používám xdebug, blackfire neznám..

Spectator: 100 mil. záznamu v jedné tabulce v MySQL je už opravdu velice nepříjemná práce. V reálu na frontendu používám sphinx – v tak velké tabulce je naprosto nemyslitelné rozumě filtrovat/vyhledávat, hlavně když tam mám desítky možných filtrů a potřebuju facety.

Antik: Tak tomu vůbec nerozumím :)

Pokud správně chápu, má to fungovat tak jak jsem očekával – pokud tu komponentu hodím v šabloně do {cache}, tak by se dotaz v render té komponenty neměl provést. V tom případě je buď bug v nette, nebo ve mě. Takže jdu hledat co jsem pokazil :)
Nejhorší je, že to neudělá pokaždé. Dal jsem si logovat každé spuštění toho renderu a je to opravdu náhodné. z 10ti refreshů se někdy spustí jednou, někdy 3×, někdy 10x…

Editoval neznamy_uzivatel (13. 8. 2016 18:45)