Pokud se memcached spoji s nginx a vraci tedy stranky z cache, tak to je super, v podstate se nemusi dojit k tomu, ze dotaz probubla az napr. do PHP/db, ale mam dotaz jak tahle kombinace pozna (resp. nginx), ze uz data v memcached nejsou platna?
V pripade kdy memcached mam primo v aplikaci tak to chapu, ze pri zmene dat rovnou znevalidnim data v cache ale takto? Jak to vlastne obecne resi reverzni proxy, nejak pres http header?
Nginx to právě nijak nepozná a to je trochu na nic (maximálně pro hodně statické soubory, u kterých člověku nevadí, že musí ručně otočit nebo promazat memcache).
Bohužel tohle je obecný problém – často je totiž zjištění, zda se data změnila, stejně „drahé“ jako vytažení samotných dat.
Ano, v HTTP se to řeší přes hlavičky – buď zdrojový server předem deklaruje dobu trvanlivosti a pak ho proxy server už neotravuje, nebo ne (pro data, která se mohou kdykoli změnit) a pak se proxy server vždy ptá, zda je něco nového – do databáze nebo na disk u zdroje se tedy musí sáhnout, ale po síti se zbytečná data nepřenášejí.
Mezipaměť má tedy smysl ve chvíli, kdy potřebujeme šetřit síť, nebo když data procházejí nějakou složitější transformací – kterou můžeme ušetřit a pouze se podívat, zda se změnil soubor nebo záznamy v databázi (proti tomu zase jde fakt, že hodně obsahu je příliš komplexního a složeného z příliš mnoha různých částí a zdrojů, že všechny spolehlivě zkontrolovat vyjde stejně draho jako poskládat ten obsah kompletně).
znevalidnit lze i data v memcachi pro nginx. Ale implementace takoveho znevalidneni asi bude vyzadovat stejne (nebo vice) prace jako implementace cache primo do aplikace. Jedina vyhoda je, ze vlastni aplikace se nespusti dokud jsou data platna. Nginx + memcached by mohlo byt dobre reseni pro cachovani statickych souboru: pri vhodne zvolene velikosti memcache budou nejpouzivanejsi soubory stale v pameti a nedojde ani k osahani fs zda se nezmenily, to muze byt vykonostni vyhoda. Dynamicke stranky bych tim asi nechachoval.
ČLÁNKY DO MAILU