Sokáig futó feladat kezelése
Sziasztok!
Van egy olyan feladványom, hogy webes felületen el kell indítani egy 0-600mp időt igénylő feldolgozást, majd a feldolgozás elkészültekor értesíteni a felhasználót, hogy lehetvturkálni az eredményben.
Ezt technikailag hogyan szokás megvalósítani?
Hogyan érdemes felosztani a munkát a kliens és a szerver közt?
Egy megkötésről biztosan tudok: webrtc nem elérhető a kétirányú kommunikációhoz. Az egyetlen amit sikerült működésre bírnom, a SSE, de nem látom, hogy erre itt szükség lenne.
Addig jutottam, hogy beesik a kliens a feladat "specifikációjával", mire a szerver elindít egy háttérprocesszt vagy egy új szálat.
És itt elakadtam, hogyan tovább?
Zaklassa a kliens x időnként a szervert, hogy lefutott-e?
Vagy valami long poll jellegű dologgal próbálkozzak, ami időnként timeoutra megy?
Vagy hogy? A dolog logikája érdekel, nem a konkrét megvalósítás.
■ Van egy olyan feladványom, hogy webes felületen el kell indítani egy 0-600mp időt igénylő feldolgozást, majd a feldolgozás elkészültekor értesíteni a felhasználót, hogy lehetvturkálni az eredményben.
Ezt technikailag hogyan szokás megvalósítani?
Hogyan érdemes felosztani a munkát a kliens és a szerver közt?
Egy megkötésről biztosan tudok: webrtc nem elérhető a kétirányú kommunikációhoz. Az egyetlen amit sikerült működésre bírnom, a SSE, de nem látom, hogy erre itt szükség lenne.
Addig jutottam, hogy beesik a kliens a feladat "specifikációjával", mire a szerver elindít egy háttérprocesszt vagy egy új szálat.
És itt elakadtam, hogyan tovább?
Zaklassa a kliens x időnként a szervert, hogy lefutott-e?
Vagy valami long poll jellegű dologgal próbálkozzak, ami időnként timeoutra megy?
Vagy hogy? A dolog logikája érdekel, nem a konkrét megvalósítás.
Bármi :)
- server sent events
- websocket
- long polling
- polling
Miért nem jó az SSE? Milyen logika érdekel?
SSE úgy éreztem, ágyú+veréb
Lehet, hogy túlgondoltam az egészet.
Már ott tartok, hogy scheduler/monitoring processz, feldolgozás a háttérben... valójában talán nem is így kellene, bár a long poll és SSE irányok feleslegesen tartanának nyitva tcp socketeket akár percekig is. Pár user mellett nem gond, de ha sok userem van, akkor már okozhat komoly problémát.
Aztán jut eszembe olyan, hogy ha elindult ez a hosszú procedúra, engedjem dolgozni a klienst, de akkor hogyan értesítem és küldöm vissza a félbehagyott műveletre? Vagy blokkoljam azt a tabot, amin beküldte a kérését?
Ilyesmi.
Push?
Most, hogy mondod, akár ez is
Csak az egész folyamatot nem látom magam előtt egyelőre, így meg már nehéz lesz tovább lépni.
A long polling alig terheli a
A feldolgozás eredményét flash message-dzsel érdemes megjeleníteni (google.com/search?q=browser+flash+message), nem kell blokkolni a tabot. Flash message-re máskor is szükség lehet, minden weblap megjelenítésébe érdemes beilleszteni, persze feltételesen (if szükségvanrá then legyenflash endif).
Ha a usernek lehetőséget kell adni a feldolgozás megszakítására? Authentikáció is kell? Stb. Vannak még alesetek, de a fentiek általában elegendőek.
Long polling esetében már nem
A http mögött működő tcp protokollról egészen nagy vonalakban annyit tudtam, hogy a kliens beküldi a kérést, ehhez nyílik egy-egy socket a szerver és a kliens oldalán, amin, mint egy csövön küldik egymásnak a kérés/válasz párokat.
Amíg kommunikálnak, addig ez a pár nyitva van.
A long pollingról meg úgy tudtam, hogy ezen a módon beküld egy kérést és várja rá a választ vagy a timeoutot, amire megismétli a kérést.
Ebből a kettőből melyik működik másképp?
Jelen feladványnál szerencsére se a megszakítással nem kell törődni, se az authentikációval. Csak annyi van, mintha egy lassan elérhető fájlt kellene lekérnie és amíg először betölt a cache-be, addig vár. Ha rájön, hogy mégsem kell, akkor fél-egy nap után úgyis törlődik amit begyűjtött.
Köszi!
szerver terhelése, long polling, auth
Tudtommal így működnek. De ha vizsgáznom kellene, előtte utána olvasnék...
A szervert leginkább az 0-600 s közötti feldolgozás terheli majd. Ha egyre újabb kérések érkeznek, akkor mindenféle gond lehet ebből. Állítsd sorba a lekérdezéseket.
Aztán ezt is lehet pimpelni priorizálással, a várható válaszidő előrejelzésével, a sor megteléséhez közeli állapot esetén elutasítással vagy böngészőoldali várakoztatással stb.
Továbbá a webszerver és az alkalmazásszerver (AS) le is állhat rövidebb-hosszabb időre, ezért a feldolgozást mindenképp tőlük független szerveroldali háttérprocesszre (BP) bízd. Meg kell tervezni az AS és a BP közötti kommunikációt is, praktikusan kis állapotgépre bízva.
Authentikáció mindenképp kell, ha nem csak elméleti a feladat. Tudnod kell, kinek küldd vissza a következő feldolgozás éppen elkészült eredményét.
Elméletileg közel azonos
Egyébként a terv, hogy backgroundból egy fut, a többi vár a sorára.
Nem egy létfontosságú szolgáltatás, ha kidöglik, majd magához tér alapon is simán elmegy. Egyfajta kereső motor lesz, ha lesz, de szűk rétegigények kielégítésére, konkrét adatokban turkálásra, ezért nem kell authentikáció. Publikus adatok, elvben a google is megtalálja, csak nehézkes.
Kicsit oszlatom a homályt
Egy kisebb társaságnak akartam karácsonyi meglepit, de úgy sejtem, legalább egyikük ide is be szokott nézni és nem akartam lelőni a poént.
Már tárgytalan, nem akarok a továbbiakban érdemben szóbaállni sem velük, úgyhogy itt le is zártam az ügyet.
Maga a feladat: az említett társaság oldala disqus alapú kommentekkel működik. A disqus-nak legendásan szar a keresője vagy csak én nem láttam embert, aki tudná, hogy egy adott témához tartozó kommentek közt hogyan lehet keresni. És miután van náluk egy konkrét téma, ami naponta többezer kommentet generál, párszor felmerült az igény, hogy jó lenne keresni benne.
A feladvány, amit meg akartam oldani, az egy disqus-ra írt kereső lett volna, persze elég komoly megkötésekkel.
Mivel fizetős szolgáltatás nem jöhet szóba, együtt kell élnem az ingyenesek korlátaival. Pl. a disqus óránként max. 1000 lekérdezést enged, emiatt mindenképpen kell cache (meg döglassú is :) )
Szerverként a pythonanywhere volt kiszemelve, mert onnan elérem a disqust, ingyen tudok futtatni saját programot, viszont ennek is van sok korlátja, többek közt ezért aggódtam a nyitva tartott tcp kapcsolatok miatt.
Persze nem lett volna tökéletes, mivel az utólag módosított kommenteket nem lehet lekérni, így ha letöltöttem egy állapotot, az azt követően keletkezett kommenteket le tudom húzni, de a módosítottak maradnak, míg nem jár le a tárolásra szánt idő és töltöm ke újra az egészet.
Volt még bennem olyan hátsó szándék hogy mivel ez nem fórumspecifikus, bármilyen disqus alapú oldal userei használhatnák, de őszintén szólva nem tudok olyan helyről, ahol pár oldalnál több komment tartozna egy cikkhez/poszthoz, így gyakorlatilag a dolog értelmét vesztette. Max. a saját szórakoztatásomra fogom elkészíteni.
:)
C'est la vie - ahogy a művelt
Jobb lett volna, ha nem jövök rá sokadjára, hogy ... :(