Problemen met long polling in JavaScript en hoe je die kunt oplossen.

Home » Python » Problemen met long polling in JavaScript en hoe je die kunt oplossen.

Long polling in JavaScript lijkt bedrieglijk eenvoudig: houd een HTTP-verzoek open totdat de server een reactie heeft, stuur de gegevens terug en open direct een nieuw verzoek. Van buitenaf voelt het bijna aan als realtime communicatie, dus het is geen verrassing dat chat-apps, dashboards, games en notificatiesystemen er al jaren op vertrouwen. Maar onder de motorkap schuilen subtiele valkuilen op het gebied van prestaties, schaalbaarheid en betrouwbaarheid die zich openbaren zodra je app groeit tot meer dan een handvol gebruikers.

Om de werkelijke problemen van long polling in JavaScript te begrijpen, moet je verder kijken dan de basisbeschrijving "client stuurt verzoek, server wacht, server reageert" en kijken naar HTTP-semantiek, browserlimieten, proxies, time-outs en alternatieven zoals WebSockets, HTTP-streaming en Server-Sent Events. In deze handleiding gaan we dieper in op hoe long polling werkt, welke problemen zijn geïdentificeerd door de IETF en grote leveranciers, en hoe je kunt bepalen wanneer je het moet gebruiken, wanneer je het moet optimaliseren en wanneer je het volledig moet vervangen.

Wat long polling in JavaScript nu eigenlijk inhoudt

Simpel gezegd is long polling een patroon dat is gebaseerd op het normale HTTP-protocol, waarbij de browser een verzoek verstuurt en de server de reactie opzettelijk uitstelt totdat er nieuwe gegevens beschikbaar zijn of een time-out is verlopen. Zodra de browser een reactie ontvangt, verwerkt hij de gegevens en verstuurt hij onmiddellijk een nieuw verzoek, waardoor de verbinding "vrijwel altijd" in behandeling blijft.

Deze werkwijze verschilt sterk van de klassieke short polling, waarbij de client de server met vaste tussenpozen bestookt met de vraag "zijn er nieuwe updates?", ongeacht of er daadwerkelijk updates zijn. Bij long polling houdt de server het verzoek open tijdens perioden van inactiviteit, zodat de client niet herhaaldelijk lege polls hoeft te versturen wanneer er niets is veranderd.

Een typische JavaScript long polling loop ziet eruit als een recursieve subscribe-functie die fetch (of XMLHttpRequest) aanroept, wacht op het antwoord, de payload verwerkt en zichzelf vervolgens opnieuw aanroept. Als de netwerkverbinding wegvalt of er een fout optreedt, probeert de code onmiddellijk of na een korte vertraging de verbinding opnieuw tot stand te brengen, om deze zo lang mogelijk in stand te houden.

Deze aanpak werkt met name goed wanneer berichten relatief zeldzaam zijn, omdat inactiviteit op de verbinding geen netwerkverkeer of CPU-belasting genereert die verder gaat dan de kosten voor het openhouden van een socket. De gebruiker ervaart vrijwel onmiddellijke updates, terwijl de server niet constant wordt belast met polling-controles.

Echter, zodra gebeurtenissen frequent voorkomen, triggert elke gebeurtenis doorgaans een volledige HTTP-responscyclus – statusregel, headers, authenticatie, body – waardoor de kosten per bericht enorm kunnen stijgen en het verkeerspatroon een zaagtandachtige vorm van pieken in verzoeken en antwoorden begint te vertonen. Dat is waar problemen met schaalbaarheid en overhead zich beginnen voor te doen in praktijkgerichte applicaties.

Korte peilingen versus lange peilingen versus streaming

Om het probleemgebied echt te begrijpen, is het nuttig om long polling te vergelijken met short polling en HTTP-streaming, aangezien alle drie manieren zijn om een ​​"push" te simuleren via een fundamenteel verzoek/antwoordprotocol zoals HTTP.

Short polling is de naïeve variant: de client verstuurt periodiek HTTP-verzoeken (bijvoorbeeld elke 5-10 seconden) en de server antwoordt onmiddellijk met alle berichten die sinds de laatste poll zijn binnengekomen. Als er niets beschikbaar is, reageert de server nog steeds, vaak met een lege payload, en wacht de client simpelweg tot het volgende interval.

Dit model heeft twee duidelijke nadelen: de berichtvertraging kan net zo hoog zijn als het pollinginterval, en de server is gedwongen om herhaalde verzoeken af ​​te handelen, zelfs wanneer er geen nieuwe gegevens zijn. Voor kleine systemen of systemen met weinig verkeer is dit wellicht acceptabel, maar op grote schaal leidt het tot verspilling van CPU-cycli en netwerkbandbreedte, en kan het merkbare vertragingen voor gebruikers veroorzaken.

Long polling is een verbetering doordat de server elk verzoek "openhoudt" totdat er iets interessants gebeurt, zoals een gebeurtenis die moet worden verwerkt of een time-outdrempel. De latentie voor nieuwe berichten is nu bijna gelijk aan één netwerk-roundtrip, en lege reacties komen veel minder vaak voor, waardoor onnodig dataverkeer wordt verminderd.

HTTP-streaming gaat nog een stap verder door de respons helemaal niet te sluiten: de server stuurt één HTTP-respons en streamt vervolgens meerdere stukken data over dezelfde verbinding, gescheiden door een bepaalde structuur op applicatieniveau. De client leest de stream stapsgewijs in plaats van te wachten tot het volledige antwoord is verwerkt.

In HTTP/1.1 wordt dit meestal geïmplementeerd via chunked transfer encoding, waarbij de server Transfer-Encoding: chunked instelt en vervolgens elk stukje data als een aparte chunk verzendt met een eigen lengteheader. In HTTP/1.0-achtige configuraties kan streaming ook worden bereikt door Content-Length weg te laten en connection close als einde-of-stream-markering te gebruiken.

Het cruciale verschil is dat bij long polling de respons na elk bericht wordt gesloten, waardoor een nieuw verzoek voor de volgende gebeurtenis wordt afgedwongen, terwijl bij streaming dezelfde respons actief blijft en berichten worden doorgestuurd zodra ze binnenkomen. Dat heeft grote gevolgen voor latentie, geheugengebruik, proxies en de manier waarop je berichten op applicatieniveau structureert.

Hoe HTTP long polling intern werkt

Vanuit het perspectief van het HTTP-protocol introduceert long polling geen nieuwe methoden of statuscodes; het rekt alleen de gebruikelijke semantiek van een verzoek dat op een antwoord wacht op. De analyse van de IETF over "bidirectioneel HTTP" maakt duidelijk dat long polling nog steeds geldig is voor HTTP 1.0/1.1, maar dat het model daarmee wel tot zijn grenzen wordt gedreven.

De basislevenscyclus van een long polling-interactie ziet er als volgt uit: de client verstuurt een eerste verzoek en wacht, de server stelt het antwoord uit totdat er een gebeurtenis, statuswijziging of time-out optreedt, vervolgens stuurt de server een volledig HTTP-antwoord (vaak 200 OK) met de gebeurtenisgegevens terug, en ten slotte verstuurt de client snel een nieuw verzoek.

Dit patroon kan worden toegepast op zowel persistente als niet-persistente HTTP-verbindingen; bij persistente verbindingen vermijdt u de overhead van herhaalde TCP-handshakes door dezelfde socket te hergebruiken voor meerdere lange polling-verzoeken. In de praktijk is het voor de prestaties vrijwel altijd beter om dezelfde TCP-verbinding open te houden.

Servers die long polling implementeren, moeten doorgaans twee resourcebuckets per client beheren: de TCP-verbinding zelf en het openstaande HTTP-verzoek dat in een wachtrij of gebeurtenisloop staat te wachten. Besturingssystemen kunnen doorgaans grote aantallen open sockets efficiënt verwerken, maar sommige HTTP-servers of gateways reserveren aanzienlijke hoeveelheden geheugen per verzoek, wat een echt knelpunt kan vormen.

Een interessante eigenschap van long polling is dat het onder zware belasting de neiging heeft om geleidelijk af te zwakken door een toenemende latentie in plaats van volledig uit te vallen. Als de server traag is, zullen berichten die voor een client bestemd zijn in de wachtrij komen te staan ​​totdat er een antwoord kan worden verzonden; meerdere berichten in de wachtrij kunnen zelfs worden samengevoegd tot één lange polling-reactie, wat overigens de overhead per bericht vermindert.

Problemen en beperkingen van long polling

Ondanks dat long polling in de praktijk veelvuldig wordt gebruikt en gestandaardiseerd is, brengt het een aantal bekende technische problemen met zich mee die, als je niet voorzichtig bent, gemakkelijk vanuit JavaScript kunnen worden ondervonden. Deze problemen manifesteren zich in bandbreedtegebruik, latentie, verbindingsbeheer en het gedrag van tussenpersonen zoals proxy's en caches.

De overhead van de headers is de eerste kostenpost: elke long poll-aanvraag en -reactie is een volledig HTTP-bericht, meestal met cookies, authenticatieheaders en andere metadata die de daadwerkelijke payload aanzienlijk kunnen overschaduwen. Voor kleine, infrequent verstuurde berichten is deze overhead wellicht acceptabel, maar in op volume gebaseerde factureringsscenario's of netwerken met beperkte bandbreedte kan het verschil tussen de grootte van de header en de grootte van de payload duur uitpakken.

Maximale latentie is een ander subtiel probleem: terwijl de gemiddelde latentie bij long polling voor nieuwe gebeurtenissen ongeveer één netwerktransit bedraagt, kan de vertraging in het slechtste geval meer dan drie transits bedragen. Als een bericht direct na een antwoord van de server binnenkomt, moet de server wachten op het volgende verzoek van de client voordat hij dat bericht kan afleveren. Verlies of herverzending van TCP-pakketten kan deze wachttijd verder verlengen.

Het tot stand brengen van een verbinding wordt vaak als een probleem gezien, vooral wanneer men long polling vergelijkt met WebSockets. Als elke reactie op een long polling-verzoek ertoe zou leiden dat de HTTP-verbinding (en de onderliggende TCP-verbinding) wordt verbroken, zouden de kosten van het herhaaldelijk openen van sockets enorm zijn. Gelukkig kan en moet long polling bovenop persistente verbindingen worden toegepast, zodat de korte pauze tussen reacties niet wordt geïnterpreteerd als inactiviteit; hierdoor blijft het transport open en herbruikbaar.

De toewijzing van server- en proxybronnen is een belangrijke praktische beperking: elk openstaand verzoek verbruikt geheugen en mogelijk een thread of worker in synchrone architecturen. Veel oudere of blokkerende servers zijn simpelweg niet geschikt voor tienduizenden gelijktijdige lange pollingverzoeken, omdat hun gelijktijdigheidsmodel ervan uitgaat dat elk verzoek snel wordt afgehandeld; voor deze systemen is asynchrone I/O of een gebeurtenisgestuurd ontwerp vrijwel onmisbaar.

Ook het cachegedrag kan lange polling verstoren als dit niet expliciet wordt uitgeschakeld. Tussenliggende caches kunnen ervoor kiezen om antwoorden opnieuw te gebruiken of op te slaan, tenzij u long poll-verzoeken en -antwoorden duidelijk markeert met Cache-Control: no-cache (en bijbehorende headers). Dit zorgt ervoor dat elk verzoek daadwerkelijk de oorspronkelijke server bereikt en geen verouderde gegevens ontvangt.

Time-outs, proxy's en het gedrag van tussenpersonen

Een van de meest irritante praktijkproblemen met long polling in JavaScript is dat je geen volledige controle hebt over het netwerk tussen browser en server. Proxy's, gateways, load balancers en zelfs de standaardinstellingen van browsers hanteren allemaal time-outs of bufferstrategieën die de illusie van een live verbinding kunnen verstoren.

Verzoeken om lange polling blijven in principe open tot een bepaalde gebeurtenis plaatsvindt of een time-out optreedt die u zelf kunt bepalen, maar in de praktijk verbreken veel tussenpersonen de verbinding na een kortere, vaste periode. Hoewel browsers standaard een time-out van ongeveer 300 seconden toestaan, hanteren sommige proxy's veel kortere time-outs. Dit betekent dat uw long poll-verzoek wordt beëindigd met een HTTP 504 Gateway Timeout-fout of een reset, waardoor de client vaker opnieuw verbinding moet maken dan de bedoeling was.

Experimenten en operationele ervaring wijzen erop dat time-outs van ongeveer 30 seconden in veel omgevingen een veiliger compromis vormen, terwijl 120 seconden vaak wel werkt, maar kwetsbaarder is. Leveranciers van netwerkapparatuur die long-polling willen ondersteunen, worden aangemoedigd om aanzienlijk langere time-outs te gebruiken dan de gebruikelijke transittijden van een gemiddeld netwerk, zodat legitieme long-pollingverzoeken niet voortijdig worden afgebroken.

Reverse proxies en connection pooling introduceren een andere categorie problemen. Sommige proxy-configuraties delen een kleine pool van upstream-verbindingen tussen veel clients; als langdurige polling-verzoeken deze gedeelde verbindingen gedurende langere perioden bezetten, kunnen andere verzoeken worden geblokkeerd of in de wachtrij terechtkomen, waardoor de prestaties van de hele site worden ondermijnd.

Bij HTTP-streaming is buffering door tussenpersonen een nog groter risico, omdat proxy's gedeeltelijke reacties mogen bufferen en gegevens pas doorsturen zodra ze een volledige reactie hebben ontvangen. In dat geval kan een streamingserver die kleine JavaScript-fragmenten verzendt met de verwachting dat ze direct in de browser worden uitgevoerd, merken dat een tussenliggende server alles vasthoudt totdat de verbinding wordt verbroken, waardoor de realtime werking volledig wordt verstoord.

Browserlimieten en aantal verbindingen

Vanuit JavaScript manipuleer je nooit rechtstreeks TCP-verbindingen; je ziet alleen constructies op hoog niveau zoals fetch of XMLHttpRequest, maar browsers hanteren wel limieten voor het aantal parallelle verbindingen met dezelfde host. Historisch gezien lag deze limiet op twee verbindingen per oorsprong, wat Comet-achtige technieken bijzonder lastig maakte.

Moderne browsers hebben deze beperkingen versoepeld tot ongeveer zes of acht verbindingen per host, maar er is nog steeds geen standaard manier vanuit JavaScript om te vragen "hoeveel verbindingen zijn er nog over?" of om het gebruik ervan over tabbladen en iframes te coördineren. Elk tabblad kan onafhankelijk een eigen lange poll starten, waardoor de beschikbare slots snel uitgeput raken en andere essentiële verzoeken, zoals CSS, afbeeldingen of API-aanroepen, worden geblokkeerd.

Een goede werkwijze aan de serverzijde is om cookies of een ander correlatiemechanisme te gebruiken om meerdere lange pollingverzoeken afkomstig van dezelfde browserinstantie te detecteren en te voorkomen dat ze allemaal worden uitgesteld. Door snel te reageren op zeer lange polls en slechts één of een klein aantal polls daadwerkelijk te blokkeren, kunt u het risico op verbindingsproblemen of interferentie met de pipeline verkleinen.

Sommige protocollen op een hoger niveau die gebaseerd zijn op long polling, zoals Bayeux en BOSH, houden expliciet rekening met de verbindingslimieten van browsers. Ze gebruiken doorgaans maximaal twee openstaande HTTP-verzoeken tegelijk en vermijden het gebruik van HTTP-pipelining, dat slecht wordt ondersteund en niet vanuit JavaScript kan worden beheerd.

HTTP-pipelining, framing en berichtvolgorde

Hoewel HTTP-pipelining (het achter elkaar versturen van meerdere verzoeken via dezelfde verbinding voordat er antwoorden worden ontvangen) in theorie de latentie bij lange pollingtijden zou kunnen verminderen, is het in de praktijk kwetsbaar en wordt het inconsistent geïmplementeerd. RFC 2616 is voorzichtig met pipelining, vooral voor POST-verzoeken, en tussenpersonen of clients kunnen het volledig uitschakelen.

Protocollen die pipelining willen gebruiken voor long polling, moeten eerst controleren of pipelining betrouwbaar van begin tot eind wordt ondersteund; zo niet, dan vallen ze terug op een conservatievere, niet-gepipelineerde werkwijze. Vanuit de JavaScript-omgeving van een browser heb je niet de mogelijkheid om dit te beheren, dus de meeste op JavaScript gebaseerde long polling-stacks gaan er simpelweg van uit dat pipelining niet beschikbaar is.

Framing – de manier waarop je een continue stroom bytes opsplitst in afzonderlijke applicatieberichten – is een ander subtiel verschil tussen long polling en HTTP-streaming. Bij long polling bevat elke HTTP-respons van nature precies één of een reeks berichten, waardoor de context impliciet is: één respons staat gelijk aan één stuk betekenisvolle data.

Bij streaming kun je niet vertrouwen op HTTP-chunkgrenzen als kader voor je applicatie, omdat proxy's de datastroom opnieuw kunnen opdelen, chunks kunnen samenvoegen of op een andere manier kunnen splitsen. Dat betekent dat de app zijn eigen scheidingstekens of lengtevoorvoegsels in de payload moet insluiten en deze vervolgens aan de clientzijde moet verwerken.

De volgorde en betrouwbaarheid van berichten worden niet gegarandeerd door long polling zelf; deze zijn afhankelijk van uw applicatieprotocol en opslaglaag. Als een client de verbinding halverwege verbreekt en opnieuw verbinding maakt, zijn expliciete mechanismen (zoals volgnummers of ID's van de laatste gebeurtenis) nodig om ervoor te zorgen dat er geen berichten verloren gaan of in de verkeerde volgorde worden afgeleverd.

Beveiligingsaspecten van long polling in JavaScript

Long polling als techniek verandert het kernbeveiligingsmodel van HTTP niet, maar de manier waarop het vaak wordt geïmplementeerd – met name in browsers die JavaScript gebruiken – kan de deur openzetten voor extra risico's.

Veel cross-domain long polling-oplossingen zijn afhankelijk van het uitvoeren van JavaScript dat door de server wordt teruggestuurd, soms via callbacks in JSONP-stijl of andere vormen van dynamische scriptinjectie. Als uw server kwetsbaar is voor injectieaanvallen, kan een aanvaller mogelijk willekeurige code in de reacties smokkelen, die de browser vervolgens uitvoert met de bevoegdheden van de pagina.

Het gebruik van HTTPS is overal onmisbaar: het versleutelen van het transport beschermt tegen man-in-the-middle-aanvallen en het afluisteren van langdurige verbindingen. In combinatie met robuuste authenticatie en autorisatie (bijvoorbeeld op tokens gebaseerde authenticatie en op rollen gebaseerde toegangscontrole) kunt u endpoints die lange polling uitvoeren, beperken tot de beoogde clients.

Omdat long polling veel verbindingen gedurende lange perioden openhoudt, kan het DoS-aanvallen aantrekkelijker maken: een aanvaller zou kunnen proberen de serverbronnen uit te putten door veel valse long polls te openen. Snelheidsbeperking, verbindingsquota per IP-adres of token en verstandige time-outs zijn essentiële verdedigingsmaatregelen.

Browserspecifieke bedreigingen zoals CSRF zijn doorgaans minder belangrijk voor pure XHR/fetch long polls die niet afhankelijk zijn van ambient cookies, maar als er wel cookies bij betrokken zijn, moet u deze eindpunten nog steeds behandelen zoals elke andere gevoelige API. SameSite-cookies, CSRF-tokens waar nodig en strikte CORS-regels maken allemaal deel uit van een robuuste configuratie.

Long polling versus WebSockets en Server-Sent Events

Vanuit het perspectief van een JavaScript-ontwikkelaar zijn long polling, WebSockets en Server-Sent Events allemaal manieren om functionaliteiten te creëren die "realtime aanvoelen", maar de voor- en nadelen verschillen aanzienlijk.

WebSockets leggen een echt persistent, full-duplex kanaal tot stand tussen browser en server. Na de initiële HTTP-upgradehandshake kunnen dataframes in beide richtingen worden verzonden zonder de overhead van HTTP-headers voor elk bericht, waardoor de latentie en het bandbreedtegebruik per bericht worden geminimaliseerd.

Dit maakt WebSockets ideaal voor scenario's met een hoge frequentie, zoals multiplayer-games, gezamenlijk bewerken of telemetriestromen, waarbij de berichten klein maar frequent zijn. Het nadeel is dat sommige bedrijfsfirewalls, oude proxy's of verouderde clients nog steeds niet goed samenwerken met WebSocket-upgrades, en dat servers een ander programmeermodel en een andere infrastructuur moeten gebruiken die is afgestemd op grote aantallen langlopende sockets.

SSE is eenvoudiger dan WebSockets als je alleen pushberichten van server naar client nodig hebt, maar het kan geen berichten vanuit de browser terugsturen via hetzelfde kanaal; je bent nog steeds afhankelijk van normale HTTP-verzoeken voor client-servercommunicatie. Het vereist tevens dat tussenpersonen streaming tolereren en gedeeltelijke reacties niet overmatig bufferen.

In vergelijking hiermee is long polling vaak de "laagste gemene deler" die in meer omgevingen werkt, waaronder oudere browsers en conservatieve netwerkconfiguraties. Daarom gebruikten veel realtimeplatformen van oudsher long polling als terugvaloptie wanneer WebSockets geblokkeerd waren, waarbij de verbindingen geleidelijk werden opgewaardeerd naarmate de mogelijkheden dat toelieten.

Praktische protocollen bovenop long polling: Bayeux, BOSH, SSE-achtige API's

Er zijn diverse protocollen op een hoger niveau ontwikkeld bovenop long polling en streaming om de complexiteit voor applicatieontwikkelaars te verbergen en een consistente API te bieden. Inzicht in hoe ze long polling toepassen, helpt zowel de sterke als de zwakke punten van de techniek te verduidelijken.

Het Bayeux-protocol, dat populair is geworden dankzij het CometD-project, ondersteunt zowel HTTP long polling als streaming als transportopties. Een Bayeux-client gebruikt doorgaans twee HTTP-verbindingen met een server, zodat berichten asynchroon in beide richtingen kunnen worden uitgewisseld zonder te worden geblokkeerd door lange pollingverzoeken.

Tijdens een eerste handshake onderhandelen client en server over welke bidirectionele technieken worden ondersteund – long polling, streaming, enz. – en de client kiest er één uit de overlappende mogelijkheden. Voor JavaScript-clients vermijdt Bayeux doorgaans het gebruik van HTTP-pipelining en beperkt het zich in plaats daarvan tot twee openstaande verzoeken om problemen met de verbindingslimiet van de browser te voorkomen.

BOSH (Bidirectional-streams Over Synchronous HTTP) is afkomstig uit de XMPP-wereld en is ontworpen om een ​​TCP-achtige sessie via HTTP te emuleren met behulp van long polling. Een BOSH-verbindingsmanager houdt een clientverzoek open en reageert pas wanneer er gegevens van de applicatieserver beschikbaar zijn. Zodra de client dat antwoord ontvangt, stuurt hij een nieuw verzoek, waardoor er vrijwel continu minstens één long poll in behandeling blijft.

BOSH kan één of twee parallelle HTTP-verzoek-antwoordparen gebruiken, die aan het begin van de sessie worden overeengekomen, en beheert deze zorgvuldig om de verbindingslimieten van de browser te respecteren, terwijl asynchrone bidirectionele berichtenuitwisseling toch mogelijk blijft. Het verbiedt chunked transfer encoding om bufferingproblemen in tussenliggende systemen te voorkomen en staat compressie via Content-Encoding toe voor efficiëntie.

Server-Sent Events worden weliswaar meestal geïmplementeerd via streaming in plaats van long polling, maar ze zijn in principe nauw verwant. De W3C-specificatie beschrijft het gebruik van tekst-/gebeurtenisstroomreacties en suggereert het uitschakelen van HTTP-chunking, tenzij de gebeurtenisfrequentie hoog genoeg is. Dit is wederom om bepaalde buffering- en tussenliggende problemen te voorkomen die zich voordoen bij streaming via HTTP/1.1.

Optimaliseren en beveiligen van long polling in JavaScript-apps

Als je besluit dat long polling de juiste keuze is, of een noodzakelijke terugvaloptie voor je JavaScript-app, zijn er verschillende strategieën om het efficiënter, schaalbaarder en robuuster te maken.

Ten eerste, stem je time-outs zorgvuldig af. Een te korte time-out zorgt voor onnodige resources door het afhandelen van frequente herverbindingen en verhoogt het risico dat een grote groep clients tegelijkertijd verbinding probeert te maken; een te lange time-out vergroot de kans op het bereiken van de limieten van de proxy of load balancer, wat kan leiden tot onverklaarbare verbroken verbindingen. In de praktijk bieden waarden tussen de 20 en 30 seconden voor WaitTimeSeconds (in API's zoals Amazon SQS) en vergelijkbare time-outs op applicatieniveau vaak een goede balans.

Overweeg vervolgens om gebeurtenissen aan de serverzijde te bundelen wanneer meerdere berichten voor een client in de wachtrij staan. Het versturen van meerdere updates in één lange polling-respons vermindert de overhead per bericht aanzienlijk en kan ervoor zorgen dat het systeem onder belasting soepeler presteert door latentie in te ruilen voor doorvoer.

Compressie is nog een makkelijke winst: het inschakelen van gzip of een vergelijkbare coderingsmethode voor JSON-payloads bij long polling kan het bandbreedtegebruik verminderen, vooral wanneer berichten een repetitieve structuur hebben. De keerzijde is een hoger CPU-gebruik voor compressie, maar in veel praktijksituaties weegt dat ruimschoots op tegen de kortere netwerkoverdrachtstijd.

Vanuit JavaScript-perspectief zijn robuuste foutafhandeling en herhalingslogica onmisbaar. Je abonnementslus moet netwerkfouten, time-outs of onjuist geformuleerde reacties detecteren en de aanvraag opnieuw proberen met een bepaalde backoff-periode in plaats van de server te overbelasten. Exponentiële backoff met jitter is een veelgebruikt patroon om een ​​stortvloed aan gesynchroniseerde herhaalpogingen tijdens storingen te voorkomen.

Wees tot slot gedisciplineerd bij het opruimen van verbindingen wanneer componenten worden ontkoppeld of tabbladen worden gesloten. Zombie-pollingloops die op de achtergrond blijven draaien, kunnen zowel clientbronnen als servercapaciteit uitputten. Zorg er daarom altijd voor dat u een mechanisme hebt om lopende fetches te annuleren of controllers af te breken wanneer een view wordt verwijderd of een gebruiker naar een andere pagina navigeert.

Long polling in JavaScript blijft een krachtig hulpmiddel voor het bouwen van bijna realtime functionaliteiten in omgevingen waar WebSockets of SSE niet beschikbaar zijn. Het brengt echter wel een aantal verborgen kosten met zich mee, zoals kosten voor headers, time-outs, proxies en resourcegebruik, die je moet begrijpen en beheren als je wilt dat je app soepel schaalbaar is.