Short Polling: wat is het, hoe werkt het en waar wordt het gebruikt

Wat is Short Polling

Short Polling — is een communicatiepatroon waarbij de client periodiek HTTP-verzoeken naar de server stuurt met een vooraf ingesteld interval, en de server elk verzoek synchroon verwerkt en onmiddellijk het resultaat retourneert. Het pollinginterval wordt aan de clientzijde ingesteld met behulp van timers en varieert meestal van 1 tot 60 seconden, afhankelijk van de vereisten voor de actualiteit van gegevens.

Short Polling is chronologisch het eerste mechanisme voor het organiseren van real-time communicatie in webapplicaties. In het begin van de jaren 2000, vóór de komst van XMLHttpRequest van de tweede generatie, gebruikten webpagina’s <meta http-equiv=”refresh”> of het periodiek herladen van iframes om inhoud bij te werken. Met de komst van AJAX (Asynchronous JavaScript and XML) technologie in 2005 werd Short Polling de standaardaanpak voor het bijwerken van gegevens zonder de pagina volledig te herladen.

Short Polling-architectuur

De Short Polling-architectuur omvat drie componenten: een clienttimer, een HTTP-verzoek en een serverhandler. De client start een intervaltimer, waarna een GET-verzoek naar de server wordt gestuurd. De server voert een query uit op de database of een andere bron, vormt een antwoord en retourneert dit onmiddellijk aan de client. De client werkt de interface bij en wacht op de volgende timer-activatie. Deze cyclus herhaalt zich oneindig zolang de applicatie actief is.

Probleem van overmatige verzoeken

Het grootste probleem van Short Polling — onvermijdelijke lege verzoeken. Als gegevens zelden veranderen, retourneren de meeste verzoeken het resultaat „geen wijzigingen”, wat netwerkbandbreedte en processortijd verspilt aan verwerking. Met 10.000 clients en een pollinginterval van 5 seconden ontvangt de server 2.000 verzoeken per seconde — waarvan een aanzienlijk deel nutteloos is als de updatefrequentie 1 gebeurtenis per minuut is.

Hoe werkt Short Polling

Short Polling werkt volgens een eenvoudige cyclus: de client stelt een intervaltimer in met een bepaalde periode (bijv. 5000 ms). Bij elke timer-activatie maakt de client een HTTP GET-verzoek naar het serverendpoint, meestal met een parameter voor de timestamp van de laatste update. De server ontvangt het verzoek, controleert op nieuwe gegevens na de opgegeven timestamp en retourneert een antwoord — ofwel met nieuwe gegevens, ofwel met een indicatie dat er geen updates zijn.

De kritieke configuratieparameter van Short Polling — het pollinginterval. Een te kort interval (minder dan 3 seconden) veroorzaakt hoge belasting van de server en het netwerk. Een te lang interval (meer dan 30 seconden) vermindert de actualiteit van gegevens. Het optimale interval hangt af van het scenario: voor monitoringspanelen — 5–15 seconden, voor nieuwsfeeds — 30–60 seconden, voor kritieke alerts — 1–3 seconden. De keuze van het interval is altijd een compromis tussen actualiteit van gegevens en infrastructuurbelasting.

Adaptief pollinginterval

Om de belasting bij inactiviteit te verminderen, wordt een adaptief interval gebruikt: als meerdere opeenvolgende verzoeken een leeg resultaat opleveren, wordt het interval verlengd (bijv. van 5 naar 15 seconden). Wanneer er nieuwe gegevens verschijnen, wordt het interval teruggezet naar de minimumwaarde. Het exponentiële vertragingsalgoritme (exponential backoff) kan het aantal lege verzoeken bij zeldzame updates met 3–5 keer verminderen.

Voorbeeld van Short Polling-implementatie in JavaScript

Laten we de clientimplementatie van Short Polling bekijken met behulp van setInterval en Fetch API. De functie accepteert de URL van het endpoint en het pollinginterval in milliseconden.

function startPolling(url, intervalMs) {
    const lastTimestamp = new Date().toISOString();

    const timerId = setInterval(async () => {
        try {
            const params = new URLSearchParams({
                since: lastTimestamp
            });
            const response = await fetch(url + "?" + params);
            const data = await response.json();

            if (data.updates && data.updates.length > 0) {
                renderUpdates(data.updates);
                console.log("Ontvangen", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("Polling mislukt:", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer) om te stoppen

De code creëert een pollinginterval met een periode van 5 seconden en stuurt de timestamp van de laatste update naar de server. De server kan deze parameter gebruiken om gegevens te filteren en alleen nieuwe records terug te sturen, waardoor de hoeveelheid verzonden informatie wordt verminderd. De functie retourneert de timer-ID om de polling te kunnen stoppen.

Serverkant van Short Polling

De serverimplementatie voor Short Polling is uiterst eenvoudig — het is een gewoon REST-endpoint dat GET-verzoeken accepteert en een JSON-antwoord retourneert met de huidige status of gegevens die zijn gewijzigd na de opgegeven timestamp.

const express = require("express");
const app = express();

let items = [];

app.get("/api/updates", (req, res) => {
    const since = req.query.since;
    const filtered = items.filter(item => item.timestamp > since);
    res.json({ updates: filtered });
});

app.listen(3000);

De server ontvangt de parameter since en filtert records waarvan de timestamp de opgegeven waarde overschrijdt. Deze aanpak minimaliseert de hoeveelheid gegevens in elk antwoord door alleen incrementele wijzigingen terug te sturen. Bij afwezigheid van nieuwe gegevens retourneert de server een lege array en gaat de client verder met pollen volgens schema.

Short Polling vs Long Polling

Short Polling en Long Polling lossen dezelfde taak op — het leveren van gegevens van de server — maar verschillen radicaal in efficiëntie. Short Polling gebruikt een vast verzoekinterval, wat voorspelbare belasting creëert, terwijl Long Polling de verbinding vasthoudt tot er een gebeurtenis plaatsvindt, waardoor het aantal lege antwoorden wordt geminimaliseerd.

De keuze tussen technieken hangt af van de updatefrequentie van gegevens. Als gebeurtenissen vaker dan eens per 10 seconden plaatsvinden — beide benaderingen geven vergelijkbare belasting, en Short Polling kan eenvoudiger zijn. Als gebeurtenissen zeldzaam zijn (uren of minuten tussen wijzigingen) — heeft Long Polling de voorkeur omdat het geen lege verzoeken creëert. Voor tussenliggende scenario’s hangt de keuze af van infrastructurele beperkingen en de mogelijkheid om WebSocket te gebruiken.

Wanneer wordt Short Polling toegepast

Short Polling wordt toegepast in scenario’s waar de vereisten voor gegevensactualiteit laag zijn en implementatie-eenvoud prioriteit heeft boven efficiëntie. De meest typische gevallen zijn interne administratieve panelen, monitoringssystemen met lage alertfrequentie en applicaties waarin een vertraging van 15–30 seconden acceptabel is.

• Monitoringspanelen — dashboards met metrieken die elke 10–30 seconden worden bijgewerkt en geen directe reactie op wijzigingen vereisen.
• Statuspagina’s — pagina’s voor het controleren van de beschikbaarheid van diensten, waar gegevens elke 30–60 seconden worden bijgewerkt en vertraging niet kritisch is.
• Analytische rapporten — interne analysesystemen met periodieke gegevensverzameling, waar actualiteit tot 1 minuut acceptabel is.
• Eenvoudige spellen — multiplayer beurtspellen zonder realtime vereisten, waar de beurt om de paar seconden wordt bijgewerkt.
• Testen — belastingtest- en foutopsporingsscenario’s, waar Short Polling wordt gebruikt als referentiepollingmethode voor vergelijking met andere technieken.

Belangrijke beperking — Short Polling is niet geschikt voor tijdkritische applicaties (handelsterminals, noodwaarschuwingssystemen), waar een vertraging van zelfs 1 seconde onaanvaardbaar is. In dergelijke scenario’s moeten WebSocket, Server-Sent Events of Long Polling worden gebruikt. Bij het ontwerpen van een systeem met Short Polling moet het verzoekbudget worden berekend: met 1.000 clients en een interval van 5 seconden verwerkt de server 12.000 verzoeken per minuut, wat een passende resourcebasis vereist.