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.
??? --- 11:04:40 15.6.2010
Jojo, do hry je potreba investovat. Kuprikladu ja ze sveho stareho testovaciho atoma udelala dual atom na otestovani vice threadu.
Dokonce pamet se zvysila o 1gb :DDD Velka investice, snad se mi to za 10 let az do doprogramuji i vrati :DDD
TENCOKACISTROMY --- 10:37:26 15.6.2010
CYBERWOLF: Tak ona ta RAMka neni zas tak draha (oproti cene vyvojare/db specialisty) a v dnesni dobe 64bitovejch serveru s tou velikou pameti neni zadnej zasadni problem. Mit 16/32/64 GB RAM sice neni uplne bezny, ale na druhou stranu to taky neni zadny zavratny mnozstvi.
CYBERWOLF --- 10:32:40 15.6.2010
Tak nejak jsem na to natahovani do pameti vzpomel, kdyz jsem se ted hrabal v databazich a kdyz vidim celkovou velikost databazi v radech GB, tak mi to prijde jako celkem nerealne, aby se skutecne drzelo v pameti vsechno (ve vetsine pripadu aplikace skutecne pracuje s drtivou vetsinou databaze). Mohlo by to fungovat s DB co ma par stovek mega, ale u velkych DB si to nedokazu predstavit.
??? --- 10:24:18 15.6.2010
TENCOKACISTROMY: Hmm :) tak tohle asi pgsql nema :) Teda aspon myslim..
TENCOKACISTROMY --- 10:19:22 15.6.2010
CYBERWOLF: Natahovani tabulek do pameti by mel umet ten DB stroj sam od sebe. Mel by splnovat ACID, a pak se o vubec nemusis starat o to co se ti kam zapsalo ci nezapsalo, protoze vis ze to mas na disku i v pameti.

???: U tech tabulek je zajimava moznost to rozdelit jak vertikalne (jednotlive sloupce jsou na ruznych discich), tak horizontalne (na zaklade nejakeho indexu jsou radky na ruznych discich). Doufam, ze jsem to vertikalne/horizontalne neprehodil, neustale si to pletu :)
??? --- 10:01:36 15.6.2010
No koukam, ze je tu diskuze asi hlavne o mssql. V pgsql jsou shared buffers, ktere pri spravne velikosti pomahaji vykonu a to tak ze dost. Ale pri vetsi velikosti skodi.
Dalsi vec je rozdeleni dat do tablespace. Takovych X (x > 10) SAS disku taky udela svoje.
Pak treba misto beznych disku muzete pouzit SSD.
CYBERWOLF --- 8:51:07 15.6.2010
YAWGMOTH: Kdyz je dotaz osklivy, je nejlepsi ho prepsat aby byl hezky:)

Ale kdyz uz jsme to tu nakousli, jak to myslite s tim natazenim DB do pameti? Jedine, co me napada, je vytvorit si tabulky jako Memory, pracovat s nimi a treba jednou denne to zazalohovat do nejake "normalni" databaze, jenze pokud spadne server, je databaze pryc a muzu jet nejvys od posledni zalohy (a rekl bych, ze to s daty v pameti jinak nepujde)
YAWGMOTH --- 1:44:27 15.6.2010
CYBERWOLF: ad to srovnání, to přece záleží na tom jakým dotazem ty data bereš ... jednoduchý dotaz to moc urychlit nemůže, ale takový většinou necachuješ. A jakmile je to dotaz ošklivý tak ten výsledek bude někde úplně jinde. (samozřejmě je tu i možnost cachovat zpátky do DB :) ).

A co se týče těch 2GB, to už hodně záleží na povaze aplikace a těch dat, ale opravdu v tom nevidim problém, webový server u takové hry pravděpodobně až tolik paměti žrát nebude a databázový bude zvlášť :)

TENCOKACISTROMY: celá DB v paměti je pochopitelně základ, pokud to jde.
TENCOKACISTROMY --- 15:16:36 14.6.2010
YAWGMOTH: Ona je pak otazka, jestli radeji tu pamet nenechat db stroji, ktery si tam pak muze dat celou db a vyhledavat pak v ni. To ti s vykonem taky dost pomuze.
CYBERWOLF --- 15:08:04 14.6.2010
Nooo, 2GB do pameti, to uz bych se asi trochu bal. Pokud by toho frcelo tolik, ze by bylo potreba cachovat tolik dat, tak ta pamet bude asi spis potreba nekde jinde.

Kazdopadne, tady jde o neco trochu jineho - query cache je tak nejak transparentni zalezitost. DB server si to resi sam a kdyz ma validni cache, tak sahne misto do tabulky do ni a vrati vysledek zdibec rychleji a kdyz nema, tak vrati vysledek a to same si nacpe do cache. Jenze pokud se do te cache nestaci podivat driv, nez ta cache vyexpiruje, tak to dela uplne zbytecne a kdyby to nedelal, tak by mohl jet o neco lip (a do dneska jsem to jeste nevyzkousel, hmmm).



Kdyz uz mluvime o cachovani, tak pred nejakym casem jsme v praci zkouseli, jak by se dala cachovat aplikacni data (celkem velky balik), aby se odlehcil SQL serveru. Celkem prekvapive (alespon pro me) jsme dospeli ke zjisteni, ze akorat memcache dokaze ta data vratit rychleji a to jeste ne o moc. Moduly pro cachovani dokazali cache vratit v case srovnatelnem s MySQL (bez cache). Cachovani do souboru bylo dokonce znatelne pomalejsi.

Ukazalo se, ze vyrazny podil na pomalosti cache ma rekonstrukce dat, protoze neni mozne ukladat rovnou pole, je potreba ho prevest do nejakeho ulozitelneho formatu (serializovat,csv,json, xml...) a prave rozparsovani po nacteni je nejkritictejsi bod.

Zaver, ktery z toho experimentu plyne je, ze prakticky nema cenu cachovat data a jedine co se vyplati cachovat je hotovy vystup (ktery se tedy nemusi porad generovat a hlavne se da ulozit/nacist tak jak je).