Cachování – mnoho souborů?
- kejlicz
- Člen | 201
Ahoj všichni.
Zkouším u jednoho většího projektu poprvé nasadit cache. Chtěl bych se
předem zeptat, když budu cachovat např. 10 000 „záznamů“, vytvoří se
mi 10 000 souborů nebo to nějak spojuje. Jde mi o to, že bude potřeba
cachovat hodně věcí a abych to případně rozdělil a nevznikalo mi
v jednom adresáři příliš mnoho souborů (desítky tisíc).
Díky za odpověď
- Jiří Nápravník
- Člen | 710
Pokud chceš hodně kešovat, tak bych nevolil kešování do souboru, ale do nějaké jiné alternativy. Třeba memcache apod.
- GEpic
- Člen | 566
Já bych nejprve projekt otestoval. Až poté řešil cache, většinou je to totiž cesta do pekel. Databáze je lépe optimalizována pro vyhledávání. Pokud uložíš všechny záznamy do jednoho souboru, bude se muset celý načíst a poté v něm budeš muset hledat. Pokud vytvoříš 10 tisíc souborů pro každý záznam, opět to bude vyžadovat jistý čas.
Každopádně pokud chceš nasadit cache z důvodu velkého množství záznamů, tak se jí radši vyhni. :)
- kejlicz
- Člen | 201
Já už jsem to pracovně testoval a při použití cache se to zrychlí dost. Ale nejsou to výsledky z reálného provozu při velké návštěvnosti.
Jedná se o pracovní portál s cca 50 000 pracovními nabídkami, kde by se cachoval hlavně výpis nabídek v jednotlivých okresech. Těch je tuším 74 a tvořilo by to 80% provozu. Zbytek by byly výpisy nabídek pro jednotlivé firmy, jednotlivé obce a nejčastěji hledané výrazy.
- Martk
- Člen | 661
Když potřebuješ filtrovat mezi výsledky, tak to nech v databázi na to je toto vytvořeno a optimalizováno. Jestli to je i přesto pomalé, tak se podívej na návrh databáze a vhodně zvol klíče.
Jediné co bych cachoval, tak celou šablonu, tzn. pro jeden okres např. první 2–3 stránky (bez filtrů).
- kejlicz
- Člen | 201
Neříkám že je to pomalý. Jen říkámm že je to s cachí o dost rychlejší.
Původně jsem to plánoval, jak píše Antik, že bych cachoval třeba jen
3–5 stránek z každého okresu. Ale jak jsem si s tou cachí hrál a
zkoušel, výsledky mě docela potěšily.
Pro CZecBoY : Nevím jestli je 50 000 záznamů málo. Já to mám na Doctrine
a když tam máš vazby jednotlivých pracovním míst na úřady práce,
zaměstnavatele, okresy a podobně, databáze se myslím nefláká. Takový
dotaz, který mi vytáhne např. do sidebaru seznam obcí z regionu a ten je
seřazený podle počtu nabídek v dané obci mi trvá na localu 60 ms.
Z cache to tahá 5 ms. Dále tam tahám např. seznam největších
zaměstnavatelů v regionu a podobně. Ve finale se cachováním ušetří dost
času.
Je to docela navštěvovaný web a každé zrychlení se hodí.
Zatím to píšu tak, že to bude cachovat do souborů. Určitě se kouknu jak radí Jiří Nápravník na cachování do paměti. Stejně asi reálnou použitelnost zjistím až v reálném provozu a pak se uvidí.
Editoval kejlicz (27. 6. 2016 11:39)
- newPOPE
- Člen | 648
@kejlicz skus sa na to co volas cache pozerat inak. Je to v podstate context toho ako chces pracovat s udajmi ktore mas momentalne v SQL.
Moznosti mas viac:
- kedze tam mas Doctrine tak ti verim, ze to nie je uplne tak ako by si chcel. Skus si to vyhladavanie napisat tak aby Ti doctrine rovno vratila vysledky ktore mozes zobrazovat. Cize nejake agregovane entity (mozno si pytaj len array nakolko aj hydracia je dost draha) ktore nemaju tabulky a sluzia len pre vyhladavanie.
- ist cestou ElasticSearch-u kde si tie data nalejes a budes vyhladavat a zobrazovat priamo odtial.
Editoval newPOPE (27. 6. 2016 11:39)
- kejlicz
- Člen | 201
CZechBoY napsal(a):
@kejlicz 60ms je pohoda (ještě k tomu na localhostu…)
Myslel jsem jen dotaz do DB. To sice je pohoda při malé návštevnosti, ale při 20 000 za den, kdy ve špičce není neobvyklých 10 requestů na stránku za sekundu je to podle mně dost vysoké číslo.
Editoval kejlicz (27. 6. 2016 11:52)
- kejlicz
- Člen | 201
newPOPE napsal(a):
@kejlicz skus sa na to co volas cache pozerat inak. Je to v podstate context toho ako chces pracovat s udajmi ktore mas momentalne v SQL.
Moznosti mas viac:
- kedze tam mas Doctrine tak ti verim, ze to nie je uplne tak ako by si chcel. Skus si to vyhladavanie napisat tak aby Ti doctrine rovno vratila vysledky ktore mozes zobrazovat. Cize nejake agregovane entity (mozno si pytaj len array nakolko aj hydracia je dost draha) ktore nemaju tabulky a sluzia len pre vyhladavanie.
- ist cestou ElasticSearch-u kde si tie data nalejes a budes vyhladavat a zobrazovat priamo odtial.
1 ) vyzkouším. Díky.
2 ) Na Elastic Search jsem koukal, ale s tím zatím neumím. Určitě si s tím pohraju.
- Jiří Nápravník
- Člen | 710
Používáš na tu Doctrinu taky filecache? Pokud jo, tak tam dej taky nějakou tu memcache nebo tak, u mě to bylo dost poznat, protože pokud tam máš dost entit, tak Doctrina celkem dost věcí cachuje a RAM a disk je rozdíl často znatelný…
A jak píše @newPOPE tak nějaká ty agregovaná data. Není to úplně správně a někteří databázisti by jistě nadávali, ale v doctrine přes EntityListenery či i přímo v entitě, pokud máš vazby, celkem bez problémů můžeš při každé nové nabídce zvýšit počet nabídek v okresu. A pak budeš mít velmi jendoduchy select, tkerý budeš řadit podlě jednoho sloupce, atd. Zase chce to používat samozřejmě s rozumem, ne vždy je tohle ideální.
Taky předpokládám, že tam nemáš plno OneToMany vazeb a obecně bidirectional, které stahuješ vždy celé, to taky dost často hodně času zabere.
Taky není špatné využít partial objekty, kdy nevybíráš celou entitu, ale jen to co zobrazuješ na té dané stránce. Ale POZORNĚ si počti, co to může taky způsobit, ten partial objekt je pak v daném request pořád partial…
A pokud ani jedno nepomohlo, tak bych pak sáhl asi po té cachi. Já osobně cachuji data, co se moc často nemění, případně to je více dotazů na databázi v daném úseku anebo tam jsou nějaké větší divočiny s tím.