bobtajici cache 50k souboru +

qwerin

Ahoj, mam takovy problem v slozce temp/cache/_Nette.Database.XXXX se mi behem par dni nageneruje 50 000 souboru o velkosti 126 B a mam podezreni ze to pak brzdi cele nette.

PHP 5.4.13 |
Apache |
Nette Framework 2.1.0 ( on 2013–12–31)

Editoval qwerin (19. 3. 2014 13:57)

Filip Procházka

Podezření je oprávněné, souborové systémy nemívají rády když je v jedné složce moc souborů.

Řešení je prosté: použít memcache nebo redis – těm je jedno kolik tam uložíš klíčů, zajímá je jenom velikost RAM :)

hrach

Idealni by bylo zjistit, co kdo kde a proc vytvari, da se to odvodit asi od toho obsahu.

qwerin

na wedosu toho s memcache asi neudelam moc :-(

Nahodny vyber z obsahu:

<?php //netteCache[01]000070a:2:{s:4:"time";s:21:"0.39140000 1395261075";s:10:"serialized";b:1;}?>a:1:{s:10:"id_produkt";b:1;}

<?php //netteCache[01]000070a:2:{s:4:"time";s:21:"0.57018400 1395284403";s:10:"serialized";b:1;}?>a:1:{s:10:"id_produkt";b:1;}

<?php //netteCache[01]000070a:2:{s:4:"time";s:21:"0.61578600 1395287011";s:10:"serialized";b:1;}?>a:1:{s:10:"id_produkt";b:1;}

Komplet za 18h (14 000 souboru)

http://weltservis.cz/_Nette.Database.e60c4aa63c3692c3ee046e4f47399944.zip

David Matějka

Nepodarilo by se ti nejak odhalit, ktery dotaz to generuje? Pouzivas doufam vsude parametry a ne konstrukce jako

$selection->where('id = ' . $id)
//spravne je:
$selection->where('id', $id)

qwerin

matej21 napsal(a):

Nepodarilo by se ti nejak odhalit, ktery dotaz to generuje? Pouzivas doufam vsude parametry a ne konstrukce jako
$selection->where('id = ' . $id)
//spravne je:
$selection->where('id', $id)

spise pouzivam vsude

$connection->table("dr_produkt")->get($id);

David Matějka

Jo, to je taky OK.. koukni, jestli tam nenajdes nejaky podezrele vypadajici nebo slozity dotaz :)

pamatuju si, ze nette\database melo podobny problem s cache asi rok zpatky, ale to bylo nekde na 2.0.x a uz je to davno opraveny..

Editoval matej21 (20. 3. 2014 13:48)

qwerin

par jich je:

http://www.weltservis.cz/test.html

qwerin

po delsi dobe jsem na to kouknul a rozklicoval jsem si co a jak se kešuje. A jesti jsem to pochopil zpravne tak na kazdy slozitejsi join dotaz se uklada „using“ key (accessColumn) do kese ktera je nazvana podle vysletku funkce getGeneralCacheKey. A v te je problem ve chvili kde kazdy dotaz je trochu jiny a kombinuje jine tabulky a sloubce (napr. fitrovani). Tak to generuje 1000-ce keš souboru.

Prosim tedy o napady jak tomu predejit. Popř. nejaky navrh upravy logiky.

Mam dva napady:
1. ve funkci getGeneralCacheKey nebrat v poraz sloubce ale jen zasazene tabulky.
2. accessColumn ukladat do pole a to ukladat do kase.

David Matějka

@hrach: co takhle dat moznost nastavit ten generalCacheKey – proste identifikator toho query?

@qwerin: pokud na selection specifikujes ->select(...), accessColumn cache by se nemela pouzit. Jinak muzes zkusit tenhle hnusny workaround :)

$selection = $context->table('foo')->where(...)...;
$setCacheKey = function() {
	$this->generalCacheKey = 'someQueryIdentifier';
}
$setCacheKey = $setCacheKey->bindTo($selection, $selection);
$setCacheKey();

( >= 5.4, pro nizsi by sel pouzit nejaky reflection hack)