WEWERKA: To vypada jako docela dobry napad, ale pokud jde o pocitani neprihlasenych hracu, tak pocitej s tim, ze lidi hrajici z prace (obzvlast ti pracujici na nejakych mene frekventovanych mistech nebo statni sprave) budou prihlaseni porad a pokud nekdo vymysli nejaky helper, tak nebude ani ta minutova neaktivita:)

Tak jsem na to asi prisla :) Vsechny subjekty patri nekam na mapu. Pokud se zmeni na nekom, kdo ma uz vypocitanou predikci, jednodusse vezmu vsechny subjekty se vztahem na dane policko v mape a uplne vsechny prepocitam. Teoreticky by se melo jednat o 50-200 radku, worst case scenario max 1000. A pokud to predelam na paralelni vypocet, tak by to mohlo byt dopocitane za chvili.
K tomu optimalizace stylu a) pocitej neprihlasene hrace b) pocitej par minut po hracove neaktivite.
Tahy budou radove 1-2h, v rychlem rezimu treba 30 minut. Takze cas na propocet urcite bude.

CYBERWOLF: Ja mam zkusenosti hlavne s MSSQL, ale tenhle pristup mi pripada pomerne jednoduchej a efektivni, tak jsem si rikal, ze by to mohli implementovat i ostatni stroje. Ale hlavu na spalek, bych za to nedal :)

Hm, diky za tipy. Dedeny tabulky v praci pouzivame a ani vlastne nevim proc :)

TENCOKACISTROMY: mam za to, ze tohle dela jenom MSSQL :)

CYBERWOLF, CYBERWOLF: Jj, s tim souhlasim.

WEWERKA: Nemyslim radky, ale stranky. Napr. MSSQL (ale u ostatnich to bude imho stejne) si tu tabulku rozdeli na jednotlivy casti (= stranky) o velikosti X radku. Kdyz pak delas nejakej update zamykaj se jen ty stranky, kde se neco updatuje. Kdyz updatujes na zaklade sloupcu, ktery maj indexy tak se ti i rychle vyhodnotej stranky, ktery se maj zamknout. Navic si u transakci muzes (zase - neznam moc dobre postreges, ale urcite to bude umet) nastavit, aby se ti to lockovalo jenom pro zapis, ne pro cteni.

Jestlize mas velky mnozstvi ruznejch typu objektu, spis nez nejakou univerzalni strukturu o par tabulkach pro ulozeni vseho bych pouzil "dedeny tabulky", ktery by byly jakoby tridy (class v OOP). Tim by jsi cekani na zamky docela dost omezila.

CYBERWOLF: jinak receno, myslim si, ze pokud se nebude resit vse najednou, ale tak ze se bude - treba paralerne - pracovat pouze s vysledky nejake uz ukoncene faze a dalsi faze nezacne dokud neskonci ta stavajici, tak k deadlocku nemuze dojit.

WEWERKA: k deadlocku by, si myslim, melo/nemelo dochazet nezavisle na vykonu stroje. Kdy muze nastat? Neco ceka na neco jineho, co ceka zatim ceka na to prvni neco, coz muze nastat jen v pripade, ze by se to vyhodnocovalo paralerne a to veci, ktere na sobe vzajemne zavisi. Kdyz se ale budou vyhodnocovat veci, ktere zavisi jen na necem, co uz bylo vyhodnoceno predtim a ne na tom, co se vyhodnocuje ted, tak by tenhle problem nemel nastat.

CYBERWOLF: K tomu deadlocku by v takove databazovem navrhu mohlo dochazet dost casto. Je to teda jen teorie, stejne nemam zadny quad+ stroj na otestovani.

CYBERWOLF: Tak nejak jsem to delala v te mezifazi. Pocitala jsem to podle kategorii. Zlepseni bylo, ale stale ne dost.


Ted me napada reseni, ktere tady zminil TENCOKACISTROMY tzn. castecne predpocitani a navic na to aplikaci stromu zavislosti. Ale budu si to muset dukladne rozepsat a rozmyslet.

WEWERKA: cemu by vadilo zamykat jenom radky?

TENCOKACISTROMY: Vsechno v jedne tabulce. Ridici tabulky k jednotlivym typu a konfigurace jsou mimo.

Zamykat stranky? Myslis row? To umi, ale nepouzivam.

Co rozdelit tah na (nejak logicky navazujici) faze a provadet je postupne? Tj. ze kdyby mel probehnout tah - rekneme - jednou za hodinu, tak by se misto toho provedlo kazdych 15 minut neco.

Napr. (podle minimalne predstavy, kterou o tve hre mam:) ):
1) presuny (pracovnik odejde do jineho mesta)
2) produkce (pracanti pracuji - vyrabi veci)
3) spotreba (pracanti jdou na obed)
4) ztraty (shorela kovarna)

Pokud je mozne rozclenit tah na vic samostatne vyhodnotitelnych fazi, tak se tim zatez prijemne rozlozi - samozrejme cim vic fazi, tim lepe se rozlozi. Hraci co u toho budou prilepeni ve dne v noci pak muzou taky lepe reagovat na to, co se deje, namisto toho, aby se po provedeni celeho velkeho tahu divili, co se jim to stalo :)

WEWERKA: Jako ze mas vsechny atributy v jedny tabulce nebo ze mas ty tabulky jakoby podedeny od sebe?

Ten postgress neumi zamykat jen jednotlivy stranky misto cely tabulky?

TENCOKACISTROMY: Pouzivam db navrh jako ma ucetnictvi Noris. Jedna obrovska tabulka, kde jsou uplne vsechny mozne subjekty - lidi, material, produkce, vylepseni, kouzla atd. Proste vsechno v jedne tabulce.
Sice nepouzivam explicitni row lockovani, ale i tak si myslim, ze sance na deadlock je velka. Predikci treba propocitavam po jednotlivych subjektech tzn. po 1 radku.

Mozna kdybych to prepsala na "select for update" a k tomu si koupila 8 jadrovy stroj, tak by tu byla urcita sance :) Ale i tak necekam obrovske zrychleni..

WEWERKA: Tak ono se da paralelizovat mnoha zpusoby. To ti tam opravdu uplne vsechno zalezi na uplne vsem? Nemuzes to rozdelit na nekolik fazi, ktery se daj rozdelit na nekolik na sobe nezavislejch vypoctech?

TENCOKACISTROMY: 200k uzivatelu ne, spis tak 200k "jednajicich db radku"

TENCOKACISTROMY: Problem je v tom, ze opravdu neumim udelat uplne paralelni vypocet. Sance na deadlock je v mem pripade hodne velka.
Taky mi neni prijemne, ze to musim delat sekvencne :( Kurzory nepouzivam.

WEWERKA: Jestlize celej ten vypocet je sekvencni, tak ti je jedno, ze si zamyka tabulky, ne? Teda v pripade, ze do nich nechces zaroven psat data od uzivatelu - ale proc neco takovyho delat?

Kdyz se vyhnes kurzorum a vyuzijes toho, v cem je to sql silny - mnozinovy operace, tak bych v tom nevidel zasadni problem.

WEWERKA: Jestlize chces mit 200k uzivatelu, tak bych to cely resil rovnou nekolika serverama. Atom je fajn na vyzkouseni, ale v realu budes mit dost jiny prostredi a na to bych se soustredil.

TENCOKACISTROMY: Ne, 80k je jen na testovani. Realnejsi odhad je tak kolem 200k za plneho provozu.