- Poco F3 - a mindenes, de nem mindenkinek
- Earfun Air Pro 3 - te is, fiam, Bluetooth?
- Mobil flották
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- iPhone topik
- OnePlus 8T – fazonigazítás
- Honor 90 - modellalkat
- Honor Magic5 Pro - kamerák bűvöletében
Hirdetés
-
Anime adaptációt kap a Guilty Gear Strive
gp Részleteket egyelőre nem kaptunk, a teljes leleplezsére jövő hónap elején kerül sor.
-
Z Fold6 imitátor árulkodik a fogyókúrázó igaziról
ma Több lesz kívül a változás, mint belül.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Ú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.[ Szerkesztve ]
Új hozzászólás Aktív témák
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- BestBuy topik
- Witcher topik
- Poco F3 - a mindenes, de nem mindenkinek
- Filmvilág
- Politika
- Milyen monitort vegyek?
- Elden Ring
- NVIDIA GeForce RTX 3060 Ti / 3070 / 3070 Ti (GA104)
- M0ng00se: Northwood vs Prescott + tuning: a tesztek
- További aktív témák...
- Iphone 12 64GB 91% akkumulátorral + Tokok
- Xbox series X+2kontroller+akku
- Samsung G9 Super Ultrawide Gamer monitor! 49"/5120x1440/240hz/1ms/G-sync-Freesync/HDR1000/Beszámítás
- ThinkPad 10.gen.core i5(8x4,2Ghz) FullHd IPS,Vil.bill.8GBDDR4,512GB SSD,Jó akku
- Slim Lenovo,15,6"HD,Intel Silver n5000,4mag!4x2,7Ghz,8GB DDR4 RAM,SSD,jó akku,jó állapot