Mnoho souborů v cache database – jak pracuje?
- frosty22
- Člen | 373
Zdravím,
všiml jsem si nyní u jednoho projektu, že mi Nette/Database vytváří příliš mnoho souborů v cache. V podstatě během pár minut, kdy se provedlo několik requestů mám v cache již přes 1000 souborů a to se jedná o databázi o pár tabulkách. Kde by mohl být zakopaný pes? Co se vůbec cacheuje?
Doposud jsem předpokládal, že se cachují, jaké jsou cizí klíče u tabulek, které zjistí *Conventional, ale cachuje se asi více věcí?
Převážná část souborů je totožná, konkrétně se jedná o dvě verze:
První typ souborů:
<?php //netteCache[01]000048a:1:{s:4:"time";s:21:"0.62191000 1343896168";}?><?php //netteCache[01]000048a:1:{s:4:"time";s:21:"0.72302700 1343896027";}?>.. a takto dalších pár tisíc souborů, lišící se pouze v oné hodnotě „time“, kde je aktuálná čas
Druhý typ souborů:
<?php //netteCache[01]000070a:2:{s:4:"time";s:21:"0.67341200 1343896168";s:10:"serialized";b:1;}?>a:2:{s:33:"type_discount_category_synonym_id";b:1;s:25:"type_discount_category_id";b:1;}… u těchto souborů bych řekl, že je asi chyba – jelikož je tam v části ukočené PHP (viz ?>)?
Děkuji za navedení, kde bych mohl hledat zakopaného psa
Editoval frosty22 (2. 8. 2012 10:41)
- uestla
- Backer | 796
V komentáři v té části s PHP kódem (u první ukázky je to v podstatě celý obsah souboru) jsou serializované údaje o cache – kdy expiruje, na čem závisí, apod.
V té druhé ukázce jsou pak za tímhle PHP kódem už serializovaná samotná do cache ukládaná data. Tzn. že v první ukázce nejsou žádná data v podstatě cachována…
Ale jak se cachuje v NDB, na to si netroufám odpovědět, jen jsem chtěl osvětlit tohle…
- frosty22
- Člen | 373
Aha, děkuji za objasnění této části :) Ještě tedy zjistit, proč se cachují prázdné soubory, neboť ted jsem u jednoho staršího projektu si toto zkontroloval a již jich tam je několik desítek tisíc (ten již běží na ostrém několik týdnů), což bych řekl není úplně košér, leč tedy to asi nic nebrzdí, tak stejně by mě zajímalo proč.
Ještě pro informaci, testoval jsem na verzi 2.0.2 a nyní jsem nahrál verzi 2.0.4 stable, a zatím to vypadá, že asi je problém stejný, opět se začínají hromadit soubory pomalu.
- David Matějka
- Moderator | 6445
uz jsem to tu psal, https://forum.nette.org/…cuje-spravne
staci zapis a cteni z cache v Nette\Database\Selection (radky 116 a 417 dle aktualni verze) upravit tak, ze
<?php
$this->conditions;
?>nahradis za
<?php
array_values($this->conditions);
?>ono to jako klic u tech $this->conditions pouziva md5 z vstupnich argumentu fce where, takze i parametry dotazu.. nevim, jestli to nezpusobi problem nekde jinde pri slozitych dotazech, ale pouzivam tenhle fix u par projektu a vsechno funguje OK
a jeste k tomu, co se vlastne cachuje: pokud mas ten dotaz poprve pouzit, tak z databaze vytahne vsechny sloupecky.. a podle toho, ke kterym jsi pristoupil si to ulozi do cache a pak taha jen ty…
Editoval matej21 (2. 8. 2012 18:26)
- hrach
- Člen | 1834
Fixed tu: https://github.com/…77a631e81624
= https://github.com/…-refactoring
Editoval hrach (2. 8. 2012 22:28)
- frosty22
- Člen | 373
Super díky, nyní jsem aktualizoval v jednom projektu, co se týče cache tak uvidím zda-li se soubory nebudou množit, zatím to vypadá, že nikoliv. Pouze mi to začalo hlásit chybu při přístupu k jiné tabulce, jelikož si nevytáhl v SELECTu sloupec s cizím klíčem. Vyřešil jsem to explicitním napsáním sloupců do metody SELECT.
<?php
$items = $this->connection->table("item")
->where("item.state = ?", 1)
->where("web.removed = ?", 0)
->where("web.authorized = ?", 2)
->where("item.fixed_state", 1);
// Zde ještě získávám počet $item->count() pro paginator, a následně předávám $items do šablony
?>{foreach $items->select("item.*") as $item}
{var $additional = $item->ref("type_discount")}
... zde je $additional = false, pokud nezavolám select("item.*"), potom to vrací správně objekt
{/foreach}PS: Cache jsem samozřejmě vždy vymazal, čili zde problém není
Editoval frosty22 (7. 8. 2012 16:43)