Kešování celé aplikace – case study
- maarlin
- Člen | 207
Ahoj,
existuje nějaká „case study“ pro HTML kešování?
Myslím něco podrobnějšího a obsáhlejšího, než je nyní v dokumentaci, třeba tam
není vůbec zmíněno kešování v šablonách via
{cache}{/cache}
, což by mě dost zajímalo…
Zároveň by mě zajímalo, jak je ten kešovací mechanismus připravený na kešování webů, kde existují private/public pohledy, tedy user se může přihlásit a pak se musí některé vnitřní části vůbec nekešovat (nebo kešovat pro každého uživatele??? imho nereálné) – např. nějaké divy se jménem uživatele, settings page…
Tedy má otázka zní – dokáže Nette kešovat zvlášť nějaké části (rozdělené na často aktualizované /z pohledu dat/ a téměř vůbec neaktualizované /jen při změně šablon/) a umí tam mít uvnitř mezi těmi všemi nakešovanými bloky nějaký jeden, který se vždy bude načítat aktuální (přihlašovací okno/přihlášený user)?
- maarlin
- Člen | 207
Díky.
Podle toho jdou kešovat sice jednotlivé části, jak jsem si myslel, ovšem „stromovým“ způsobem, tedy v okamžiku, kdy budu mít na stránce jeden malý div, který bude chtít mít hodně aktuální data (aktualizovaná třeba 1× denně), tak se bude muset přegenerovávat celá strana, protože se invaliduje, jakožto nadřazená.
S předchozím tedy asi i souvisí můj druhý problém – přihlašování – je to v přihlášeném režimu nepoužitelné? Protože podle toho co mám nyní k dispozici mě přijde že bych musel při každém přihlášení invalidovat znova celou stranu pro každého uživatele zvlášť, což fakt není realistická představa…
Editoval maarlin (1. 10. 2010 20:38)
- maarlin
- Člen | 207
jtousek napsal(a):
Nikdy jsem
{cache}
nepoužíval, ale lajcky bych řekl, že když použiješ ID uživatele jako$id
, v Davidově examplu tak by to mohlo být ono.
No, to mě nenapadlo :-)
Ovšem přijde mi to tak trochu jako na komára s brokovnicí… aneb proč musím mít mraky nakešovaných !celých! stránek pro !každého! uživatele zvlášť, když se tam třeba jen změní dvě slova? To fakt nejde udělat lépe (šetrněji)?
Editoval maarlin (1. 10. 2010 22:27)
- jtousek
- Člen | 951
A jak lépe bys to chtěl? Stejně si myslím, že něco co je pro uživatele nemá smysl kešovat.
IMHO kešování má smysl pouze tehdy když se nějaká data načítají stále a stále znovu a nemění se. Pokud uživatel u tebe navštíví 5 stránek je kešování kontraproduktivní neboť zbytečně zabírá místo. Má to smysl pouze pro nepřihlášené uživatele.
- Michalek
- Člen | 210
Používej cache pro logické části. Cachuj zvlášť „menu“, „poslední komentáře“, zvlášť „aktuality“ zvlášť „stalo se ve světě“ (příklady). Záleží web od webu, ale logické části snad vždycky najdeš. Samotné sestavení stránky z cache se i v případě hodně maker cache zvládne velmi rychle.
Používám {cache} v šablonách hodně, na opravdu velkém webu to šetří tisíce sql dotazů. Problém je jen jeden – jak modelu říct, že nemá nic načítat a zároveň nemít volání modelu v šabloně :(
Editoval Michalek (1. 10. 2010 23:35)
- maarlin
- Člen | 207
jtousek napsal(a):
A jak lépe bys to chtěl?
Představ si, že na té stránce jsou nějaké datové tabulky, grafy etc. a výpočty těch dat stojí docela nezanedbatelný čas a výkon a jestliže existuje několik tisíc přihlášených uživatelů v jeden okamžik (cca), tak se to musí spočítat z databáze pro každého (pro každého se musí získat ta samá informace a při každém požadavku se musí databázový server docela zapotit), což je právě to, čemu se snažím vyhnout použitím kešování – tzn. spočte se to třeba jen jednou denně a pro ostatní by se to tahalo už jen jako HTML.
Moje představa byla taková, že by bylo hotové vygenerované HTML a vevnitř include toho jednoho dynamického bloku (přihlašovací okno), u něhož nevadí, že se kešovat nebude.
Editoval maarlin (2. 10. 2010 0:19)
- redhead
- Člen | 1313
A co kešovat pouze ty informace a v šabloně je jen vykreslit?
Podle mě kešování šablon má opravdu smysl, pokud se ta jedna stejná stránka zobrazuje hodně často a v nezměněné podobě. Pokud potřebuješ kešovat dlouho tvrvající nebo náročné operace využil bych normální kešování přes Nette Cache.
- Michalek
- Člen | 210
Kdyby to byl nesmysl, asi by se {cache} nepoužívalo :-) Takové generování hodně strukturovaných komentářů pod článkem v šabloně taky něco času zabere a tam se cache html hodí. Případně uložení celé nacachované hlavní stránky obrovského zpravodajského portálu…
Taky by se mi občas hodilo mít uvnitř tagu {cache} místo označené {nocache}html{/nocache} které by se volalo vždy znovu. Návrh padl už v roce 2008. https://forum.nette.org/…-cache-cache?…
Editoval Michalek (2. 10. 2010 14:20)
- redhead
- Člen | 1313
Zrovna u těch kometářů se nebude nic měnit do doby, než někdo přidá něco nového, čili dlouhodobě neměnná část stránky. Stejné u toho zpravodajského portálu.
Na druhou stranu neumím si představit, že by se třeba cachovali všechny témata (a stránky ve stránkování!) tohoto fóra.
Prostě jsou případy, kdy se to hodí, ale někde je to zbytečné (nebo náročné na místo atd.).
- maarlin
- Člen | 207
Michalek napsal(a):
Taky by se mi občas hodilo mít uvnitř tagu {cache} místo označené {nocache}html{/nocache} které by se volalo vždy znovu. Návrh padl už v roce 2008. https://forum.nette.org/…-cache-cache?…
To je přesně to co potřebuji… :-) Jen škoda že to prostě nyní není implementováno… :( Jsou nějaké důvody proč to tam neimplementovat?
Editoval maarlin (2. 10. 2010 14:45)
- Patrik Votoček
- Člen | 2221
Jak to tady tak čtu tak si říkám proč tu ještě nikdo nevytáhnul výceůrovňovou cache? Vždyť je to ukázkový příklad. Za různých podmínek jsou různé úrovně cache různě vhodné. (myslím si že není potřeba toho psát víc)
- maarlin
- Člen | 207
vrtak-cz napsal(a):
Jak to tady tak čtu tak si říkám proč tu ještě nikdo nevytáhnul výceůrovňovou cache? Vždyť je to ukázkový příklad. Za různých podmínek jsou různé úrovně cache různě vhodné. (myslím si že není potřeba toho psát víc)
Edit jen pro ostatní, co to nepochopili, tak jako já :-)
Myšleno kešování na 3 úrovních – M – V – C. Tzn. v případě že upravím šablonu a nahraju novou verzi, invaliduje se jen ta keš na nejvyšší úrovni – HTML a nemusí se kvůli této změně invalidovat modelová keš (tzn. neposílají se zbytečné dotazy na databázi)
Editoval maarlin (7. 10. 2010 22:10)