cache – co ukládat a kdy invavalidovat

Úplně jsem zapomněl na cache samotné databáze. Myslel jsem, že cache v Nette je nesrovnatelně rychlejší byť i jen jediný dotaz do DB. Pokud je s ní ale režie srovnatelná s jednoduchým SQL dotazem, nemá pro tyto dotazy velký smysl. Až budu mít chvíli, zkusím si to nějak změřit.

Určitě dodělám globální vypnutí cache – uvažoval jsem spíš o jednorázovém výmazu, ale pro potřeby ladění výkonu bude užitečnější to vypnutí (příp. oboje).

Co se invalidace týče, budu věřit že sestavená cache může být platná třeba i za rok a budu invalidovat pouze při změně objektu.

Díky.

Ono to, co je rychlejší – jestli vyhodnocení databázového dotazu, anebo parsování nějakého souboru na disku – se velmi těžko paušálně rozhoduje. Prví varianta obnáší provedení samotného dotazu a přenos výsledku, což vše stojí nějaký čas, druhá varianta obnáší diskové operace, parsování, hledání dat podle žurnálu, což pochopitelně také stojí nějaký čas. Nejlepší je to opravdu změřit.

V každém případě jednoduché dotazy, ve kterých se filtruje podle primárního klíče (či jiného indexu), databázové systémy vyhodnocují velmi rychle.

K tomu globálnímu vypnutí a řešení jednorázovým výmazem… Jakékoliv měření provedené jedním spuštěním je zavádějící. Chce to opravdu mít možnost spustit benchmark se třeba 1000 opakováními a výsledky zprůměrovat. Výborně se na to hodí třeba ab (Apache Benchmark).

Jinak co se globálního vypnutí týče, myslím, že udělat individuální aktivaci/deaktivaci není o tolik pracnější. K realizace cache se IMHO velmi hodí návrhový vzor dekorátor (není to můj objev, opravdu se pro cache často používá), kdy ve výsledku lze podle nějaké konfigurační direktivy rozhodovat, zda použít základní, anebo dekorovaný zdroj. Já to mám takhle udělané přímo na úrovni DI kontejneru – prostě když sestavuji službu, jejíž data je možné cachovat, zkontroluji nastavení v konfiguračním souboru, zda se skutečně cachovat mají, a podle toho službě předám standardní, anebo „odekorovaný“ zdroj. Funguje to výborně. Standardní a dekorovaný zdroj mají stejné API, takže služba samotná ve výsledku ani neví, jestli pracuje s cachovanými daty nebo normálními.

V konfiguračním souboru mám pak jednom jeden řádek s logickými hodnotami, zda danou část webu cachovat či nikoliv. Za sebe jsem zatím nenalezl hezčí řešení. :)

Editoval Tharos (19. 9. 2011 9:47)

@ Tharos:

Jestli tomu dobře rozumim (zjednodušeně) – při nahrávání modelu si zjistíš, zda má platnou cache a podle toho vrátíš model kde jsou některé funkce přepsané tak, že vrací hodnoty z cache.
Pokud nemá platnou cache, vracíš standardní model, který při volání těchto funkcí sahá do databáze??

Já to zatím řeším tak, že si přímo v modelu zjistím zda je platná cache – pokud ano, vrátím výsledek z ní, pokud ne spustím sql dotaz.

Uvedu příklad, jak by to mohlo fungovat u dibi.

Vytvoříš si interface

interface IUsersRepository
{
	/**
	 * @param integer $id
	 * @return User
	 */
	function find($id);
}

Interface implementuješ

class UsersRepository extends Nette\Object implements IUsersRepository
{
	/** @var DibiConnection */
	private $db;

	public function __construct(\DibiConnection $db)
	{
		$this->db = $db;
	}

	/**
	 * @param integer $id
	 * @return User
	 */
	public function find($id)
	{
		$user = $this->db->fetch('SELECT * FROM users WHERE id =%i', $id);
		return $this->load($user);
	}

	private function load($data)
	{
		$user = new User;
		$user->username = $data['username'];
		return $user;
	}

}

Nyní nad tím postavíš kešovací dekorátor

class CachedUsersRepository extends Nette\Object implements IUsersRepository
{
	/** @var UsersRepository */
	private $repository;

	/** @var Nette\Caching\Cache */
	private $cache;

	public function __construct(UsersRepository $repository, Nette\Caching\Cache $cache)
	{
		$this->repository = $repository;
		$this->cache = $cache;
	}

	/**
	 * @param integer $id
	 * @return User
	 */
	public function find($id)
	{
		return $this->cache->call(callback($this->repository, 'find'), $id);
	}
}

A pak se budeš rozhodovat, jestli vytvořit jenom repozitář

return new UsersRepository($container->db);

Nebo ho budeš kešovat

$repository = new UsersRepository($container->db);
$cache = new Nette\Caching\Cache($storage, 'UsersRepository');
return new CachedUsersRepository($repository, $cache)

Což jde rozložit na jednotlivé služby a všechny zapsat do DI Containeru.

Editoval HosipLan (19. 9. 2011 13:07)

Abys měl ještě více o čem přemýšlet :), doplním k HosipLanovo implementaci (učebnicově čisté) ještě ukázku celkového použití i včetně toho řízení individuálního zapnutí/vypnutí cache.

Tohle můžeš mít ve vlastním konfigurátoru (který bude dědit z Nette\Configurator a kterým nahradíš v bootstrap.php ten výchozí):

public function createServiceUsers(Nette\DI\Container $cont)
{
	$repository = new UsersRepository($cont->db);

	if ($this->shouldWeUseCache($cont, 'users')) {
		$cache = new Nette\Caching\Cache($cont->cacheStorage, 'UsersRepository');
		$repository = new CachedUsersRepository($cache, $repository);
	}
	return new Users($repository);
}

private function shouldWeUseCache(Nette\DI\Container $cont, $serviceName)
{
	return
		isset($cont->cacheStorage) and
		array_key_exists($serviceName, $cont->params['cacheControl']) and
		$cont->params['cacheControl'][$serviceName] === true;
}

A řídit se to poté dá z config.neon následovně:

common:
	cacheControl: [webUser: true, ..., ...]

K tomuhle bych navíc doporučil… Nemít tu továrnu na službu přímo ve vlastním konfigurátoru, ale mít ji někde jinde. Úplně ideální je mít ji ve své vlastní třídě.

Btw. tohle je úplně obecný princip, ta cachovaná záležitost nemusí být žádný repositář, může to být úplně stejně i výsledek nějakého složitého výpočtu nebo tak…