Autor Zpráva
Tom2234
Profil *
Zdravim,

mam takovy dotaz ohledne cachovani... pomoci skriptu si cachuju obsah stranky a ukladam jej do souboru nazev-stranky.txt ve slozce cache. Pomoci CRONu budu volat skript, ktery kazdou hodinu vytvori novy cache stranky... ovsem toto je nedotacujici, v pripade, ze v teto hodine provedu update db a data budou zmenena (tato zmena by se projevila az kazdou hodinu)... Chtel jsem se tedy zeptat, jak osetrit pripad, aby se novy cache vytvoril v pripade, ze se vlozi do db nove data nebo se data vymazou a nebo se data updatuji?

napadlo mne reseni vytvorit si v dane tabulce slopec update_time, kde by se ukladal cas kdy bylo s tim a tim radkem naposledy manipulovano... pote bych vytvoril novou tabulku s nazevm auktualni_casy_tabulek, ve ktere by byly sloupce s nazvy vsech tabulek v DB.. v kazdem sloupci by byl ulozen posledni cas manipulace s danou tabulkou... ve skriptu bych pote porovnaval prave sloupec "update_time" a dany sloupec v tabulce "auktualni_casy_tabulek" a kdyby se odlisovaly, tak bych provedl novy cache. Ovsem mi to prijde celkem neprakticke, neexistuje nejake jine, lepsi reseni??

(snad to je aspon trochu srozumitelne, v pripade ze by nebylo tak vytvorim priklad na kterem by to bylo hezky videt) :)

dekuji za odpovedi Tom
Joker
Profil
Tom2234:
Podle mě je zbytečné vytvářet cache přes CRON v nějakých pravidelných intervalech.
1. Cache dává užitek jen ve chvíli, kdy nějaký návštěvník zrovna chce stránku. Je zbytečné udržovat cache i v období, kdy danou stránku třeba nikdo nezobrazil.
2. Aktualizovat cache má smysl až ve chvíli, kdy se změní obsah stránky. Pokud je obsah stále stejný, je zbytečné aktualizovat cache.

Možné řešení:
- Při zobrazení stránky se skript pokusí ji přečíst z cache. Pokud v cache není platná kopie dané stránky, nechá stránku sestavit znovu, uloží do cache a pošle návštěvníkovi.
- Jakákoliv operace vedoucí ke změně dat zároveň zneplatní cache příslušné stránky nebo stránek.

Potenciální problém: Neřeší to situaci, kdy někdo obejde redakční systém a změní data nějak ručně, třeba přímo v databázi. Pak by asi musela být nějaká cesta, jak ručně zneplatnit cache příslušné stránky.
Tom2234
Profil *
1. ano, s tim souhlasim, ale pres cron se stale udrzuje aktualni cache a nacitani je rychle.. v pripade, ze navstevnik prijde na stranku a ta teprve musi vyhodnotit zda je cache aktualni, kdyz ne, tak nacist aktualni data z db a pote je do cache ulozit, tak to bude trvat casove dele, nez kdyz se jen nacte stranka z cache. Tuto praci vyhodnocovani provadi skript pres CRON a tudiz navstevnikovi se stale zobrazuje aktualni stranka z cache a uz neni potreba provadet zadne skripty, ktere by navstevnikovi zdelsily nacitani stranky.

2. aktualizovat cache ve chvili zmeny dat jsem prave chtel poresit tim porovnanim castu v db.. zda jsou v db udaje nove provede aktualizaci skript kdyz uzivatel stranku navstivi.. jinak to provadi skript pres cron.. sice se vetsinou asi stane, ze cache je aktuali a cron skript ji i tak vytvori, ale stale to bude pro navstevnika "casove" vyhodnejsi (dle meho nazoru).

- jj to je i ma idea..
- aha.. takze v pripade ze do DB ulozim nova data, nebo data upravim a nebo data smazu tak zaroven mam znehodnotit cache? teoreticky to je logicke :) a velmi jednoduche, ne jak jsem popisoval to me slozite reseni s porovnavanim casu...

potencionalni problem: tento roblem nehrozi, uzivatel (konkretne administrator) ktery RS bude vyuzivat nebude rucne do db zasahovat, zaprve to neumi a zadruhe nebude mit ani pristup k db. takze az na tek velke urovni to resit nemusim...

dekuju moc za radu, jak jednoduche :) snad jsem to tedy pochopil spravne... v pripade jakekoliv prace s db mam znehodnotit cache.. a to je vpodstate vse :) tim vlastne pada i prvni problem, neni potreba resit skript ktery bude provaden pres CRON.. :o) (kdybych nejdrive reakci precetl a az pote odpovedel tak bych si to vyvodil, jenze mam ve zvyku odpovidat uz pri cteni prispevku.. tak uz to nebudu mazat kdyz sjem se s tim psal)...
Joker
Profil
Tom2234:
v pripade, ze navstevnik prijde na stranku a ta teprve musi vyhodnotit zda je cache aktualni
Tak pokud by tohle byl problém, může operace "zneplatnění" spočívat ve fyzickém vymazání dané stránky z cache.
Pak zobrazovací skript musí jen ověřit, jestli stránka v cache existuje- a v případě neexistence ji nechat znovu sestavit (a pokud nejde ani sestavit přejít na chybovou stránku).
Což je stejný mechanismus, který musí používat i ten skript s CRONem, protože jinak by na neexistujících nebo nově přidaných stránkách havaroval.

Takže jediné zpoždění bude při první návštěvě po změně stránky (kdy se stránka bude muset znovu sestavit).
Pokud by tohle byl problém, je možné novou stránku do cache sestavit už při změně obsahu- tj. místo zneplatnění cache prostě aktualizovat data v cache.
Zátěž by se tím přenesla na místo, kde se obsah mění. Nazval bych to "write-thru" strategií, zatímco zneplatnění cache a aktualizace dat při příštím zobrazení by byla "write-back".

Záleží, jestli jde hlavně o snížení zátěže serveru, nebo trvá dlouho stránky sestavit a cílem je zkrátit čekání na stránku.
Ta "write-thru" by mohla přinést velké zatížení v místech, kde se mění hodně stránek najednou. Naopak ta "write-back" by rozhodila zátěž do delšího času (jak by návštěvníci postupně prohlíželi aktualizované stránky), ale zas někteří návštěvníci (první po změně obsahu) by čekali na stránku déle.
Tom2234
Profil *
dekuji za vycerpavajici komentar :) v prvni rade mi slo predevsim o to, aby navstevnik na stranku cekal co nejkratsi cas... zkusim si z toho neco vzit a cachovani prizpusobit radam :) kazdopadne dekuji za teorii a ted si jdu otevrit editor a zkusit si to vse v praxi :) uvidim jaky bude vysledek ;o)
Mastodont
Profil
je možné novou stránku do cache sestavit už při změně obsahu- tj. místo zneplatnění cache prostě aktualizovat data v cache
To mi připadá dost složité, protože změněný údaj se může vyskytovat ve více dotazech a musel bys je nějak vyhledat ...
Návrh - buď při změně smazat všechny položky v keši nebo je doplnit o nějaké tagy a promazávat podle tagů.
Lamicz
Profil
Jenom poznamecka: Az ta cache bude nejak realizovana tak bych se ujistil, zda cachovaci system je vykonnejsi nez ten SELECT, neni to tak trivialni to udelat univerzalni a pritom rychle :)
Perry
Profil
Lamicz
I kdyby byla pomalejší, tak ulehčíš DB serveru, který bývá vytížený daleko více než PHP server (hlavně na hostingu), takže se to vyplatí (pokud teda máš PHP a MySQL na oddělených serverech). A pak když spadne DB, tak ti stránky pořád fungují :)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: