Először is szögezzük le, hogy alapnak veszem, hogy egy játéknál nem oldal újratöltéssel oldjuk meg a kliensoldali frissítéseket, hanem ajax-al. Játékról van szó, tehát rengeteg request-el lehet számolni.

A dátum kiolvasása, összehasonlítása és az új mana érték beírása valóban nem erőforrás-igényes, viszont:
- Távolról sem nevezhető atomi műveletnek, tehát valamilyen lock-ot kell használj, ami viszont nagyon is erőforrás igényes. (Leginkább azért, mert az összes többi folyamat, ami ugyanazt az erőforrást használja, várni fog a lock miatt)
- Ahhoz, hogy a kliens nézőpontjából a mana érték frissítése úgy tűnjön, mint egy ütemezett feladat, minden egyes request-nél az összes játékos manáját ellenőrizni kell és frissíteni. Ez az összes olyan requset-re igaz, ahol a mana szerepel az adatok között. Felszorzod az ellenőrzés időigényét a játékosok magas számával, hozzáveszed, hogy elég sok request lesz, majd hozzáteszed, hogy minden egyes ellenőrzésnél lockolod az erőforrást, amire a többi request várni fog.

Az eredmény az lesz, hogy beraktál egy k*rvanagy aknát a forráskódodba, ami akkor fog robbanni, amikor a júzereid száma elkezd nőni. A rendszered szép egyenletesen fog skálázódni egészen addig, amíg a request-ek száma túl kicsi ahhoz, hogy a lock komoly fennakadást okozzon, efölött pedig hirtelen és drasztikusan fog lecsökkenni a teljesítménye.

Ja, és ezt az egész baromságot pusztán azért, mert valamilyen hülye okból kifolyólag nem vagy hajlandó arra, hogy az ütemezett feladatot a pontosan erre a célra kitalált feladatütemezővel futtasd. Most komolyan, ez miért éri meg bárkinek?

(#12997) oleslie
Miért kell túlbonyolítani cron-al, ami nem mindenhol elérhető?
A cron mindenhol elérhető. Linuxon, Unixon, OSX-en mind alapból ott van, Windows-on szintén, csak ott máshogy hívják.
Ahol nem elérhető a cron, azok a kétpálcás php webhosting megoldások, de hadd ne ez legyen a mérce.

[ Szerkesztve ]

Részben egyetértek veled akkor, ha a manát "globálisan" láthatóvá teszi a fejlesztő az oldalon. Tehát mondjuk meg lehet nézni a játékosok adatlapját és ott valós mana értéket szeretnél látni (persze itt is meg lehet kerülni a cron-t). Én így képzeltem el a játékát:

A belépett játékos csak a saját manájával van elfoglalva, csak azt látja, semmilyen körülmények között nem tudhatja, hogy mennyi manája van az ellenségnek vagy a többi játékosnak.
Így elég csak belépéskor ellenőrizni, hogy a legutóbbi manahasználat óta mennyi idő telt el, majd megjelenítés előtt megnövelni a mana értékét a kiszámolt mennyiséggel.
Minden manahasználatkor logolod annak az idejét. Minden manamegjelenéskor elvégzed a vizsgálatot, hogy mennyi idő telt el és mennyivel kell megnövelned a manádat (ez jól megírt játéknál ez nagyon egyszerűen kivitelezhető).

Ha lehet látni a másik manáját (mondjuk adatlapon keresztül), akkor is elég csak az adott (éppen nézett) játékos manáját vizsgálni és updatelni.

Szerintem ez lenne a leginkább erőforráshatékony megoldás, mert így egy, maximum kettő játékos manáját kell számolgatni. Főleg ha van sok tíz-százezer játékosod.

Persze a cron is jó dolog, abszolút nem vagyok ellene, én is használom napi szinten, de csak akkor, ha valóban indokolt. Ebben az esetben én nem tartanám annak (értsd, nem cron-nal csinálnám a fejlesztő helyében).

Rip and cut and mutilate the innocent, his friends, and again and again and on and on.

Én épp ezért írtam, hogy adatbázisba csak akkor írjunk ha a user csinált valamit. Addig csak meg kell jeleniteni, ezért nem kell lock, meg semmi, ezért irtam, hogy egy matematikai müvelettel megjelenitjük, utána meg ha esetleg varázsolt egyet akkor beírunk.

Szerk : Azért egy pontosabb sepcifikációt szivesen meghallgatnék, mert egyelőre 5-6an játszünk elméleti fizikust

[ Szerkesztve ]

Nem értem miért vagy igy rápörögve a lock-ra . Ugyan megint csak találgatok, de gondolom a játék nem úgy néz ki jellemzően, hogy 1 embert támad 50.000 . Innentől kezdve (még ha lock-olnánk is, de azzal eddig magyaráztam, nem kell) InnoDB motor row-level lock-nál miért olyan nagy probléma ha lockolunk egy sort? Ha még egyszerre 3-5 ember akarja elérni (nem értem hogy miért updatelné egyszerre 3-5, de ugye találgatunk csak) akkor se lenne dráma.

Az ütemezett feladatot feladatütemezővel futtatjuk, mert egyrészt pont erre találták ki, másrészt mert ez megkímél egy csomó jövőbeli problémától. Semmilyen komoly érv nem szól amellett, hogy ne így tegyük, különösen annak fényében, hogy az alkalmazáslogika lényegében ugyanaz bármilyen esetben. Ha gondoljátok, akkor fűrészelhetitek a fingot ebben a témában tovább, én kiszállok.

(#13004) oleslie
Egy valamire való hosting szolgáltatónál az ütemezett feladatok futtatása megoldható. Nyilván nem fogod megengedni a júzernek, hogy turkálja a crontab-ot, de vannak erre UI eszközök, vagy megoldhatja egyedi kérésre a rendszergazda, teljesen mindegy.
(És ha szar a kód és beakasztja a szervert, akkor teljesen mindegy, hogy az cron-ból futtatva vagy http request következményeként fogja beakasztani.)

Először is: nyugi, tudtommal egyelőre csak a lehetőségekről és miértekről beszélgetünk, és nem én akarom így vagy úgy megoldani, mert engem nem érint, hanem visszakérdeztem, hogy támaszd alá picit jobban, amit mondtál, mert érdekelt, de a hsz.-ed végére kissé behergelted magad.

"Először is szögezzük le, hogy alapnak veszem, hogy egy játéknál nem oldal újratöltéssel oldjuk meg a kliensoldali frissítéseket, hanem ajax-al."
Őő, ja, de ez nyilvánvaló, szerintem erről nem is érdemes témázni, mivel evidens.

Amit viszont én szögeznék le előre a félreértések elkerülése érdekében, mert fontos, hogy alapvetően én is jobbnak látom a cronos megoldást, valszeg én is azzal csinálnám, ha én lennék a fejlesztője, mivel ütemezett feladatra használjunk ütemezőt, végül is pont arra való. Tehát én nem a cron ellen beszélek, hanem érdekes témának láttam megvizsgálni a másik oldal lehetőségeit is, ha már felvetették a többiek, hogy meg lehetne oldani anélkül is, tehát azt is érdemes megbeszélni, hogy mi történne abban az esetben, ha NEM cronnal történne a dolog. Én pedig csak azokra a dolgokra reagálok/kérdezek rá, amik esetleg elsőre teljesen egzakt fogalmazás híján (számomra) kérdésesek lehetnek (vagy legalábbis engem érdekelnek). Oké?
Úghogy az "ezt az egész baromságot pusztán azért, mert valamilyen hülye okból kifolyólag nem vagy hajlandó arra, hogy az ütemezett feladatot a pontosan erre a célra kitalált feladatütemezővel futtasd" (kicsit behergelődött) mondatot nem vettem magamra, mert nem rám vonatkozik.

Lock-okra:
Igazából direkt előre kihangsúlyoztam, hogy elsősorban magára az ellenőrzésre kérdeztem rá, nem pedig az írási műveletekkel kapcsolatos aggályaidra, mert mint említettem vala, az még érthető is , de nekem úgy tűnt, hogy a lock-ok emlegetése kapcsán Te rátapadtál kőkeményen az írás-témára. De aztán utána meg simán az ellenőrzés-téma kapcsán is azt emlegetted, hogy a többiek várni fognak az erőforrásokra. Most szűkítsük le a kört simán arra, hogy kiolvasod az értéket ÉS az utsó módosítás dátumát, majd utóbbinál még egy összehasonlítást is végzel az aktuális dátummal, megnézed, amúgy mi a pálya, kéne-e frissíteni. Akkor itt még ne vegyük azt, hogy mi van, ha igen (akkor növelni kéne) - ebben az esetben ugye Te sem arra gondoltál, hogy írási művelet híján drasztikusan csökken a szerver teljesítménye nagy felhasználószám esetén?

Egyébként az ütemezett scriptben feltételezem, nem árt ellenőrizni, hogy a júzer épp online-e, mert ha offline, akkor gondolom nem kéne növelni a mannáját, szóval akkor a böngészőből való kilépés esetén küldeni kéne egy requestet a szerver felé, hogy na cső, akkor távoztam, azt meg beírni adatbázisba, hogy most már nincs szükség buzerálásra az adott júzernél.
Mondjuk jobb lenne ismerni jobban egy ilyen játék működését, én ilyeneket nem szoktam tolni (kinek van ilyenre ideje? ), úgy kicsit könnyebb lenne beszélni az elméleti lehetőségekről.

===

(#12995) Tele von Zsinór :
na ja, ez az ütemezős dolog jó példa, alapvetően ez így tök jogos. De tényleg jobban kéne ismerni egy ilyen játék működési elvét, mert konkrét implementációt nem tudok, csak sejtéseim vannak róla.

Sk8erPeter

Ezt a reakciót most nem egészen értettem, annyira nem nagy elvárás egy osztott tárhelyen sem, hogy legyen cron-futtatási lehetőség, manapság olcsó tárhelyeknél is jellemző, hogy be lehet állítani időzítetten lefuttatott scriptet pl. egy cPaneles felületen, pár kattintással.

(#12994) Soak :
jah, most esett le, hogy ezt mire mondtad, hogy 1 perc a legkisebb egység, OK, sorry, félreértettelek, igazából csak a lényeget néztem be, hogy cucka 30 másodpercet írt, nem pedig percet, pedig még idéztem is.
Lehetséges megoldás az egyszerűek közül.

[ Szerkesztve ]

Sk8erPeter

Jókat írsz, egy apróság kivételével: a manafrissítés tekinthető egy tranzakciónak, ami a következő elemekből áll:
- dátum kiolvasása
- dátum ellenőrzése/összehasonlítása
- mana frissítése, ha szükséges
A lock a tranzakció elején jön létre és a végén szűnik meg. Tehát írási művelet híján sem fogod tudni kikerülni a lock létrehozását és törlését, így a megoldásod overhead-je ígyis-úgyis a request-ek számával lesz arányban.

A lock természetesen akkor is szükséges, ha cront futtatsz, az előny abban áll, hogy az, hogy hányszor fut le a szkript egy konstans és nem függ semmilyen más külső tényezőtől (pl. a http requestek számától)

[ Szerkesztve ]

Remélem tudtok segítein. Van egy oldal, amiben a tartalomban span-ban, p-ben, divben, th,td,ben lévő szövegeket ki kell cserélem linkre. Ezt hogyan tudom megcsinálni. Most jelenleg preg_replace-t használok de img-ben meg a-ban is cserél aminek következtében szétesik az oldal a hibás html miatt

A phpstorm az elsőt biztosan tudja, úgy emlékszem, a másodikat is. Úgy nézem, a harmadikat is.

Van egy formom:
<form name="form" method="post" action="">
<select name="kaja">
<option value="alma">Alma</option>
<option value="szendvics">Szendvics</option>
<option value="csoki">Csoki</option>
</select>
<input type="submit" name="gomb" value="Küldés"/>
</form>
És azt szeretném, hogy a kiválasztott kaját illessze bele egy adatbázisba. Erre van egy PDO-s megoldás:
$q = $db->prepare("INSERT INTO etel (kaja) VALUES :kaja");
$q->execute(array(":kaja" => $_POST["kaja"]));
De valamiért nem rakja be a select-es adatokat, helyette csak egy 0-t látok az adatbázisban :/

:D Semmi :D

Szerintem Eclipse is képes ilyenre.

mobal,

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Miért van az, hogy a git megeszi a gépemet?
Kb ~5GB van az adott mappában, de a legtöbbet kihagyja, mert az nem kell a projektbe.
Kiadtam a git add ., git commit, git push origin parancsokat és így is van ~1800 fájl, amit tömörít.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Refactor → Rename nem módosítja akkor passzolom. Legjobb tudomásom szerint működnie kéne, vagy rosszul gondolom.

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

De honnan tudta, hogy hova tetted? Nem kell megadni az új mappa helyét?

Fastruktúrában mozgatást nem használtam még, egy-egy filet többször neveztem át Shift+F6-tal, akkor átírta, ahol az volt require()-ölve. Az átnevezős ablakban lehet pipálni, hogy nézze-e, hol van használva, nézd meg, ez hogy állt nálad.

Dave-11: az execute() hívásnál ne tegyél kettőspontot a placeholder neve elé.

Az mitől lehet, hogy a php mail függvény true értékkel tér vissza, de levelet nem küld mégsem?

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

[link] → "Returns TRUE if the mail was successfully accepted for delivery, FALSE otherwise." Ebből én azt veszem ki, hogy azt nem ellenőrzi, hogy sikeres volt-e a küldés.

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Mert a választ az SMTP szervertől kapod, az pedig 'átvette' küldésre. Azt nem ellenőrzi, hogy a cél létezik/elérhető/sikerült e a kézbesíteni. Ezt csak úgy tudod megoldani, ha saját SMTPD használsz php-ból.
Most korán van a böngészőelőzményekben való turkáláshoz.
Ha türelmetlen vagy, akkor gugli| php smtpd

update: ez sem megoldás minden esetre. Előfordul (az enyém is így működik), hogy ha a domain lézetik, 'átveszi' a levelet, attól függetlenül, hogy a fiók létezik e. HA nem sikerül, megpróbálja 3 óránként kézbesíteni. HA ez 24 óra alatt nem sikerül, akkor küldi a választ a @reply-to -ra vagy @from -ra, hogy a címzett nem létezik.

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

De a cél létezik biztosan, ennyiszer nem tudom elgépelni a saját mail címem.
Inkább lecseréltem a sima mail PHPmailer-re. Így már ki is küldte egyből a levelet.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

hüm ... az ölég érdekes.
Én a phpmailer-t cseréltem le a mail() -ra
Valamiért nem tudtam vele úgy levelet küldeni, hogy mindenhol (utf8 + webmail/kmail/kitekintő/etc.) helyesen jelenjen meg amit küldök (tárgy+tartalom), ill. ne érzékelje spam-nak.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Pedig van direkt ilyen property-je (CharSet). Én több szolgáltatónál is próbáltam már, mindnél jó volt a karakter kódolás.
A spam-re nem tudom mit írni, az elvileg mx válogatja, hogy spam lesz vagy sem.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Eddig is úgy dolgoztam, hogy az execute()-nál a placeholdernél ott volt a kettőspont. De most kipróbáltam nélküle, és ugyanaz az eredmény, a táblába 0-t rak be az option value-ja helyett :/

OMFG!!! De egy láma vagyok, a táblában nem varchar volt beállítva, hanem int

[ Szerkesztve ]

:D Semmi :D

Be lehet állítani valahol a netbeans-ben, hogy a tab helyett ne 4db space-t rakjon? Vagy ha enter-t ütök, akkor az új sorban tab legyen, ne space?

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Nem szolgáltatói oldalon volt a probléma, hanem a fogadónál. Azt, hogy jól van e összerakva a levél, ki tudom deríteni saját hatáskörben (saját rencer, exim, dovecot, spamassasin).
Kliensoldalon borultak meg a dolgok. Ha utf8 ban csináltam, a M$ levelezőit leszámítva mindenhol jó volt, ha win1250/latin2 -ben, akkor bár jó lett az M$-nek, cserébe baxakodott a többi. Ezt megunva ejtettem a phpmailer-t, és oldottam meg saját hatáskörben a problémát.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Hmmm, én próbáltam már tb-vel, outlook 2010-el, gmail-el, de nem volt még ilyen gondom.

A netbeans tab-ra már megtaláltam a megoldást. [link]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Options/Editor/Formatting -> Expand Tabs to Spaces

Nekem is volt ilyen tárhelyem, amcsiban, azért váltottam róla, mert messze volt, és megérződött. Amúgy tényleg azt raktál rá amit akartál, csak archiválást figyelték. Szóval azért 20gigás csomagolt fájlokat nem szerették De lehetetlen feltölteni, mert van havi adatforgalmi korlát, és abba fogsz beleütközni.

Mellé nem is olcsó: [link]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

De itt van forgalmi limit és tárhely limit is. A memória okés, hogy nagyobb.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Az oké, de akkor szerintem nem ilyen csomagot veszel (memória méretére gondolok elsősorban), ott meg már ugye többet is engednek.

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."