Težave z dolgim ​​anketiranjem v JavaScriptu in kako jih rešiti

Domov » Python » Težave z dolgim ​​anketiranjem v JavaScriptu in kako jih rešiti

Dolgo anketiranje v JavaScriptu je videti varljivo preprosto: zahteva HTTP naj bo odprta, dokler strežnik nima kaj povedati, nato pa vrnite podatke in takoj odprite novo zahtevo. Od zunaj se zdi skoraj kot komunikacija v realnem času, zato ni presenetljivo, da se aplikacije za klepet, nadzorne plošče, igre in sistemi za obveščanje že leta zanašajo nanjo. Toda pod pokrovom se skrivajo subtilne pasti delovanja, skalabilnosti in zanesljivosti, ki se pojavijo takoj, ko vaša aplikacija preseže peščico uporabnikov.

Razumevanje resničnih težav dolgega anketiranja v JavaScriptu pomeni preseči osnovni opis »odjemalec pošlje zahtevo, strežnik čaka, strežnik odgovori« in si ogledati semantiko HTTP, omejitve brskalnika, posredniške strežnike, časovne omejitve in alternative, kot so WebSockets, pretakanje HTTP in dogodki, poslani s strežnika. V tem priročniku bomo podrobno preučili, kako dolgo deluje anketiranje, katere težave so odkrili IETF in glavni prodajalci ter kako se odločiti, kdaj ga uporabiti, kdaj ga optimizirati in kdaj ga v celoti zamenjati.

Kaj pravzaprav je dolgo anketiranje v JavaScriptu

Preprosto povedano, dolgo anketiranje je vzorec, zgrajen na običajnem HTTP-ju, kjer brskalnik pošlje zahtevo, strežnik pa namerno odloži odgovor, dokler niso na voljo novi podatki ali dokler ne poteče časovna omejitev. Takoj ko brskalnik prejme odgovor, obdela podatke in takoj sproži novo zahtevo, pri čemer povezava ostane »skoraj vedno« v teku.

Ta tok se zelo razlikuje od klasičnega kratkega anketiranja, kjer odjemalec v določenem intervalu sprašuje strežnik »je kaj novega?«, ne glede na to, ali so na voljo posodobitve. Pri dolgem anketiranju strežnik med obdobji neaktivnosti ohrani zahtevo odprto, zato odjemalcu ni treba večkrat pošiljati praznih anket, ko se ni nič spremenilo.

Tipična dolga zanka anketiranja v JavaScriptu je videti kot rekurzivna funkcija naročnine, ki pokliče fetch (ali XMLHttpRequest), čaka na odgovor, obravnava koristni tovor in nato ponovno pokliče samo sebe. Če se omrežje prekine ali pride do napake, koda poskusi znova takoj ali po kratki zakasnitvi in ​​poskuša čim dlje ohraniti čakajočo povezavo.

Ta pristop deluje še posebej dobro, kadar so sporočila relativno redka, saj čas mirovanja povezave ne povzroča omrežnega prometa ali obremenitve procesorja, ki bi presegla stroške ohranjanja odprte vtičnice. Uporabnik ima skoraj takojšnje posodobitve, strežnik pa se izogne ​​​​nenehnemu bombardiranju z anketiranjem.

Vendar pa takoj, ko dogodki postanejo pogosti, vsak dogodek običajno sproži celoten cikel odziva HTTP – statusno vrstico, glave, preverjanje pristnosti, telo – zato se lahko stroški na sporočilo močno povečajo in vzorec prometa začne izgledati kot žagast porast zahtev/odgovorov. Tu se v resničnih aplikacijah začnejo pojavljati težave s skaliranjem in dodatnimi stroški.

Kratko anketiranje v primerjavi z dolgim ​​anketiranjem v primerjavi s pretakanjem

Za resnično razumevanje problematike je koristno primerjati dolge ankete s kratkimi anketami in pretakanjem HTTP, saj so vsi trije načini za lažno "vsiljevanje" prek protokola zahteve/odziva, kot je HTTP.

Kratko anketiranje je naivna različica: odjemalec periodično pošilja zahteve HTTP (na primer vsakih 5–10 sekund), strežnik pa takoj odgovori z vsemi sporočili, ki so prispela od zadnjega anketiranja. Če ni ničesar na voljo, strežnik še vedno odgovori, pogosto s praznim koristnim tovorom, odjemalec pa preprosto počaka do naslednjega intervala.

Ta model ima dve očitni slabosti: zakasnitev sporočil je lahko tako visoka kot interval anketiranja, strežnik pa je prisiljen obravnavati ponavljajoče se zahteve, tudi če ni novih podatkov. Za majhne sisteme ali sisteme z nizkim prometom je to morda sprejemljivo, vendar v velikem obsegu zapravlja procesorske cikle, omrežno pasovno širino in lahko povzroči opazne zamude za uporabnike.

Dolgo anketiranje to izboljša tako, da strežniku omogoči, da vsako zahtevo »zadrži odprto«, dokler se ne zgodi nekaj zanimivega – dogodek za dostavo ali prag časovne omejitve. Zakasnitev za nova sporočila je zdaj blizu eni omrežni poti nazaj, prazni odgovori pa se pojavljajo veliko manj pogosto, kar zmanjšuje izgubljeni promet.

Pretočno pretakanje HTTP gre še korak dlje, saj odgovora sploh ne zapre: strežnik pošlje en odgovor HTTP in nato prek iste povezave pretaka več delov podatkov, ločenih z okvirjanjem na ravni aplikacije. Odjemalec bere tok postopoma, namesto da čaka, da se celoten odgovor konča.

V HTTP/1.1 se to običajno izvaja s kodiranjem prenosa v blokih, kjer strežnik nastavi Transfer-Encoding: chunked in nato vsak del podatkov pošlje kot ločen blok z lastno dolžino glave. V nastavitvah sloga HTTP/1.0 je pretakanje mogoče doseči tudi z izpuščanjem Content-Length in uporabo connection close kot označevalnika konca toka.

Ključna razlika je v tem, da dolgo anketiranje zaključi odgovor po vsakem sporočilu in sili novo zahtevo za naslednji dogodek, medtem ko pretakanje ohranja isti odgovor aktiven in potiska sporočila, ko se pojavijo. To ima velike posledice za zakasnitev, porabo pomnilnika, posrednike in način oblikovanja sporočil na aplikacijski plasti.

Kako deluje dolgo anketiranje HTTP pod pokrovom

Z vidika protokola HTTP dolgo anketiranje ne uvaja nobenih novih metod ali statusnih kod; le razširja običajno semantiko zahteve, ki čaka na odgovor. Analiza »dvosmernega HTTP«, ki jo je izvedla organizacija IETF, jasno kaže, da je dolgo anketiranje še vedno veljavno za HTTP 1.0/1.1, vendar model potiska blizu svojih meja.

Osnovni življenjski cikel dolge interakcije anketiranja je videti takole: odjemalec pošlje začetno zahtevo in jo začasno ustavi, strežnik odloži odgovor, dokler se ne zgodi dogodek, sprememba stanja ali časovna omejitev, nato strežnik vrne celoten odgovor HTTP (pogosto 200 OK) s podatki o dogodku in na koncu odjemalec hitro izda novo zahtevo.

Ta vzorec se lahko izvaja prek trajnih ali netrajnih povezav HTTP; s trajnimi povezavami se izognete stroškom ponavljajočih se rokovanj TCP tako, da ponovno uporabite isto vtičnico za več dolgih anket. V praksi je ohranjanje iste TCP povezave skoraj vedno boljše za boljšo zmogljivost.

Strežniki, ki izvajajo dolgo anketiranje, morajo običajno upravljati dva vedra virov na odjemalca: samo TCP povezavo in čakajočo zahtevo HTTP v čakalni vrsti ali zanki dogodkov. Operacijski sistemi običajno lahko učinkovito obdelajo veliko število odprtih vtičnic, vendar nekateri strežniki ali prehodi HTTP dodelijo veliko pomnilnika na zahtevo, kar lahko postane pravo ozko grlo.

Zanimiva lastnost dolgega anketiranja je, da se pri veliki obremenitvi nagiba k elegantnemu poslabšanju s povečanjem latence, namesto da bi močno odpovedal. Če je strežnik počasen, se sporočila, namenjena odjemalcu, postavijo v vrsto, dokler ni mogoče poslati odgovora; več dogodkov v čakalni vrsti se lahko celo združi v en sam dolg odgovor na anketo, kar mimogrede zmanjša stroške na sporočilo.

Težave in omejitve dolgega anketiranja

Čeprav se v praksi pogosto uporablja in je standardizirano, dolgo anketiranje uvaja več znanih tehničnih težav, ki jih je v JavaScriptu enostavno odpraviti, če niste previdni. Te težave se kažejo v uporabi pasovne širine, zakasnitvi, upravljanju povezav in vedenju posrednikov, kot so proxyji in predpomnilniki.

Stroški glave so prvi strošek, s katerim se srečujete: vsaka dolga zahteva in odgovor na anketo je celotno sporočilo HTTP, običajno s piškotki, glavami za avtorizacijo in drugimi metapodatki, ki lahko zasenčijo dejanski koristni tovor. Za majhna, redka sporočila so ti dodatni stroški morda sprejemljivi, vendar lahko v scenarijih obračunavanja na podlagi količine ali v omrežjih z omejeno pasovno širino razlika med velikostjo glave in velikostjo koristnega tovora postane draga.

Največja latenca je še ena subtilna težava: medtem ko je povprečna latenca dolgega anketiranja za nove dogodke približno en omrežni tranzit, je lahko v najslabšem primeru zamuda več kot tri tranzite. Če sporočilo prispe takoj zatem, ko je strežnik poslal odgovor, mora strežnik počakati na naslednjo zahtevo odjemalca, preden lahko dostavi to sporočilo, izguba ali ponovni prenos TCP paketov pa lahko ta čas še podaljša.

Vzpostavljanje povezave se pogosto pojavlja kot zaskrbljenost, zlasti ko ljudje primerjajo dolgo anketiranje z WebSockets. Če bi vsak dolg odgovor na anketo povzročil zaprtje povezave HTTP (in osnovne povezave TCP), bi bili stroški ponavljajočega se odpiranja vtičnic ogromni. Na srečo je dolgo anketiranje mogoče in bi moralo biti narejeno na vrhu trajnih povezav, tako da se kratek premor med odgovori ne razlaga kot nedejavnost; to omogoča, da transport ostane odprt in ga je mogoče ponovno uporabiti.

Dodeljevanje virov strežnika in proxyja je velika praktična omejitev: vsaka čakajoča zahteva porabi pomnilnik in morda nit ali delavca v sinhronih arhitekturah. Mnogi starejši ali blokirajoči strežniki preprosto ne zmorejo več deset tisoč sočasnih dolgih anket, ker njihov model sočasnosti pričakuje, da se bo vsaka zahteva hitro zaključila; za te sisteme je asinhroni V/I ali zasnova, ki jo poganjajo dogodki, skoraj obvezna.

Predpomnjenje lahko prekine tudi dolgo anketiranje, če ni izrecno zatrto. Vmesni predpomnilniki se lahko odločijo za ponovno uporabo ali shranjevanje odgovorov, razen če dolge zahteve in odgovore na ankete jasno označite s Cache-Control: no-cache (in povezanimi glavami), s čimer zagotovite, da vsaka zahteva dejansko doseže izvorni strežnik in da se ji ne posredujejo zastareli podatki.

Časovne omejitve, posredniki in vedenje posrednikov

Ena najbolj nadležnih težav v resničnem svetu z dolgim ​​​​polniranjem v JavaScriptu je, da nimate popolnega nadzora nad omrežjem med brskalnikom in strežnikom. Proxyji, prehodi, uravnalniki obremenitve in celo privzete nastavitve brskalnika vsiljujejo časovne omejitve ali strategije medpomnjenja, ki lahko prekinejo iluzijo žive povezave.

Dolge zahteve za ankete naj bi ostale odprte do dogodka ali časovne omejitve, ki jo nadzirate, vendar v resnici mnogi posredniki prekinejo povezave po krajšem, določenem obdobju. Čeprav brskalniki privzeto dovoljujejo do približno 300 sekund, nekateri posredniki uveljavljajo veliko krajše časovne omejitve, kar pomeni, da se bo vaša dolga anketa končala s HTTP 504 Gateway Timeout ali samo s ponastavitvijo, zaradi česar se bo odjemalec moral pogosteje ponovno povezati, kot ste nameravali.

Poskusi in operativne izkušnje kažejo, da so časovne omejitve okoli 30 sekund v mnogih okoljih varnejši kompromis, medtem ko 120 sekund pogosto deluje, vendar je bolj krhko. Proizvajalci omrežne opreme, ki želijo biti prijazni do dolgih anket, naj uporabljajo časovne omejitve, ki so bistveno daljše od tipičnih časov prenosa v srednjem omrežju, da se legitimne dolge ankete ne bi prezgodaj uničile.

Obratni posredniki in združevanje povezav uvajajo še en razred težav. Nekatere nastavitve proxyja si delijo majhen nabor povezav navzgor med številnimi odjemalci; če dolge ankete zasedajo te skupne povezave dlje časa, se lahko druge zahteve zadržijo ali postavijo v vrsto za njimi, kar spodkopava delovanje celotnega spletnega mesta.

Pri pretakanju HTTP je vmesno medpomnjenje še večje tveganje, saj lahko posredniki medpomnijo delne odgovore in posredujejo podatke šele, ko zberejo celoten odgovor. V tem primeru lahko pretočni strežnik, ki pošilja majhne dele JavaScripta in pričakuje takojšnjo izvedbo v brskalniku, ugotovi, da posrednik hrani vse, dokler se povezava ne konča, kar popolnoma uniči delovanje v realnem času.

Omejitve brskalnika in število povezav

V JavaScriptu nikoli ne morete neposredno upravljati TCP povezav; vidite le visokonivojske konstrukcije, kot sta fetch ali XMLHttpRequest, vendar brskalniki uveljavljajo omejitve glede števila vzporednih povezav, ki jih je mogoče odpreti z istim gostiteljem. Zgodovinsko gledano je bila ta omejitev dve povezavi na izvor, zaradi česar so bile tehnike v slogu Comet še posebej zapletene.

Sodobni brskalniki so te omejitve omilili na približno šest ali osem povezav na gostitelja, vendar JavaScript še vedno ne ponuja standardnega načina za vprašanje »koliko povezav je še ostalo?« ali za usklajevanje uporabe med zavihki in okvirji iframe. Vsak zavihek lahko neodvisno sproži svojo dolgo anketo, kar hitro izčrpa razpoložljive reže in blokira druge bistvene zahteve, kot so CSS, slike ali klici API-ja.

Najboljša praksa na strani strežnika je uporaba piškotkov ali nekega mehanizma korelacije za zaznavanje več dolgih anket, ki prihajajo iz istega primerka brskalnika, in preprečevanje odlaganja vseh. S hitrim odzivanjem na izjemno dolge ankete in zares obešanjem le ene ali majhnega števila lahko zmanjšate tveganje za pomanjkanje povezave ali motnje v cevovodu.

Nekateri protokoli višje ravni, zgrajeni na dolgem anketiranju, kot sta Bayeux in BOSH, so izrecno zasnovani okoli omejitev povezave brskalnika. Pogosto hkrati uporabijo največ dve odprti zahtevi HTTP in se izogibajo zanašanju na cevovod HTTP, ki je slabo podprt in ga ni mogoče nadzorovati iz JavaScripta.

HTTP cevovod, uokvirjanje in urejanje sporočil

Čeprav bi HTTP pipeline (pošiljanje več zahtev zaporedoma po isti povezavi pred prejemom odgovorov) teoretično lahko zmanjšal dolgo zakasnitev anketiranja, je v praksi krhek in nedosledno implementiran. RFC 2616 je previden glede cevovoda, zlasti za zahteve POST, posredniki ali odjemalci pa ga lahko v celoti onemogočijo.

Protokoli, ki poskušajo izkoristiti cevovodno obdelavo za dolgo anketiranje, morajo najprej zaznati, ali je cevovodna obdelava zanesljivo podprta od začetka do konca; če ni, se vrnejo na konzervativno, necevovodno vedenje. V okolju JavaScript v brskalniku nimate kavljev za upravljanje tega, zato večina dolgih anketnih skladov, ki temeljijo na JavaScriptu, preprosto predpostavlja, da cevovod ni na voljo.

Uokvirjanje – način, kako razdelite neprekinjen tok bajtov na ločena sporočila aplikacije – je še ena subtilna razlika med dolgim ​​​​poliranjem in pretakanjem HTTP. Pri dolgem anketiranju vsak HTTP odgovor naravno vsebuje natanko eno sporočilo ali serijo sporočil, zato je vaše uokvirjanje implicitno: en odgovor je enak enemu kosu pomembnih podatkov.

Pri pretakanju se ne morete zanašati na meje blokov HTTP kot okvirjanje aplikacije, ker lahko posredniki ponovno razdelijo podatkovni tok, združijo bloke ali jih razdelijo na različne načine. To pomeni, da mora aplikacija v koristni tovor vdelati lastne ločilnike ali predpone dolžine in jih ustrezno razčleniti na odjemalcu.

Dolgo anketiranje samo po sebi ne zagotavlja vrstnega reda in zanesljivosti sporočil; odvisna sta od protokola aplikacije in plasti shranjevanja. Če odjemalec prekine in ponovno vzpostavi povezavo sredi toka, potrebujete eksplicitne mehanizme (kot so zaporedne številke ali ID-ji zadnjih dogodkov), da zagotovite, da se sporočila ne izgubijo ali dostavijo v napačnem vrstnem redu.

Varnostni vidiki za dolgo anketiranje v JavaScriptu

Dolgo anketiranje kot tehnika ne spremeni osnovnega varnostnega modela HTTP, vendar lahko način, kako se pogosto izvaja – zlasti v brskalnikih, ki uporabljajo JavaScript – odpre vrata dodatnim tveganjem.

Številne rešitve za dolge ankete med domenami se zanašajo na izvajanje JavaScripta, ki ga vrne strežnik, včasih prek povratnih klicev v slogu JSONP ali drugega dinamičnega vbrizgavanja skriptov. Če je vaš strežnik ranljiv za napade z vbrizgavanjem, lahko napadalec v te odgovore vtihotapi poljubno kodo, ki jo brskalnik nato zažene s privilegiji strani.

Uporaba HTTPS povsod je neizogibna: šifriranje prenosa ščiti pred vdori in prisluškovanjem dolgotrajnim povezavam s strani vmesnega človeka. V kombinaciji z robustnim preverjanjem pristnosti in avtorizacijo (na primer preverjanje pristnosti na podlagi žetonov in nadzor dostopa na podlagi vlog) lahko dolge končne točke anketiranja omejite na predvidene odjemalce.

Ker dolgo anketiranje ohranja številne povezave odprte dlje časa, lahko napade DoS naredi bolj privlačne: napadalec lahko poskuša izčrpati strežniške vire z odpiranjem številnih lažnih dolgih anket. Omejevanje hitrosti, kvote povezav na IP ali žeton in razumne časovne omejitve so bistveni obrambni ukrepi.

Grožnje, specifične za brskalnik, kot je CSRF, so običajno manj pomembne za čiste ankete XHR/fetch, ki se ne zanašajo na piškotke okolja, če pa so vključeni piškotki, morate te končne točke še vedno obravnavati kot kateri koli drug občutljiv API. Piškotki SameSite, žetoni CSRF, kjer je to primerno, in strogi pravilniki CORS so del utrjene nastavitve.

Dolgo anketiranje v primerjavi z WebSockets in dogodki, poslanimi s strežnika

Z vidika razvijalca JavaScripta so dolgo anketiranje, spletni vtičnice in dogodki, poslani s strežnika, vsi načini za doseganje funkcij »občutka v realnem času«, vendar se kompromisi precej razlikujejo.

WebSockets vzpostavijo resnično trajen, polnodupleksni kanal med brskalnikom in strežnikom. Po začetnem rokovanju za nadgradnjo HTTP lahko podatkovni okvirji tečejo v obe smeri brez dodatnega bremena glav HTTP za vsako sporočilo, kar zmanjšuje zakasnitev in porabo pasovne širine na sporočilo.

Zaradi tega so WebSockets idealni za scenarije z veliko frekvenco, kot so igranje iger za več igralcev, skupno urejanje ali telemetrični tokovi, kjer so sporočila majhna, a pogosta. Slaba stran je, da nekateri korporativni požarni zidovi, stari posredniki ali podedovani odjemalci še vedno ne delujejo dobro z nadgradnjami WebSocket, strežniki pa morajo uporabljati drugačen programski model in infrastrukturo, uglašeno za veliko število dolgoživih vtičnic.

SSE je enostavnejši od WebSockets, saj potrebujete le potisno komunikacijo med strežnikom in odjemalcem, vendar ne more pošiljati sporočil iz brskalnika nazaj po istem kanalu; za komunikacijo med odjemalcem in strežnikom se še vedno zanašate na običajne zahteve HTTP. Prav tako zahteva, da posredniki tolerirajo pretakanje in ne pretirano shranjujejo delnih odgovorov v medpomnilniku.

V primerjavi s temi je dolgo anketiranje pogosto »najmanjši skupni imenovalec«, ki deluje v več okoljih, vključno s starejšimi brskalniki in konzervativnimi omrežnimi nastavitvami. Zato so številne platforme v realnem času v preteklosti uporabljale dolgo anketiranje kot rezervno možnost, ko so bili WebSocketi blokirani, in postopoma nadgrajevale povezave, ko so zmogljivosti to dopuščale.

Protokoli iz resničnega sveta na vrhu dolgega anketiranja: Bayeux, BOSH, SSE podobni API-ji

Poleg dolgega anketiranja in pretakanja je bilo zgrajenih več protokolov višje ravni, da bi pred razvijalci aplikacij skrili kompleksnost in zagotovili dosleden API. Razumevanje, kako uporabljajo dolge ankete, pomaga razjasniti tako prednosti kot slabosti tehnike.

Bayeuxov protokol, ki ga je populariziral projekt CometD, podpira tako dolgo anketiranje HTTP kot pretakanje kot možnosti prenosa. Odjemalec Bayeux običajno uporablja dve HTTP povezavi s strežnikom, tako da lahko sporočila asinhrono tečejo v obe smeri, ne da bi bila blokirana za dolgimi zahtevami za anketiranje.

Med začetnim rokovanjem se odjemalec in strežnik dogovorita, katere dvosmerne tehnike so podprte – dolgo anketiranje, pretakanje itd. – in odjemalec izbere eno od prekrivanja. Za odjemalce JavaScript se Bayeux običajno izogiba odvisnosti od HTTP pipeline in se namesto tega omeji na dve odprti zahtevi, da se izogne ​​težavam z omejitvijo povezave brskalnika.

BOSH (Bidirectional-streams Over Synchronous HTTP) izvira iz sveta XMPP in je bil zasnovan za emulacijo seje, podobne TCP, prek HTTP z uporabo dolgega anketiranja. Upravitelj povezav BOSH ohranja zahtevo odjemalca odprto in se odziva le, če ima podatke iz aplikacijskega strežnika; takoj ko odjemalec prejme ta odgovor, pošlje novo zahtevo, pri čemer skoraj ves čas ohranja vsaj eno čakajočo dolgo anketo.

BOSH lahko uporablja enega ali dva vzporedna para zahtev in odgovorov HTTP, o katerih se dogovori na začetku seje, in jih skrbno upravlja, da spoštuje omejitve povezave brskalnika, hkrati pa omogoča asinhrono dvosmerno sporočanje. Prepoveduje kodiranje prenosa z bloki, da se izognemo težavam z medpomnjenjem v posrednikih, in dovoljuje stiskanje prek Content-Encoding za učinkovitost.

Dogodki, poslani s strežnika, čeprav se običajno izvajajo prek pretakanja in ne dolgega anketiranja, so po duhu tesno povezani. Specifikacija W3C opisuje uporabo odgovorov besedilnega/dogodkovnega toka in predlaga onemogočanje HTTP-blokiranja, razen če je stopnja dogodkov dovolj visoka, spet zato, da se izognemo določenim težavam z medpomnjenjem in posredniškimi težavami, ki se pojavljajo pri pretakanju prek HTTP/1.1.

Optimizacija in utrjevanje dolgega anketiranja v aplikacijah JavaScript

Če se odločite, da je dolgo anketiranje prava izbira ali nujna rezerva za vašo aplikacijo JavaScript, obstaja več strategij, s katerimi jo lahko naredite učinkovitejšo, prilagodljivejšo in robustnejšo.

Najprej premišljeno prilagodite svoje časovne omejitve. Če je prekratek, boste zapravljali vire za obravnavanje pogostih ponovnih povezav in tvegali množice odjemalcev, ki se bodo vse hkrati ponovno povezale; če je predolg, boste povečali možnost doseganja omejitev proxyja ali uravnalnika obremenitve, kar bo povzročilo skrivnostne prekinitve povezav. V praksi vrednosti v območju 20–30 sekund za WaitTimeSeconds (v API-jih, kot je Amazon SQS) in podobne časovne omejitve na ravni aplikacije pogosto dosežejo dobro ravnovesje.

Nato razmislite o združevanju dogodkov na strani strežnika, ko je za odjemalca v čakalni vrsti več sporočil. Z zagotavljanjem več posodobitev v enem samem dolgem odgovoru na anketo se znatno zmanjša strošek na sporočilo in lahko sistem lažje degradira pod obremenitvijo, saj se zakasnitev spremeni v prepustnost.

Stiskanje je še ena preprosta zmaga: omogočanje gzip ali podobnega kodiranja vsebine za koristne tovore JSON pri dolgem anketiranju lahko zmanjša porabo pasovne širine, zlasti kadar imajo sporočila ponavljajočo se strukturo. Kompromis so dodatni stroški procesorja za stiskanje, vendar v mnogih resničnih uvedbah to odtehta krajši čas prenosa prek omrežja.

Z vidika JavaScripta sta robustno obravnavanje napak in logika ponovnega poskusa neizogibni. Vaša naročniška zanka bi morala zaznati omrežne napake, časovne omejitve ali napačno oblikovane odgovore in poskusiti znova z odložitvijo, namesto da bi preveč obremenjevala strežnik. Eksponentna odložitev z jitterjem je pogost vzorec za preprečevanje sinhroniziranih neviht ponovnih poskusov med izpadi.

Nenazadnje bodite disciplinirani pri čiščenju povezav, ko se komponente odklopijo ali zaprejo zavihki. Zombie zanke anketiranja, ki se nenehno izvajajo v ozadju, lahko porabijo tako odjemalske vire kot tudi zmogljivost strežnika, zato vedno poskrbite, da imate mehanizem za preklic čakajočih pridobitev ali prekinitev krmilnikov, ko je pogled uničen ali ko uporabnik zapusti stran.

Dolgo anketiranje v JavaScriptu ostaja močno orodje za gradnjo funkcij skoraj v realnem času v okoljih, kjer WebSockets ali SSE nista na voljo, vendar prinaša kup skritih stroškov glede glav, časovnih omejitev, proxyjev in porabe virov, ki jih morate razumeti in upravljati, če želite, da se vaša aplikacija gladko skalira.