Nemuselo to tak uplne vyplynout, ale vsechny procesy se v php forkuji.

Jinak nevyhoda - spatne se mi debuguji problemy.

Po nejake dobe testovani jsem prisla na nejlepsi variantu zpracovani. Treba bude nekoho zajimat jake problemy ho muzou potkat.

Pracuju s postgresem a php. Diky php nemuzu pouzivat listen/notify, takze se porad musim dotazovat do db. Php sice ma fci na notify, ale ta se stejne porad dokola pta. Dalo by se vyresit dotazovanim z C, tam notify funguje bez problemu.
To je slabina c.1.

Dalsi vec je pamet viz CYBERWOLF. Pouzivam na to knihovny, ktere si pri kazdem volani par bajtu seberou.
Kvuli viceprocesorovemu zpracovani musim volat jednotliva db volani samostatne (connect, query, close). Protoze close potomka by mi zavrel persistentni spojeni i pro hlavni pripojeni. Proste pamet se pri takovem volani zabira pomerne rychle.
Slabinu c.2 - pamet, jsem vyresila automatickym ukoncenim skriptu pri dosazeni urcite obsazene pameti. Skript se navic ukonci 10 sec pred kontrolou na nove spusteni (spousteni z cronu kazdou minutu), tim padem nemuze dojit k vypadku zpracovani (minuta uz je hodne).

Je to na freebsd a nemuzu uplne vyuzit signaly, protoze se tam zpracova vic signalu najednou a to pro moje ucely neni idealni. Na linuxu bych signaly nejspis vyuzila a mozna bych neresila centralni zpracovani pres db.


Takze si eviduju ukoly v db. Ukladam si pidy childu, ktere prijmou job a eviduji stavy, tak abych mohla zajistit vetsinou failover stavu. To vsechno pro napr. 4 procesy najednou (nastavitelne za "behu").

Navic skript si kontroluje, zda vsechny joby opravdu bezi. Kazdy job ma predpokladany cas, takze kontrola nastava az po danem case. Krom toho je u jobu nastavene jak moc kriticky je, zda stopnout cele zpracovani nebo to jen oznamit, ci proste ignorovat a jit dal. Nekriticky job se teoreticky muze pri prelomu proste smazat a udelat se jindy.

Pokud dojde k padu, jsem schopna opetovnym pustenim nedodelane ukoly znovu pustit a dozpracovat. Tady byla potreba kontrola na dvoji zpracovani (job se dela, nastava pad, job se v db dozpracoval a nedal vedet ridicimu zpracovani, opetovne pusteni, dozpracovani spadleho jobu, priznak ze job je jiz zpracovan, pad childu resp. rollback)

Na vsechno existuje planovac. Paradoxne existuje job na vytvoreni planu, ktery tvori ukoly :) Joby vytvari tak, aby se zpracovavaly pokud mozno rovnomerne a logicky s ohledem na logiku hry.
Joby maji v nastaveni priznak, ze muzou ci nemuzou byt soucasne pustene - nemuzou tak vzniknout situace jako "kdyz tam nic neni, vloz tam 1000 zaznamu" a ve vysledku se vytvorilo 2000 zaznamu, protoze se to najednou zpracovalo ve 2 procesech.

Vysledkem je histogram jobu. V budoucnu se pouzije statistika pro dalsi upravy za behu napr. prumerna delka pusteni bude upravovat limit pro kontroly bezicich jobu.

Timhle zpusobem zpracovani veci, ktere trvalo 20 minut se na 4 jadrech (atom, 2 cpu, 2 HT) dela presne 5 minut.

AVATAR: To zalezi na spousta vecech. Muzes mit klidne gigantickou mapu (treba milion zaznamu), ale kdyz to budes mit dobre indexovany a clusterovany, a dotazy a updaty se budou vzdycky tykat "malyho" mnozstvi zaznamu, tak je v zasade jedno jestli tam tech zaznamu je milion nebo dva miliony.

CYBERWOLF: jaky jsou tvy zkusenosti? Ja chci radeji zacit trochu pri zemi, abych pak nebyl nemile prekvapenej...

YAWGMOTH: smycka se sleepem je ale trochu vypecena, je treba si zajistit, aby to OPRAVDU bezelo jenom jednou a pokud to z nejakeho duvodu bezet prestane, aby se to znovu pustilo, coz neni uplne sranda.

Na zamek pozor, protoze skript muze neocekavane skoncit a zamek tam zustane viset.

Dalsi vec je, ze kdyz skript spi, tak sice nezatezuje procesor, ale porad si drzi pamet (coz u prepoctu muze byt docela knedlik), spojeni k DB a podobne zdroje.

AVATAR: Tady by asi byl docela prostor pro optimalizaci prace s DB, protoze 50k zaznamu... to mi prijde porad dost malo na to, aby to byla hranice pohodoveho provozu.

ok, neco o tom jeste nactu a verim ze se mi to podari dat dohromady, diky za doporuceni ;)

Plus k tomu navic zpracovani pres fork(). Na to jsem prisla diky podnetum tady ve foru a skutecne to zpracovani zrychlilo. A to jsem se bala zamykani.

Jinak na zamek je idealni ukladat vlastni pid do db a ten pak kontrolovat na spusteni. Nemuze dojit k deadlocku jako kdyz se pracuje s diskem.

Neco takoveho

//nactu si pid z sql a overim jestli se nepousti 2x
$r=exec_sql_getone("select coalesce(konstanta_int_vrat('ROBOT_PID'),0)");
if (!empty($r)) { //test na dvoji spusteni
$tmp=`/bin/ps -o command -p $r`;
if (eregi(ROBOT_RUNTIME,$tmp)) { die("dvoji spusteni\n"); }
}
//nastavim pid
echo "nastavuju pid=".getmypid()."\n";
exec_sql("select konstanta_int_nastav('ROBOT_PID',?)",array(getmypid()));

YAWGMOTH: aha, uz rozumim. Diky moc za tip ;)

AVATAR: něco jako

$data = array();
while (true) {
    sleep(1); // sleep je na začátku schválně, kdybych chtěl někde v následujícím kódu
              // třeba použít continue, nebo něco takového, prostě aby bylo zaručeno, 
              // že v každém běhu smyčky ten spánek skutečně nastane
    if (empty($data)) { $data = nacteni_akci_z_databaze(); }
    
    $akce = array_pop($data);
    if ($akce) zpracuj_akci($akce);
}

tohle se pro jistotu stejně pouští cronem, aby se to samo spouštělo znovu, kdyby to náhodou kvůli nějaké chybě spadlo.. ale zároveň se ten proces nesmí množit, takže na začátek to chce ověřit, jestli už to neběží.. třeba

if(!mkdir("cesta_k_zamku")) {
  // vhodná cesta je třeba /var/lock, /tmp, nebo tak, prostě adresář, který je při restartu systému promazán
  // adresář se nepovede vytvořit pokud už existuje a tedy tenhle skript běží, tj  můžeme končit
  exit;
}

Tohle teda je trochu zjednodušeně a ani ne kompletní (ještě je třeba ten zámek občas mazat, třeba poznat když skript už neběží protože spadnul), i je podobných možností víc ... Na obdobné téma zrovna má být v Praze přednáška, byť teda ne v PHP, ale principy snad budou podobné: http://srazy.info/4it445-vyvoj-webovych-aplikaci-na-vse/908

a k tomu omezení databáze: chápu no, já s tim právě taky trochu bojoval, chtěli jsme totiž vysloveně masivní multiplayerovou hru, kde hrají všichni spolu. Na facebooku třeba taková vpodstatě není ani jedna, což mi přijde smutné, ale potom při stovkách tisíc hráčů už relačním databázím dochází dech no, my nakonec od MySQL odešli a zkoušíme válčit s MongoDB.. jestli jsme si pomohli se teprve uvidí :)

YAWGMOTH: diky za radu i za prani ;)

tech 2500/svet je z duvodu db. Cim vic zaznamu, tim pomalejc to bezi, takze se to snazim dimenzovat na 50k zaznamu s plnym serverem. Takze to rozlozim takhle na svety, ktery budou mit samostatny db.
Gulas v tom snad nebude, kdyz budu nabizet jen svety podle zeme...

tou vecnou smyckou myslis co, prosimte. Obsah sdeleni jsem pochopil a beru na vedomi (peaky nechceme), ale kde mam pustit vecnou smycku fakt nevim. V podstate jsem na tohle vzdycky pouzival cron i kdyz to bylo v ramci vterin.

AVATAR: nebude trochu guláš v těch světech? Jestli to chceš rozjet ve velkém a 2500/svět, tak jich můžou být třeba i stovky :)

jinak co se týče spouštění skriptů 1x za minutu, může se ti stát, že ti to bude dělat pravitelný peak a ta nerovnoměrná zátěž je nepříjemná, buď musíš mít servery předimenzované, nebo si kolem té celé minuty budou lidi stěžovat na přetížení (ale samozřejmě záleží na konkrétnim kódu, je možné, že ten tvůj přepočet bude proti zbytku aplikace zanedbatelný nebo tak). Já bych se tohle snažil rozložit rovnoměrně, cronem jen kontrolovat jestli zpracování běží, jinak věčná smyčka a v ní se vždycky podívat jestli jsou k dispozici akce, zpracovat je, na chvilku (nějakou vteřinku) se uspat a zkusit to znovu.

jinak hodně štěstí no, betu nám pak ukaž :)

asi jsem zapomel napsat, ze uzivatel vidi pouze vysek z cele mapy

p.s. uz na tom makame vic jak rok a investoval do toho tolik usili a penez, ze to fakt dva metry pred cilem nevzdam ;)

nechystame to pro cesky trh (i kdyz lokalizace samozrejme bude), ale pekne ve velkym.

CYBERWOLF: uzivatel v mape planuje trasu, po ktere jeho postavicka pujde. Jednotlive waypointy se ukladaji do db. Neplanuju trasu z jednoho konce mapy na druhy, pouze v ramci jedne obrazovky. Vsechno kontroluju pak na serverove strane, pocet kroku, jestli jdou po sobe etc. Nerikam, ze to nepujde nejak ojebat, ale ja neprisel na to jak. Snad open beta napovi ;)

Nase mapa bude mit dost takticko strategicky raz a urcite nebude jen na okrasu, spise naokap, je velmi interaktivni. Nechte se prekvapit, open beta uz na sebe snad neda moc dlouho cekat. Mafie byl jen priklad aplikace. Inzerat jsem repastoval z jinyho auditka, kde to nebylo dany tematem ;)

TENCOKACISTROMY: pote co spusti hrac naplanovanou trasu a jde off, vygeneruju ke kazdemu kroku cas od kdy do kdy je hrac na tom tile. Na mape pak ostatnim hracum zobrazuju podle toho v ten dany cas tu spravnou ikonku hrace. Pokud je na konci nejaka akce (treba fajt), kazdou minutu se mi vola script, ktery zjistuje stojici hrace s neprovedenou akci a tu akci pak spusti.

Jeden verejny svet pocita s maximem 2500 hracu.

TOMAS3333: Dostal jsem se na cca 85 hodin, dekuji za optani :)

Prochazeni jednotlivych stranek/odstavcu/uzlu/kroku (jak je libo) mi funguje i s autosavem, uz mam i celkem funkcni podminkovani a ted se chci poradne ponorit do zmen stavu postav (nejake pridavani ubirani vlastnosti/hodnot mam, ale chtel bych nejake casove omezene efekty a podobne).

Problem bude inventar a vylepsovani postavy, ale sance, ze se vejdu do 120h se mi zda zatim realna :)

btw, jak to vyzera s tym 100 hodinovym pokusom?

AVATAR: Proc vsichni cpou do webovek mapy, jeste nedej boze s pohybovymi efekty? Takovyho srani s tim a nakonec budou pro hrace ty efekty jen otravnym zdrzovanim. Ve hre typu Mafie si ani pro mapu nedokazu predstavit moc vyuziti, ale hadam, ze je to proto, ze ta hra neni az tak moc Mafie a to je jedine dobre.

Vypocet cesty pouze javascriptem ti ale urcite stacit nebude - lidi to budou ojebavat a to hrozne moc. Ja jsem pred casem hledani cesty v php take resil (protoze jsem si taky musel do svoji hry nacpat mapu, ze ano) a to jeste s vypoctem vzdalenosti a to vsechno podle zemepisne sirky a delky (takze jeste na kouli :) ).Ve vysledku se mi cesta se sto kroky pocita asi sekundu. Sice to neni moc unosne, ale s kratsimi trasami se to da a verim, ze bez pocitani vzdalenosti na kouli i rychleji. Jak dlouhe cesty pocitas?

Jak to na me pusobi, mas to nejdulezitejsi za sebou a ted uz zbyva to jen dotahnout, takze se da pocitat s tim, ze se na to za mesic nevykasles. Drzim palce pri hledani pomocnika.

AVATAR: dibi - a je klid :)

AVATAR: Jak resis pohyb, kdyz je klient offline ci vytizenej a neposila ti data dost rychle?

Na kolik hracu to je dimenzovany?

zajimalo by me, jak resite connect do databaze?

Tak sem sepisu naky svoje zkusenosti, coby reakci na prvni prispevek ;)

Za celou dobu vyvoje jsem nenarazil takrka na nic, co bych na tech internetech nenasel ;)
stalo to sice vzdycky hodne usili (ani ne tak najit, jako ozkouset, zjistit jak moc to brzdi a vybrat nejlepsi), ale slo to.

takrka pisu proto, ze jsem nenasel nic, co by fungovalo jako google mapy. Mam mapu sestavenou z jednotlivych tileu a pri posuvu mapy bych chtel, aby se mi mapa posouvala s efektem pohybu nad mapou.

A pak taky nejsem spokojenej s nabidkou pozmenenych scrollbaru. A kdyz uz jsem nakej nasel, tak byl zas v konfliktu s cimsi jinym :D

A co pouzivam za pluginy? Cestu vypocitavam pomoci a* (musi se to pocitat pres javascript, php to pocita leta), na alty pouzivam wtooltip, na countery toto. Na progressbar pouzivam animate, na backpack draggable a droppable.

Dulezita je synchronizace, ale zas v ni neni zadna veda. Pouzivat co nejmene a nejlepe jen kdyz ocekavate odpoved ;)

na debugg pouzivam firebug a firephp, ktery vam krasne zobrazujou jednotlivy requesty. bohuzel taky zpomaujou beh prohlizece na 10%, ale clovek nemuze mit vsechno...

Kdyby vas neco zajimalo, ptejte se.