Jak měřit čas metod?

Laethnes

Nějakou dobu dělám na webu a poslední dobou se mi zdá, že je značně pomalý. Tak jsem si aktivoval Nette Profiler a pak rovnou i FirePHP a FireBug. A skutečně – u mě na PC (1,6 GHz Intel dual-core) vykreslování stránky trvá okolo 500–1000ms. Stránky mám na www.ic.cz, kde rendering trvá 1–10 s (pomocí Debug::timer()). Dříve mě napadlo, že je to databází, protože jednak používám sqlite a jednak mi tam časem vzniklo hodně dotazů na stránku (takže jsem začal uvažovat nad používáním Nette cache), ale díky FirePHP/FireBug jsem zjistil, že to tím není. Když jen čtu, je to cca 5ms čtení z sqlite (ale 10–15 dotazů na stránku je asi moc, co?), problém nastává když zapisuji – přesto se jedná jen o cca 5–10% veškerého času (až 20% na ic.cz).
Takže jsem asi blbě napsal některé procedury a metody. Zjišťuji, že by se mě hodil profiler, jak to funguje v C/C++ – vypíše se, kolik času strávila aplikace v jaké metodě. Na netu jsem vyhrabal, že to nejspíš půjde (hlavně díky tomu, že třídy dědí od Nette/Object, čehož se striktně držím), ale nikde jsem nezjistil jak. Neví někdo, prosím, zda a jak to jde?

Panda

Profilovat umí Xdebug: http://xdebug.org/docs/profiler.

Ondřej Mirtes

Laethnes napsal(a):

Nějakou dobu dělám na webu a poslední dobou se mi zdá, že je značně pomalý. Tak jsem si aktivoval Nette Profiler a pak rovnou i FirePHP a FireBug. A skutečně – u mě na PC (1,6 GHz Intel dual-core) vykreslování stránky trvá okolo 500–1000ms. Stránky mám na www.ic.cz, kde rendering trvá 1–10 s (pomocí Debug::timer()). Dříve mě napadlo, že je to databází, protože jednak používám sqlite a jednak mi tam časem vzniklo hodně dotazů na stránku (takže jsem začal uvažovat nad používáním Nette cache), ale díky FirePHP/FireBug jsem zjistil, že to tím není. Když jen čtu, je to cca 5ms čtení z sqlite (ale 10–15 dotazů na stránku je asi moc, co?), problém nastává když zapisuji – přesto se jedná jen o cca 5–10% veškerého času (až 20% na ic.cz).
Takže jsem asi blbě napsal některé procedury a metody. Zjišťuji, že by se mě hodil profiler, jak to funguje v C/C++ – vypíše se, kolik času strávila aplikace v jaké metodě. Na netu jsem vyhrabal, že to nejspíš půjde (hlavně díky tomu, že třídy dědí od Nette/Object, čehož se striktně držím), ale nikde jsem nezjistil jak. Neví někdo, prosím, zda a jak to jde?

Můžeš prosím popsat, kdes vzal tolik dotazů na databázi? Vyvíjím teď jeden web, tak jsem si schválně nechal vypsat počet dotazů pro stránku s článkem a komentáři + nějakými věci okolo a mám tam 6 dotazů. Takže soudím, že 15 je opravdu moc :)

Laethnes

Panda napsal(a):

Profilovat umí Xdebug: http://xdebug.org/docs/profiler.

Dík, jdu se na to mrknout.

LastHunter napsal(a):

Můžeš prosím popsat, kdes vzal tolik dotazů na databázi? Vyvíjím teď jeden web, tak jsem si schválně nechal vypsat počet dotazů pro stránku s článkem a komentáři + nějakými věci okolo a mám tam 6 dotazů. Takže soudím, že 15 je opravdu moc :)

No… :3. Stránka s diskuzí:

Výběr seznamu v menu (položky v menu mají přiřazeny role, podle kterých se mohou zobrazit, či zakázat. Pochopitelně je to ošetřeno i ve startupu).
Následující 4: výběry dat ohledně rolí a práv, jak je navrhnuto někde na těchto stránkách Davidem právě pro kontrolu, zda je uživateli stránka přístupná. roles
acl
privileges
resources
Trošku zbytečný výběr. Mám dynamický systém multijazyčnosti, zde se vybírá seznam jazyků pro kontrolu správně nastavené proměnné aktuálního jazyka.
Výběr dat o aktuálním uživateli (nevzpomínám si už proč)
Zjištění počtu dat v aktuálně zobrazené diskuzi kvůli paginatoru
Výběr hlavních příspěvků v diskuzi (omezeno dle paginatoru).
Výběr odpovědí (udělal jsem systém stromových odpovědí – pro snížení počtu dotazů má každá odpověď dva odkazy: na předchozí odpověď a na hlavní příspěvek)
Výběr statistických dat o uživateli (mám odděleny od hlavních dat, jako je jméno, heslo a tak) kvůli zjištění času poslední návštěvy této diskuze a tedy k označení, které příspěvky jsou nové, taktéž proto, že v informacích pod menu je zobrazeno, počet nových příspěvků od poslední návštěvy dané stránky)
Uložení nové informace o tom, kdy naposledy uživatel viděl toto fórum a že již má přesně 0 nových příspěvků
Výběr z databáze seznamu vzhledů stránky
Výběr z databáze „statistiky osobních zpráv“ (pro možnost zobrazení informace, kolik nových zpráv z jakého počtu uživatel má)
Výběr ze statistik diskuzí (je jich více – 3 pro uživatele s maximálními právy – a jejich status (počet zpráv) je zobrazen v informacích).

Nicméně na běžné stránce je to 11 dotazů a když uživatel není přihlášen, tak 8.

(Pozn. jo, jsem si vědom, že hodně z těchto výběrů přímo volá po cachování, nicméně po té, co jsem zjistil, že dotazy nejsou hlavním problémem, tak jsem to odložil na neurčito :3.)

EDIT:
hromada oprav

Editoval Laethnes (26. 10. 2009 18:38)

Tomik

Jen jsem to zběžně proběhl, nečetl ten seznam celý, ale je tam spousta kandidátů na kešování – ACL, nějaké ty role a podobné věci, to se mění velmi málo a pokud tak invaliduj keš… Jazyky – taky kešovat. Menu – načíst celé menu – nakešovat – a zobrazovat pak jednotlivé položky podle potřeby…

Atd…

Laethnes

Panda napsal(a):

Profilovat umí Xdebug: http://xdebug.org/docs/profiler.

Možu mít takový hodně pitomý dotaz? Na netu jsem našel extenzi do firefoxu (https://addons.mozilla.org/…x/addon/3960) – neznáš ji? Nevíš k čemu vůbec slouží? Našel jsem kolem ní hodně infa, návodů, jak to nastavit, ale nějak netuším, co s tím… Když používám FireBug spolu s FirePHP, tak si tam otevřu okno a v něm mám info, ale toto rozšíření nic takového nemá. Pokud neznáš, neřeš.

Tomik napsal(a):

Jen jsem to zběžně proběhl, nečetl ten seznam celý, ale je tam spousta kandidátů na kešování – ACL, nějaké ty role a podobné věci, to se mění velmi málo a pokud tak invaliduj keš… Jazyky – taky kešovat. Menu – načíst celé menu – nakešovat – a zobrazovat pak jednotlivé položky podle potřeby…

Atd…

Jasně no… proto jsem pod ten seznam napsal:

(Pozn. jo, jsem si vědom, že hodně z těchto výběrů přímo volá po cachování, nicméně po té, co jsem zjistil, že dotazy nejsou hlavním problémem, tak jsem to odložil na neurčito :3.)

(Mimochodem, vzhledem k tomu, že tohle všechno se využívá na všech stránkách, přemýšlel jsem, že bych to všechno uložil do jedné obecné cache jako pole polí, které fungují jako cache jednotlivých částí.)

Panda

Laethnes napsal(a):

Panda napsal(a):

Profilovat umí Xdebug: http://xdebug.org/docs/profiler.

Možu mít takový hodně pitomý dotaz? Na netu jsem našel extenzi do firefoxu (https://addons.mozilla.org/…x/addon/3960) – neznáš ji? Nevíš k čemu vůbec slouží? Našel jsem kolem ní hodně infa, návodů, jak to nastavit, ale nějak netuším, co s tím… Když používám FireBug spolu s FirePHP, tak si tam otevřu okno a v něm mám info, ale toto rozšíření nic takového nemá. Pokud neznáš, neřeš.

Znám, jen to jen čudlík, kterým dáš Xdebugu pokyn, aby se připojil k debuggovacímu klientovi (tzn. IDE). Na profilování to nepotřebuješ a z IDE s podporou pro debuggování to povětšinou můžeš pustit taky.

Ondřej Mirtes

1: OK
2 – 5: Starou verzi psal Roman Sklenář, novou (Acl + AclModel) jsem psal já a na nutnost cachování tam upozorňuju.. ušetříš 4 dotazy :) Teď koukám, že vlastně jen 3, žádné getPrivileges() tam není, s těmi se pracuje jen v JOINu uvnitř getRules().
6: Cache :)
7: To dej do autentikační třídy a ty nutný věci vracej v Identity, čímž ten dotaz bude nutný jen jednou a to při přihlašování uživatele
8: OK
9 – 10: To jde na stoprocent vměstnat do jednoho dotazu (případně s LEFT JOINem), protože to jde u všech třech nejpoužívanějších metod: http://interval.cz/…-databazich/
11: OK
12: OK
13: Cache
14: To by se vešlo pod 12ku.
15: Tomu nerozumím, ale dejme tomu, že by to mělo být zvlášť.

Takže počet se dá IMHO dost dobře zkrouhnout :)

Editoval LastHunter (26. 10. 2009 19:27)

Laethnes

Panda napsal(a):

Znám, jen to jen čudlík, kterým dáš Xdebugu pokyn, aby se připojil k debuggovacímu klientovi (tzn. IDE). Na profilování to nepotřebuješ a z IDE s podporou pro debuggování to povětšinou můžeš pustit taky.

Aha :3. Tak jo, dík za info. (To víš, hledám něco, v čem bych to mohl zobrazit. Ale myslím, že už mám :3.)

LastHunter napsal(a):

1: OK
2 – 5: Starou verzi psal Roman Sklenář, novou (Acl + AclModel) jsem psal já a na nutnost cachování tam upozorňuju.. ušetříš 4 dotazy :) Teď koukám, že vlastně jen 3, žádné getPrivileges() tam není, s těmi se pracuje jen v JOINu uvnitř getRules().
6: Cache :)
7: To dej do autentikační třídy a ty nutný věci vracej v Identity, čímž ten dotaz bude nutný jen jednou a to při přihlašování uživatele
8: OK
9 – 10: To jde na stoprocent vměstnat do jednoho dotazu (případně s LEFT JOINem), protože to jde u všech třech nejpoužívanějších metod: http://interval.cz/…-databazich/
11: OK
12: OK
13: Cache
14: To by se vešlo pod 12ku.
15: Tomu nerozumím, ale dejme tomu, že by to mělo být zvlášť.

Takže počet se dá IMHO dost dobře zkrouhnout :)

Moc díky za pomoc. Určitě to použiju, ale jak jsem psal, v dotazech aplikace tráví minimum času na to, abych to teď řešil.

Nicméně:

2–5: kapišto

9–10: Hm… fajn, zkusím se na to mrknout, i když si to vůbec neumím představit :3. (Ve škole databáze mám, ale join jsem zapomněl :3.)

14: Do 12ky? Jak?

15: Tabulka: nazev_fora, pocet_prispevku, cas_posledniho_prispevku (názvy mám jiné, jde mi o princip). Každá diskuze má svůj záznam. Díky sloupci pocet_prispevku teoreticky by umožnil vynechání 8ky, ale není to pravda. Stránky rozděluji podle hlavních příspěvků, ty vedlejší se do toho nezapočítávají (kdysi jsem měl algoritmus, který to dokázal, ale dokážu si představit, že pro větší množství příspěvků by to bylo… příšerné. A ani to neřeším, takhle to stačí).

Laethnes

Mám zas takový pitomý dotaz. Co si mám myslet o tomhle? Nechal jsem si zobrazit stránku. Podle Nette Profileru trvalo její zobrazení 1068,8ms. (pozn. mimo otázku: podle Nette timeru to je 954ms – nechávám si zobrazit na stránce, takže ještě neproběhly destruktory, takže to je pochopitelné, předpokládám.) Pomocí xdebug jsem si udělal profilový soubor, který jsem si zobrazil v programu WinCacheGrind. Ten mi však tvrdí, že vše trvalo 115ms. To je trošku… mimo, ne?

paranoiq

to může být naprosto správně. tvůj program není to jedinné co tam běží – multitasking

Laethnes

paranoiq napsal(a):

to může být naprosto správně. tvůj program není to jedinné co tam běží – multitasking

Hm, tak to mě fakt nenapadlo. Pochopitelně to dává do určité míry smysl. Jenomže… tak trošku nechápu, jak na nezatíženém počítači (když dělám ten test, nic jiného aktivně neběží – ani hudba, snad jen IM) operace, která trvá něco málo přes 100ms je kvůli multitaskingu natažena na cca 1000ms? Dělám to u sebe na laptopu (už jsem výše psal – 1,6 GHz intel dual-core) a zobrazuji jen jednu jedinou stránku… Nekopíruji data na pozadí, neposlouchám hudbu, nesleduju videa na YouTube…

A bohužel, udělal jsem test, který to vyvrací. Prozatímně při spuštění scriptu mám bezpečnostní zámek, který se musí vytvořit, než se spustí zbytek scriptu. Vypadá to zhruba takto (je to jen dočasné řešení – tohle jsem řešil na jiném fóru):

<?php

while(!mkdir("zamek"))
{
	nahodnou_chvili_pockej();
	par_dalsich_testu();
}

renderovani_stranky();

odstran_zamek();

?>

Schválně jsem vytvořil ten soubor, reload stránky, odpočítal cca 10 sekund a odstranil jej. Podle Nette Profileru renderování stránky trvalo skoro 15s. Samotné vytvoření zámku jsem si pomocí Debug::timer() změřil na 14s (těch 10s jsem odhadoval). Výsledný soubor z xdebug jsem otevřel a výsledek: script trval 1484ms, z toho zámek údajně trval 1112ms (nahodné čekání) + 160ms (test času zámku – kdyby byl soubor příliš starý, začal by se tvořit zámek „zamek₂“) + 99ms (volání mkdir), samotná metoda lock prý trvala celkem 1392ms. Při tvorbě zámku mi tu chybí 12,7s minus pozastavení vlákna.

Když jsem tohle psal, napadlo mě, že usleep se nepočítá (a tudíž těch 1112ms na usleep byl „jen“ čas, který zkonzumovalo volání metody), tak jsem spustil aplikaci a dal usleep(1010001000). Odhadem jsem odpočítal 11s, Nette Profiler tvrdí, že stránka trvala 10920ms a WinCacheGrind? Ten mi v klidu tvrdí, že sice nejvíc času sebral usleep, nicméně ten čas je prý 1000ms (s tím, že byl zavolán jen jedenkrát). Mám pocit, že tu něco nehraje.

Honza Marek

Laethnes napsal(a):

Stránky mám na www.ic.cz, kde rendering trvá 1–10 s (pomocí Debug::timer())

Ach ty freehostingy…

Honza Kuchař

Četl jsem tady na fóru, že autor WinCacheGrid neumí převody jednotek. Takže je dost možné, že je tam posunutá desetiná čárka.

Laethnes

Honza M. napsal(a):

Laethnes napsal(a):

Stránky mám na www.ic.cz, kde rendering trvá 1–10 s (pomocí Debug::timer())

Ach ty freehostingy…

Tjn. Ale zas na druhou stranu je to aspoň hosting, kde Nette funguje (narozdíl od webzdarma s jejich PHP 4.3.4 :3). Pochopitelně z tohoto důvodu se spíš zaměřuji na to, jak to funguje u mě na PC, kde mi 800–1000ms taky přijde moc.

honzakuchar napsal(a):

Četl jsem tady na fóru, že autor WinCacheGrid neumí převody jednotek. Takže je dost možné, že je tam posunutá desetiná čárka.

Jo, to je dost možné… Vezmu-li všechny experimenty zpět, pak ten čas v podstatě vždy odpovídá s převodem krát 0.09 až 0.11, tedy zhruba 10× míň. Jdu to otestovat.

Laethnes

Honza M. napsal(a):

Laethnes napsal(a):

Stránky mám na www.ic.cz, kde rendering trvá 1–10 s (pomocí Debug::timer())

Ach ty freehostingy…

Tjn. Ale zas na druhou stranu je to aspoň hosting, kde Nette funguje (narozdíl od webzdarma s jejich PHP 4.3.4 :3). Pochopitelně z tohoto důvodu se spíš zaměřuji na to, jak to funguje u mě na PC, kde mi 800–1000ms taky přijde moc.

honzakuchar napsal(a):

Četl jsem tady na fóru, že autor WinCacheGrid neumí převody jednotek. Takže je dost možné, že je tam posunutá desetiná čárka.

Jo, to je dost možné… Vezmu-li všechny experimenty zpět, pak ten čas v podstatě vždy odpovídá s převodem krát 0.09 až 0.11, tedy zhruba 10× míň. Jdu to otestovat.

Laethnes

Mno… pustil jsem se do toho cachování a čas (u mě lokálně) se z 800–1000ms zvýšil na 1000–1200ms. :P Zato mám teď 6–8 dotazů na stránku. :3

Tomik

Laethnes napsal(a):

Mno… pustil jsem se do toho cachování a čas (u mě lokálně) se z 800–1000ms zvýšil na 1000–1200ms. :P Zato mám teď 6–8 dotazů na stránku. :3

To je opravdu možné, ovšem na produkčním serveru by to mělo být naopak.

P.S.: Ještě to může být špatně implementovaným kešováním… ;)

Jod

Mne práveže cachovanie aplikáciu zrýchlilo (z 10query na 0 :D). Ono podľa profileru ani tak nespomaluje to query ako jeho spracovanie. A rozdiel poznáš až pri väčšej záťaži.

Laethnes

Tomik napsal(a):

Laethnes napsal(a):

Mno… pustil jsem se do toho cachování a čas (u mě lokálně) se z 800–1000ms zvýšil na 1000–1200ms. :P Zato mám teď 6–8 dotazů na stránku. :3

To je opravdu možné, ovšem na produkčním serveru by to mělo být naopak.

P.S.: Ještě to může být špatně implementovaným kešováním… ;)

Jod napsal(a):

Mne práveže cachovanie aplikáciu zrýchlilo (z 10query na 0 :D). Ono podľa profileru ani tak nespomaluje to query ako jeho spracovanie. A rozdiel poznáš až pri väčšej záťaži.

Hm, rozhodně to zkusím (a počkám, až bude databáze větší :3). Pozn.: Na výsledném serveru se mě to bude testovat blbě – včera vykreslení stránky trvalo maximálně 4s, obvykle okolo 1s takže 2–10× rychleji, než obvykle :3.

Špatná implementace? Neříkám, že ne, většinou to dělám takhle:

<?php

__construct(...)
{
	$cache = Environment::getCache("moje_cache");

	if(!isset($cache["moje_data"]))
	{
		// Edit: dibi::query -> dibi::fetch*
		$this->data = dibi::fetch*("...");
		// ... atd
		$cache->save("moje_data", $this->data, array(
			nejaka ta expirace, sliding, ...
			));
	}
	else
	{
		$this->data = $cache["moje_data"];
	}
}

?>

a pak implementuji metodu, kterou volají formuláře a handlery při změně dat databaze, ktera maze danou cachi. (Nemažou ji rovnou samy, protože mam oddělenou třídu s daty a třídu s editorem, tedy z hlediska zapouzdření by editor ani neměl vědět, zda se cache používá či ne a když ano, pod jakým názvem – to má na starosti třída s daty, díky čemuž mám všechny volání cache na jednom místě a tak mj. mohu případně změnit název či umístění, aniž bych musel procházet celý kód a hledat, kde všude je to potřeba změnit.)

Editoval Laethnes (28. 10. 2009 8:40)

Honza Kuchař

třída s daty

= model :)

Laethnes

honzakuchar napsal(a):

třída s daty

= model :)

:O Dík! Tahle definice mě jaksi dlouho unikala, teď jsi mi osvětlil hodně věcí :3

Laethnes

Jod napsal(a):

Mne práveže cachovanie aplikáciu zrýchlilo (z 10query na 0 :D). Ono podľa profileru ani tak nespomaluje to query ako jeho spracovanie. A rozdiel poznáš až pri väčšej záťaži.

No… momentálně je zřejmě na ic.cz větší zátěž. Minulé dny touto dobou to trvalo 1–10s, teď, s novou „optimalizací“ (zatím okolo 3–6 dotazů za stránku) trvá rendering 20–60s.

Já vím, že Nette má být údajně rychlé, podle root.cz jeden z nejrychlejších frameworků vůbec, ale mám obavy, že za to zpomalení může právě Nette. Na ic.cz mám jiný web, který jsem psal v PHP. Nepoužívá žádný framework, ale to, co jsem kolem toho napsal by se teoreticky dalo považovat ze amatérský příšerný framework. Tato stránka se mi načte do 5ti sekund i teď, když je na ic.cz zátěž taková, že Nette stránka se mě renderuje okolo jedné minuty… (Ještě že tam mám nastavený vysoký limit :3.) Fakt už nějakou dobou přemýšlím nad tím, jestli jsem tak mizerný programátor, nebo je Nette oproti čistému PHP o tolik pomalejší… Samozřejmě si myslím, že to první je pravděpodobnější, ale proč tedy jiný web, co jsem dělal je o tolik rychlejší?

nAS

Jak tak tady poslouchám o ic.cz, tak mě napadá, jestli by nebylo vhodné zaplatit si za pár korun alespoň nějaký low-cost hosting.

Laethnes

nAS napsal(a):

Jak tak tady poslouchám o ic.cz, tak mě napadá, jestli by nebylo vhodné zaplatit si za pár korun alespoň nějaký low-cost hosting.

Jo, taky nad tím přemýšlím :3. Hlavně teda proto, že nemám představu, co po takovém serveru chtít a osobně subjektivně mě přijde, že pokud moje stránky požadují 1,6 GHz pro jednoho uživatele aby to vyrenderovalo za 1s, tak problém bude spíš mezi židlí a klávesnicí :3

nAS

Jestli ti fungují řádově stejně pomalu i příklady přibalené k Nette, tak je chyba někde v počítači, v opačném případě to bude blíž židle ;-)

Laethnes

nAS napsal(a):

Jestli ti fungují řádově stejně pomalu i příklady přibalené k Nette, tak je chyba někde v počítači, v opačném případě to bude blíž židle ;-)

No, to jsem teď netestoval, nicméně jsem krapánek pomalejšího běhu všiml hned, jak jsem s Nette začal. A vzhledem k jeho komplexnosti jsem nezačínal od začátku, ale z Quick Startu.

No, každopádně už jsem pochopil, co jste se mě v rámci cache snažili říct – já to vůbec nechápal! Já vás pochopil tak, že web by měl být tím rychlejší, čím víc se bude počet dotazů blížit nule. A proto mě to přišlo divné – snížil jsem ten počet ze 12ti na 3–4 a u mě na PC došlo ke zpomalení o cca 200ms. Pak jsem ale nakonec dosáhl (zatím jen na některých stránkách) snížení počtu dotazů na rovnou nulu. No a bez toho otevření databáze se výkon u mě na PC zvýšil o víc, jak 30%! Takže nešlo o co nejmenší počet dotazů – rychlost 2 dotazů a 12ti je hrozně podobná. Ale jde o snížení na přesně rovnou 0. Na daných stránkách skutečně došlo k výraznému zlepšení, které se nakonec dotklo i stránek, které ještě nemám optimalizované (např. to fórum), protože ostatní stránky jsou rychlejší a fórum má tedy víc výpočetního času/výkonu pro sebe. Všem moc moc díky.

Nicméně mám ještě jeden dotaz. Spíš upřesnění. V rámci Nette cache: na stránkách jsem si přečetl, že v rámci jednoho sezení se uloží výsledky a uvolní paměť skrz metodu „release()“. Chápu správně, že do té doby, než zavolám release() je cache soubor uzamčen, takže ostatní procesy jej nemůžou měnit (kvůli datům – něco načtu a než to uložím, uloží tam něco jiného jiné vlákno)? A volá se to nějak samo? (Předpokládám, že release() se vždy volá na konci programu.) Například vytvořím lokální proměnnou $cache, do ní načtu data, něco uložím, metoda skončí, lokální proměnná se zruší, ale nevolal jsem release(). Zavolá se v tomto případě sama? Nebo je to něco, co musím dělat sám a ručně? (Ani si nejsem jistý, co by bylo lepší, asi to druhé :3.)

redhead

Metoda release pouze maže cache z paměti, ta se sama po konci programu maže, protože http není stavový (teda aspoň doufám). Release by mělo sloužit jen pro opravdu velké cache, aby zbytečně tu pameť nezahltili a byl prostor pro další (třeba náročné) operace. Release tedy není třeba volat.

Cache se využívá pouze k jedné věci, pokud není objekt cachovaný, zakešuj ho a pak z ní už jen čti. Neměli by 2 různé procesy vytvořit stejnou cache – 1 ji vytvoří a 2. ji už jen čte. V jednu chvíli buď cache je a nebo není.

Pokud nastane změna, opět se provede jenom jednou. Další procesy už musí logicky číst změněnou cache.

Editoval redhead (30. 10. 2009 10:49)

Laethnes

redhead napsal(a):

Metoda release pouze maže cache z paměti, ta se sama po konci programu maže, protože http není stavový (teda aspoň doufám). Release by mělo sloužit jen pro opravdu velké cache, aby zbytečně tu pameť nezahltili a byl prostor pro další (třeba náročné) operace. Release tedy není třeba volat.

Cache se využívá pouze k jedné věci, pokud není objekt cachovaný, zakešuj ho a pak z ní už jen čti. Neměli by 2 různé procesy vytvořit stejnou cache – 1 ji vytvoří a 2. ji už jen čte. V jednu chvíli buď cache je a nebo není.

Pokud nastane změna, opět se provede jenom jednou. Další procesy už musí logicky číst změněnou cache.

Hm. Takže chápu tohle správně, že když dám něco číst z cache, soubor se otevře, načte, uzavře a já pracuji s těmi daty, a v době tohoto procesu mohou číst tu samou cachi další procesy. A klíčové je udržet uzamčenou databázi, ne cache soubory? Jde mě třeba o tohle: mám soubory, které mají být přístupny jen pro určité uživatele. Tedy načtu info o uživateli a o souboru (obojí cachované), nepoužiji release() a začnu odesílat data. Před odesláním daty uzavřu spojení s databází, protože již nepotřebuji, aby byla uzamčena (a mohly ji používat i jiné procesy) – u větších souborů se stahování může protáhnout a je zbytečné, aby to zdržovalo všechny ostatní stránky. Jenže pokud je cache uzamčena do jejího uvolnění, pak stejně procesy musí čekat. Ale pokud se uzamykají jen pro přečtení a pak pro zápis, pak již není potřeba tohle řešit. O to mě jde.

A další věc: chci implementovat to, že budu mít někde nějaký seznam s aktivními uživateli (včetně nepřihlášených hostů). Z důvodu, že když se vůbec nepřipojím k databázi, je stránka mnohem rychlejší, to nechci řešit přes databáze, ale právě přes cache – seznam všech uživatelů (asi klíče skrz id v cookie + ip adresa (kvůli těm, co nemají povoleny cookies) a samozřejmě k tomu čas poslední aktivity), kteří jsou aktivní a mohl bych na stránku napsat: „aktuálně je na stránkách 7 uživatelů“. Napadlo mě to řešit přes sessions, ale nevím, jak číst i ostatní sessions, ne jen tu aktivní. Navíc bych rád i info o přihlášených uživatelích…