Cached Configurator

DocX

Zkoumal jsem jaké části kódu mojí aplikace spotřebovávají kolik milisekund. Zjistil jsem, že cca 35ms z cca 200ms celkového času běhu (na mém ntb) mi sebere bootstrap.php.

Z většiny je to daň za RobotLoader a nutnou režii při vytváření Application. Ale hodně, cca 10 ms, si veme také řádek s Environment::loadConfig()

Zkusil jsem vyrobit Configurator, který nastavení ještě cachuje:

<?php
class CachedConfigurator extends Nette\Configurator {

	public function loadConfig($name)
	{
		$cache = Nette\Environment::getCache('Config');
		if (!isset($cache['config']))
			$cache['config'] = parent::loadConfig($name);
		return $cache['config'];
	}

}
?>

Výsledek byl pro mě docela překvapiví: téměř o 50% menší čas – 4–5 ms.

Jde o pár milisekund, ale myslím, že pokud to jde, tak je každá ms k dobru dobrá :)

Jediná nevýhoda je, že při změně configu se musí smazat keš. Config se ale zas tak často na produkčním serveru nemění.

Co si myslíte o tom, zařadit toto do Nette?

Editoval DocX (27. 8. 2009 11:22)

Blizzy

Imho výhody nekompenzují nevýhody. Než abych musel při každé změně configu mazat cache (a co teprve ty problémy, když na to zapomenu), to si radši těch 5 ms počkám.

Kdyby byl ale rychlý způsob, jak tu cache invalidovat (např. nastavit nějakou expiraci, invalidovat podle hashe nebo data poslední změny, nebo tak něco) a stále zůstat na tak nízkém čase, myslím, že by stálo za to to zařadit do distribuce.

DocX

Blizzy napsal(a):

Imho výhody nekompenzují nevýhody. Než abych musel při každé změně configu mazat cache (a co teprve ty problémy, když na to zapomenu), to si radši těch 5 ms počkám.

Souhlasím, že ta nevýhoda je celkem silná :) Asi to opravdu nemá na distribuci v Nette, tak to tu nechám alespoň pro ostatní, kterým by se to třeba hodilo.

IMHO: Když zapomenu smazat cache, tak si snad vzpomenu, když uvidím, že se nic nezměnilo :)

Jan Tvrdík

Co něco takového?

<?php
class CachedConfigurator extends Nette\Configurator {

        public function loadConfig($name)
        {
                $cache = Nette\Environment::getCache('Config');
                if (!isset($cache['config']))
                        $cache->save('config', parent::loadConfig($name), array(
                            'files' => array('config.ini'),
                        ));
                return $cache['config'];
        }

}
?>

Nevím ale, jak to bude rychlé.

Editoval Jan Tvrdík (27. 8. 2009 12:09)

jasir

Zrovna jsem to chtěl napsat… Můžeš to změřit na jakém jsme čase?

redhead

Pánové, čtěte tu dokumentaci!

Cache se dá přece snadno invalidovat dokonce automaticky, když se změní soubor (viz Nette\Caching

$cache->save('config', parent::loadConfig($name), array(
    'files' => array($name),
));

(sakra, pozdě :) )

Editoval redhead (27. 8. 2009 12:11)

Jan Tvrdík

Vzpomněl jsem si, že v dobách dávno minulých se Configurator cachoval, ale od revize 162 se cachování zrušilo „due strange bug“.

DocX

Teď jsem zjistil, že to dělá docela velký problém: neprovádí se set! nastavení

Takže možná proto se od toho opustilo…

Editoval DocX (27. 8. 2009 13:44)

PaBi3

Ja len tak pomimo, že set! už nie je preferovaný.

Jan Tvrdík

DocX napsal(a):

Teď jsem zjistil, že to dělá docela velký problém: neprovádí se set! nastavení

Takže možná proto se od toho opustilo…

Ne, to není ten důvod. Dříve se totiž necachovalo celé volání loadConfig, ale pouze načtení a parsace.

DocX

Ok, tak zas tolik mě těch pár ms netankuje :)

Mimochodem, teď jsem na našem serveru (testovacím, jinak je to stará šunka) rozchodil XCache a celá Nette aplikace prolítne za 35ms, teda za tak dlouho co u mě na lokálu jen bootstrap :)

David Grudl

DocX napsal(a):

Takže možná proto se od toho opustilo…

Problém byl v tom, že se mohly změnit hodnoty nějakých uživatelských konstant, které se expandovaly v config.ini, a těžko se tyhle závislosti dohledávaly.