Tento web používá soubory cookie. Dalším používáním webu s tímto souhlasíte.
jméno
heslo
přihlásit
zaregistrujte se
zapomněli jste heslo?
On-line WebBased hry kreativně - udělejte si vlastní webovku!
CYBERWOLF
Hráli jste někdy nějakou webovku a napadlo Vás někdy udělat si nějako vlastní?
Máte nějaký nápad na bezva hru a neumíte ho realizovat?
Nebo umíte skvěle programovat webové aplikace, ale nemáte nápad na dobrou hru?
Nebo namáte ani jedno a umíte cokoliv jiného, co by mohlo při tvorbě hry pomoct (malovat, dělat hezky vylížející html stránky, jakoukoli grafiku, nebo jste matematický génius, prostě COKOLI)
Pokud Vám vyšla alespoň jedna kladná odpověď, jste tu správně!
Máte k tomu co říct? Vložte se do diskuze.
CYBERWOLF --- 19:36:19 13.6.2010
YAWGMOTH: memcache je fajn, ale ta pamet taky neni nafukovaci :)
YAWGMOTH --- 11:18:41 13.6.2010
CYBERWOLF: proto se reálně používá ještě cachování na úrovni aplikace, třeba s memcached, a do databáze vůbec nelezeš :)
CYBERWOLF --- 14:06:15 9.6.2010
TENCOKACISTROMY: Tak to je jesny, ze zalezi na situaci, ale ja bych prave rekl, ze zrovna webove hry jsou ten typ aplikace, kde tech insertu a updatu v pomeru k selectum docela dost (a proto tu o tom mluvim:) ).

Ale jak o tom tak prubezne premyslim, napadlo me, ze by mozna mohlo pomoct v pripadech kdy je nepriznivy pomer select/zmeny, tak jednoduse query cache vypnout a zbavit se tak overheadu s overovanim a ukladanim cache, ktera se stejne v 99.9% pripadu nevyuzije.
TENCOKACISTROMY --- 13:35:01 9.6.2010
CYBERWOLF: Tak to je samozrejme o tom, v jakym scenari to pouzivas. Kdyz mas naopak velkej pocet selectu a malej pocet zmen, tak se ti to vyplati.

Resit query cache jsem nikdy nemusel, pac mi skoro porad vychazej dotazy pokazdy trochu jiny a casto se mi menej data. Ale vim, ze treba MSSQL umi notifikovat, ze se zmenily data pro tebou zaslanej dotaz. Doporucuje se to ale pouzivat v omezeny mire, aby si prave tim porovnavanim jak rikas, nezabrdil celej stroj. Jak to maj reseny uvnitr netusim, ale tipuju ze je to delany podobne jako Change Data Capture.
CYBERWOLF --- 12:29:59 9.6.2010
TENCOKACISTROMY: nebo takhle, vis o nejakem db serveru, ktery tohle skutecne dela?
CYBERWOLF --- 12:24:09 9.6.2010
TENCOKACISTROMY: nj, ale predstav si, ze mas cachovanych par stovek (tisic, desetitisic...) dotazu a pri kazdem insertu musis proverovat, jestli by se vlozeny zaznam do nektereho nevesel aby se cache zinvalidovala. To mi neprijde realne, rekl bych, ze overhead bude daleko vetsi, nez zisk, obzvlast pokud budou inserty/updaty casto.
TENCOKACISTROMY --- 12:18:08 9.6.2010
CYBERWOLF: Jak kdy. Kdyz bys mel napriklad "SELECT a,b,c FROM tbl WHERE d > 10", tak pri "INSERT INTO tbl (a,b,c,d) VALUES (1,2,3,4)" docela jasne vis, ze to invalidovat nepotrebujes.
CYBERWOLF --- 12:08:31 9.6.2010
TENCOKACISTROMY: tohle konkretne MySQL, ale pochybuju, ze to jinde bude jinak. Logicky, kdyz zmenim obsah tabulky, tak se meni i to, co muzu vybrat a musi se invalidovat cache. Tezko by mohlo byt zjistovani, jestli do ktereho nacachovaneho dotazu by se vlozeny/upraveny zaznam vesel efektivnejsi, nez invalidace cache pro danou tabulku
TENCOKACISTROMY --- 12:06:19 9.6.2010
CYBERWOLF: A to se tyka kteryho db stroje?
CYBERWOLF --- 12:01:31 9.6.2010
Jen tam mimochodem, trochu jsme ted resili cachovani SQL dotazu a tak nejak vyplynula takova (nakonec docela zrejma) vec a to ze query cache se invaliduje pokazde, kdyz se tabulka zmeni (struktura, nebo obsah). Me tak napadlo, ze to je v pripade webovych her docela pruser, protoze pripadu, kdy se nejaka data pouziji vic nez jednou do chvile, nez do tabulky nekdo zapise bude opravdu malo.

Je tedy pravda, ze pokud bude dotaz dobre napsany, probehne rychle i bez cache, ale i tak mi to pripada jako oskliva neprijemnost :(