Hirdetés
- M.2 csatlakozók terén (is) jónak ígérkezik az MSI közelgő AMD-s alaplapja
- Kivégezheti a kisebb VGA-gyártókat az NVIDIA döntése
- Szinte a semmiből robbanna be az 1,4 nm-es eljárásával a Rapidus
- Félszáz terabájtos HDD-k előtt nyitotta ki az ajtót a Seagate
- Lassú lett a Windowsod? Ezeket kapcsold ki elsőnek!
- Apple asztali gépek
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- AMD Navi Radeon™ RX 9xxx sorozat
- VR topik (Oculus Rift, stb.)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Androidos fejegységek
- Miért nem tűnik el soha a kalózkodás?
- Drasztikusan lassíthatja a játékokat egyes VGA-kon a Windows 11 új frissítése
- Projektor topic
Ú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ésSzó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
- Új bontatlan és újracsomagolt laptopok bolti ár alatt,i3-i5,ryzen 5,számlával,garanciával
- MacSzerez.com - iPhone 15 / 128GB / Fekete szín / Apple Garancia!
- XPS 15 9570 15.6" FHD IPS i9-8950HK GTX 1050Ti 32GB 1TB NVMe ujjlolv új akku gar
- MacSzerez.com / iPhone 13 Mini / 128GB / Midnight / Kártyafüggetlen /Új akkumulátor! / Garancia!
- MacSzerez.com - iPhone 14 / 128GB / Fehér szín / Gyári új Akkumulátor! / Garancia!
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RX 9060 XT 8GB GAMER PC termékbeszámítással
- magyar billentyűzet - 171 - Lenovo Legion Pro 7 (16IAX10H) - Intel Core U9 275HX, RTX 5080
- GYÖNYÖRŰ iPhone 13 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3576, 100% Akkumulátor
- GYÖNYÖRŰ iPhone 12 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3195, 95% Akkumulátor
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: ATW Internet Kft.
Város: Budapest


