Keresés

Új hozzászólás Aktív témák

  • cucka

    addikt

    válasz Sk8erPeter #12993 üzenetére

    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.

  • Tele von Zsinór

    őstag

    válasz Sk8erPeter #12993 üzenetére

    maga az ellenőrzés miért lenne olyan nagy gond

    Szerintem itt erre gondolt: Pistike rángógörcsöt kap, és egymás után tizenhét alkalommal kattint valamelyik linkre. Az adott oldalon olvasni kell a manát, és ekkor történik a növelés szükségességének ellenőrzése is. A számos egyszerre bejövő processt ütemezi az OS, ebből három véletlenül így jön ki:

    - #1: aktuális érték olvasás
    - #2: aktuális érték olvasás
    - #3: aktuális érték olvasás
    - #3: ellenőrzés, növelés
    - #1: ellenőrzés, növelés
    - #2: ellenőrzés, növelés

    Szóval mivel az olvasás-ellenőrzés-növelés nem atomi művelet, simán válthat közben az OS (jó eséllyel fog is). Ha szerencsétlen mód úgy jön ki, mint fenn, akkor van három processed, ami mind növeli, szóval rögtön eltelt másfél órád néhány másodperc alatt. Ezt lehet mondjuk lockolással elkerülni, de nem triviális feladat. Sokkal egyszerűbb cronból, ütemezve írni, és csak ott.

    Persze ez a fenti helyzet egyszerűsítve van, sok függ a környezettől, szerverbeállításoktól, hogy használsz-e sessiont...

  • Soak

    veterán

    válasz Sk8erPeter #12993 üzenetére

    Az alapbol az, hogy linuxon a cron leggyakran 1 percenkent futhat le. (a konfigban a perc a legkisebb egyseg).

    A masiknal pedig en epp a System_Daemon php daemonrol beszeltem ami ad egy elfogadhato alapot php alapu daemonok gyartasahoz.

Új hozzászólás Aktív témák