CYBERWOLF: z casti uz to tu probehlo, ale stejne to napisu

cim vic logiky das do db tim lepe, uz jen protoze neresis zpozdeni na presunu dat php-db-php-db-php-db .... ale je to php-dblogika-dbdata-dblogika-php

pokud musis zustat u mysql (nad 60k zaznamu v tabulce hrozne zpomaluje a pak resis UNIONy, s logikou tam toho moc neudekas) tak jedine cim budes moci ladit rychlost jsou indexy nad tabulkama (je pravda ze tam toho jde udelat hodne, z vlastni zkusenosti spojenim 3 indexu do jednoho zkraceni z 45sec na 3sec)

php je pomale, ale pokud pouzivas objekty, je extremne pomale; objekty jsou v php silena nadstavba ... kterou pridali, aby byly vice cool, jenze uz z povahy jazyka (interpretovany) je to silena konina hlavne pri zahazovani veskere prace ihned po zobrazeni stranky

pokud nejvic casu zabiraji operace s textem/cisly zkus se zamyslet nad perlovy scriptiky, ktery bys z php volal, posun v rychlosti by byl dost extremni

Napr. ja tam mam pohyb reprezentovany mapou sveta, rozdelenou do sektoru, ktere odpovidaji zemepisne delce a sirce. Pokud chci cestovat z bodu A do bodu B, tak vypocitam trasu, zjistim, jestli se danou trasou da projit (treba ze tam zrovna neni more) a jak dlouho bude cesta trvat (poledniky se se vzdalenosti od rovniku vzajeme priblizuji). Byl docela masakr tohle udelat i v php, jak bych to delal na urovni SQL, to si neumim predstavit...

PHP je pomale, protoze se pri kazdem spusteni kod nejdrive zkontroluje, zkompiluje a pak teprve pusti. Ovsem s pouzitm napr. eAcceleratoru prvni dva kroky odpadaji :)

Nevim, jak jsou na tom jine databazove systemy, ale s MySQL muzu jen tezko vytvorit celou logiku na databazove urovni tak, aby se s tim dalo rozume pracovat a tady je holt treba se rozhodnout, jestli radsi obetovat rychlost nebo prehlednost a udrzovatelnost.

No a pokud se neukaze, ze neco vyslovene nejde, protoze je to pomaly, tak uprednostnuji prehlednost a udrzovatelnost:)

PHP je hrozne pomale, osobne ho pouzivam jen na osetreni vstupu a na vystup sablon.
Mit celou logiku uvnitr db je jednoznacne plus.


CYBERWOLF: Vzhledem k tomu, ze budu mit 3x delsi tahy nez ty, tech objektu tam vic jak 100k nebude a stroj, na kterem jsem to merila byla pouze pomala p3, tak se toho nebojim :)
A i kdyby se to stalo, tak od toho jsou pak priority. Nektere veci se proste vykonat nemusi.

Jinak optimalizaci bych resila uz na zacatku. Uvedu konkretni priklad. Mam 100 000 clovicku (cti radku v db) a kazdy z nich starne, tzn. kazdy tah je update. Update byl radove 30-60s (IIRC, mozna vic). Tak jsem to udelala tak, ze se nastavi pouze tah narozeni clovicka a dal se vek pocita jako aktualni tah-tah narozeni. Zadny update, zadny insert a kontrola starnuti byla za 200ms hotova :) A s takovou veci musis pocitat uz od zacatku, jinak to budes muset zpetne prepracovat a to neni zrovna zabavne :)

MICTECH: Tak tohle jsou veci, co se vzajeme nevylucuji:) Dotazy pisu rucne, ale prohanim skrz knihovnu (dibi) a pokud prijdu na pripad, kdy to bude vyhodne, budu resit ulozene procedury.

CYBERWOLF: tohle neni moc o optimalizaci, tohle by jsi mel resit pri navrhu, jakym zpusobem bude resena DB vrstva

jestli si budes psat vsechny SQL rucne, pouzijes nejakou DB knihovnu v php nebo treba budes pouzivat mnou zmineny procedury a jen je volat s danyma parametrama

No, zatim bych to s tou optimalizaci moc neprehanel. Je tam toho jeste dost, co by se dalo poladit a ted to bezi pomerne snesitelne, takze jeste je kde to zrychlit a predcasna optimalizace je zdrojem vseho zla:)

WEWERKA: Tak z toho, co tu pises, bych mel docela hruzu:) Nekonecny cyklus, ktery si to dela jak mu to zrovna jde... Co kdyz toho bude proste moc a pretece to do dalsiho tahu?

CYBERWOLF: pokud chces usetrit komunikaci mezi php a db, tak to udelej pres storovane procedury

CHARLEZ: drtivou vetsinu databaze. Puvodne jsem k tomu pristupoval tak, ze kazdy ukol je samostatny objekt se svymy metodami atd., takze jsem pro kazdy zvlast navysoval casy atd. takze pocet dotazu na DB narustal dost strme a s tim i cas co si vzala komunikace mezi PHP a databazi. Rikal jsem si, jak to bude narame prehledne, atomicke, snadno udrzovatelne...no ale cena ztraty vykonu byla prilis vysoka.

Ted jsem to vyresil tak, ze navysovani tahu dela jeden dotaz, pak si vyberu jen ty ukoncene ukoly, z nich udelam objekty a provedu ukonceni a pripadne aktivaci dalsiho ukolu (v PHP).

Zpracovani pouze pres php je cesta do pekel :( Po predchozich zkusenostech mam veskerou logiku v db (pgsql).

CYBERWOLF: vetsinu toho casu ti zpracovava databaze nebo je to zpracovani na urovni php?

CYBERWOLF: Taky jsem se potykala s timhle problemem :) Na zkusebni databazi jsem si vytvorila okolo 100 000 objektu, ktere delaji ruzne ukoly. Napr. starnou, pracuji, ji atd atd. a postupne jsem to zoptimalizovala tzn. inserty misto updatu, cachovani vseho mozneho atd. No a nakonec to bude tak, ze ta urcita akce se vykona v prubehu celeho tahu. Nebudu vedet kdy presne, ale nekdy se vykona. V podstate hrac bude mit moznost treba do pulky tahu jeste zmenit co se ma stat, jen protoze objekt se jeste neoznacil jako zpracovany.

Takze proc by se treba tovarna nemohla dostavet uprostred tahu.

S cronem urcite pocitej. Ja si to napsala tak, abych neblokovala transakce, takze se to pousti porad za sebou a vybira si prednostne typy akci, ktere se maji provest. Udela vzdy par veci a jde na dalsi cyklus (nekonecny cyklus, cron je tam jen pro jistotu).

Tak jsem to udelal tak, ze se po urcitem casovem useku (tedy asi tech 10 min) pusti UPDATE na databazi, ktery vsechny aktivni ukoly posune o jeden tah. Potom vyberu vsechny aktivni ukoly, ktere maji naplneny pozadovany pocet tahu a ukoncim je.

Co se tyka ukoncovani ukolu, tak to probiha zhruba stejne dlouho, jako predtim probihal kazdy tah (spis se to blizi k 12 vterinam, ale je to zhruba stejne). Pouhe navyseni tahu trvalo necelych 0.1 sec, takze ve vetsine pripadu se jedna o usporu 99% casu (zrychleni o vice nez 10 000% zni jeste lip :))

TOMG: Proc stahovat kalhoty, kdyz brod je jeste daleko? Nejdriv udelam hru, pak forum a az se zacnou mnozit spameri, tak budu hledat adminy (nebo lepe receno mazace) :)

CYBERWOLF: Pocitam, ze hra bude potrebovat i forum a tudiz nekdo to tam bude muset umravnovat. Ale forum tam mit nemusis ze.

TOMG: Tak s optimalizacemi mam celkem dobre zkusenosti, jeden cas jsem delal na projektu, ktery ve spicce delal 15000 hitu za vterinu (samozrejme jsem na tom nedelal sam, bezelo to na farme atd, ale stejne jsem se naucil docela dost, jak co udelat maximalne efektivni).

Co se tyka adminu, tak nejak mam pocit, ze nejsou tak moc potreba. Na multilogy se da udelat skript, ktery vetsinu z nich odhali, na dotazy hracu si odpovi sami mezi sebou no a jinak, co s adminy?

CYBERWOLF: No i stovka hracu = potreba mit tam nejake adminy na dohled, ale zase je fakt, ze jsou lidi co za virtualni pocit moci ve hre makaji zadarmo :) U tisicu me fakt zajima jak to budes optimalizovat :)

TOMG: S freehostingem nepocitam, nechtel bych aby mi to za tejden stopli:) Mam vyhlednuty hosting, ktery obsahuje vsechno co potrebuji a vim, ze pokud cokoliv nebude stacit, tak mi to poskytovatel za primereny poplatek navysi, takze neni problem. Vim, ze nic jako neomezeny hosting neexistuje:)

Co se tyka poctu hracu - cim vic, tim lip:) Pocital bych tak radove stovky, kdyby to lezlo do tisicu, tak uz bych si na treba mohl zaridit i zivnost...

Dalsi vec je, ze to samotne provadeni tahu neni ani tak moc vypocetne narocne, protoze vetsinou se jen nastavi pocitadlo hotovych tahu u toho ktereho ukolu a jenom kdyz se naplni pozadovana kvota, tak se teprve ukonci. Problem je v tom, ze je jich hodne.

Ale dostal jsem napad, jak tohle trochu zjednodusit, tak vyzkousim a uvidime:)

Na free hostingu budeš rád, když tam budeš mít možnost CRONu co minutu a limit na trvání skriptu. Velice brzo zjistíš, že ty různé sliby, že nejsou limity, nejsou tak úplně pravda v okamžiku, kdy některý z jejich limitů překročíš. Ti slušnější tě na to upozorní, před tím, než ti to sestřelí.