- Long polling in PHP houdt HTTP-verzoeken open, wat schaarse PHP-workers kan blokkeren en de schaalbaarheid kan schaden als het wordt geïmplementeerd met naïeve blokkerende lussen.
- Moderne, gebeurtenisgestuurde benaderingen, zorgvuldige configuratie en optimalisaties zoals batchverwerking, caching en snelheidsbeperking kunnen veel problemen met langdurige polling verhelpen.
- Alternatieven zoals WebSockets, SSE en beheerde realtimeplatforms bieden vaak betere prestaties voor scenario's met een hoge gelijktijdigheid dan pure PHP long polling.
Als je ooit hebt geprobeerd om 'realtime' functionaliteit toe te voegen aan een klassieke PHP-applicatie, ben je waarschijnlijk wel eens tegen long polling en de bijbehorende vreemde prestatieproblemen aangelopen. Wat klinkt als een simpele truc – een HTTP-verzoek openhouden totdat er iets nieuws te verzenden is – roept plotseling lastige vragen op over geblokkeerde PHP-processen, servergeheugen, time-outs en hoe je in vredesnaam moet opschalen naar meer dan een handvol gebruikers.
Deze handleiding gaat diep in op het long polling-probleem in PHP, waarom het zich zo gedraagt, welke knelpunten er echt toe doen en wat je eraan kunt doen. We zullen uitleggen hoe lang opiniepeilingen werken en waarom een naïeve sleep()Een op PHP gebaseerde implementatie is vaak slechter dan short polling. We bespreken hoe moderne event loops en webservers hierbij kunnen helpen en welke optimalisaties de moeite waard zijn. Onderweg vergelijken we long polling met WebSockets en Server-Sent Events, raken we aan beveiliging en foutafhandeling en bekijken we wanneer je PHP beter kunt inruilen voor iets als Node.js of een beheerd realtime platform.
Wat is long polling en hoe werkt het precies?
In essentie is long polling niets meer dan HTTP waarbij de server de reactie opzettelijk uitstelt totdat er iets interessants te melden valt. In plaats van dat de client de server om de paar seconden bestookt met de vraag "is er al iets nieuws?", stuurt de client een verzoek dat de server openhoudt en pas antwoordt wanneer er nieuwe gegevens beschikbaar zijn of wanneer een time-out is bereikt.
De typische lange polling-aanvraag/antwoordcyclus ziet er als volgt uit: De browser (of een andere client) doet een HTTP-verzoek naar een speciaal eindpunt. De server accepteert het verzoek, maar stuurt niet direct een antwoord terug. De TCP-verbinding blijft open terwijl de server wacht op nieuwe gebeurtenissen of gegevens.
Als er een gebeurtenis plaatsvindt – een chatbericht, een melding, een game-update – reageert de server onmiddellijk op de wachtende client. De client verwerkt die gegevens en, cruciaal, verstuurt direct een nieuw long polling-verzoek, zodat er altijd (of bijna altijd) een open verbinding beschikbaar is die wacht op de volgende update.
Als er een tijdje niets gebeurt, zal de server de aanvraag na een ingestelde limiet uiteindelijk beëindigen en reageren met lege gegevens of een "geen update"-payload. De client verstuurt nog steeds een nieuw verzoek wanneer hij deze time-outmelding ontvangt, waardoor het langdurige gedrag behouden blijft door herhaalde HTTP-aanroepen in plaats van één oneindige verbinding.
Hoewel men spreekt over een "permanente" long polling-verbinding, is het technisch gezien een lus van relatief langdurige HTTP-verzoeken in plaats van één oneindige stroom. Dat subtiele verschil is van groot belang voor PHP, omdat elk van die verzoeken normaal gesproken gedurende zijn hele levensduur aan één PHP-werkproces of -thread is gekoppeld.
Long polling versus short polling in PHP
Short polling is het eenvoudigere, traditionele patroon: de client vraagt de server volgens een vast schema om nieuwe gegevens en de server antwoordt onmiddellijk. Je zou kunnen raken /notifications Controleer elke 3-5 seconden snel de database en stuur alles wat nieuw is door.
Deze aanpak is makkelijk te begrijpen, maar ontzettend inefficiënt wanneer de meeste peilingen "niets nieuws" opleveren. Je verbruikt CPU-kracht, databasequery's en netwerkbelasting door een constante stroom van grotendeels lege reacties, en de gebruiker kan nog steeds vertragingen ervaren tussen een gebeurtenis en de volgende geplande polling.
Long polling draait het model om: minder HTTP-verzoeken, maar elk verzoek blijft veel langer actief terwijl de server wacht op een gebeurtenis. Theoretisch gezien vermindert dat de HTTP-overhead en verbetert het de ervaren responsiviteit, omdat gebruikers updates ontvangen zodra deze plaatsvinden in plaats van te moeten wachten op het volgende polling-interval.
Het probleem in PHP is dat een naïef long polling-eindpunt een worker blokkeert gedurende de wachttijd. Als je een verbinding 300 seconden openhoudt met behulp van een lus met sleep()Je bezet hiermee een PHP-proces of -thread die anders in dezelfde tijdspanne veel snelle, korte verzoeken zou kunnen verwerken.
Als je de twee onder belasting vergelijkt, blijkt een slecht geïmplementeerd long polling-eindpunt in werkelijkheid veel minder gelijktijdige clients aan te kunnen dan een short polling-eindpunt. Een PHP-FPM-pool die bijvoorbeeld gemakkelijk duizenden kleine polls van 5 seconden kan verwerken, kan vastlopen als elke gebruiker een worker voor 300 seconden tegelijk in beslag neemt.
Waarom het klassieke PHP long polling-patroon problematisch is
Een veelvoorkomend PHP-recept voor long polling ziet er ongeveer zo uit: "verhoog max_execution_time, sluit de sessie af en herhaal vervolgens een lus met een sleep() terwijl er naar nieuwe gegevens wordt gezocht. Conceptueel gezien is het eenvoudig: je voorkomt dat PHP te vroeg een time-out geeft, je maakt de sessievergrendeling vrij zodat andere verzoeken van dezelfde gebruiker kunnen worden uitgevoerd, en vervolgens controleer je in een lus gedurende maximaal ~300 seconden op nieuwe berichten.
Binnen die lus zou je code het volgende kunnen doen: De database opvragen of controleer bij elke iteratie een in-memory cache, met een pauze van ongeveer een seconde. sleep(1) om te voorkomen dat de backend overbelast raakt. Als er een nieuwe melding binnenkomt, onderbreek je de lus, verstuur je het antwoord en beëindig je het script; als de tijdslimiet is bereikt zonder nieuwe gegevens, stuur je een lege array of een markering "geen updates" terug.
Aan de clientzijde een beetje JavaScript (meestal via $.ajax() in jQuery of fetch() (in pure JavaScript) roept dit eindpunt herhaaldelijk aan. Zodra de browser een reactie ontvangt (gegevens of niets), wacht hij een paar seconden en stuurt vervolgens direct een nieuwe, langdurige pollingaanvraag. Dit proces blijft in feite oneindig doorgaan zolang de gebruiker op de pagina blijft.
Hoewel dit patroon werkt voor een kleine gebruikersgroep, loopt het al snel tegen zijn grenzen aan, omdat elk wachtend verzoek een volledige PHP-worker in beslag neemt. Bij een Apache prefork- of PHP-FPM-configuratie gebruikt elke geblokkeerde scriptinstantie RAM en resources gedurende de hele tijd dat deze inactief is. Dit betekent dat zelfs 30-40 gelijktijdige clients merkbaar kunnen zijn, en dat meer dan 100 clients gevaarlijk worden zonder zorgvuldige afstemming.
Erger nog, het is gemakkelijk om te misverstaan wat de sleep() wat het gesprek daadwerkelijk doet. Vanuit het perspectief van het besturingssysteem doet je PHP-thread tijdens die slaapstand letterlijk niets productiefs, maar wordt deze toch beschouwd als een actieve worker die niet opnieuw kan worden gebruikt voor andere verzoeken.
Threads, processen en het webservermodel
Om het long polling-probleem in PHP echt te begrijpen, moet je kijken naar hoe je webserver verbindingen en workerprocessen beheert. Traditionele Apache prefork start meerdere processen, waarbij elk proces één verzoek tegelijk afhandelt; andere MPM's of PHP-FPM gebruiken pools van workers met een vergelijkbaar patroon van één verzoek per worker.
Als elke client die langdurig polling toepast een verzoek minutenlang openhoudt, raakt die beperkte pool van PHP-workers snel uitgeput. Ze zitten allemaal grotendeels inactief, blokkeren geheugen en voorkomen dat er nog meer verkeer kan worden verwerkt zodra het geconfigureerde maximum is bereikt.
Vergelijk dit met systemen die gebouwd zijn rond niet-blokkerende I/O en gebeurtenisloops, waarbij een enkele OS-thread duizenden gelijktijdige verbindingen kan afhandelen, zolang de meeste daarvan maar inactief zijn. In die wereld wacht er inderdaad "iets" binnen de OS-stack, maar het is geen zwaarwegend gebruikersproces per verbinding.
Nginx is een goed voorbeeld aan de HTTP-kant: het gebruikt een gebeurtenisgestuurde architectuur om enorme aantallen open verbindingen te beheren met zeer weinig geheugenoverhead. Wanneer je PHP via FastCGI of PHP-FPM met Nginx verbindt, kan Nginx clientverbindingen actief houden en verzoeken verdelen over een pool van PHP-workers met een vaste grootte. Dit geeft wat extra ademruimte, maar lost blokkerende PHP-scripts niet op magische wijze op.
Daarom is de simpele mantra "elke lange polling blokkeert een thread" weliswaar een oversimplificatie, maar nog steeds pijnlijk accuraat voor veel klassieke PHP-implementaties. Tenzij je een asynchrone runtime of een andere architectuur gebruikt, wordt een typisch PHP-script synchroon uitgevoerd en bezet het een worker zolang het actief is.
Is Node.js hier echt zo bijzonder?
Node.js wordt vaak aangehaald als een magische oplossing omdat het standaard gebruikmaakt van een single-threaded event loop en niet-blokkerende I/O. In plaats van voor elke verbinding een aparte thread te starten, houdt Node gelijktijdig veel open sockets bij en voert het pas daadwerkelijk werk uit wanneer er data binnenkomt of een gebeurtenis plaatsvindt.
Deze architectonische keuze maakt het veel gemakkelijker om een enorm aantal inactieve long polling- of WebSocket-verbindingen te ondersteunen op bescheiden hardware. Wanneer er geen berichten worden verzonden, is de event loop van Node nog steeds actief, maar werkt deze nauwelijks, en het RAM-gebruik per verbinding is minimaal in vergelijking met een klassieke PHP-opstelling waarbij elke aanvraag een aparte worker heeft.
PHP is echter niet volledig uitgesloten van dit spel; het beschikt ook over moderne event loop-bibliotheken die vergelijkbaar niet-blokkerend gedrag bieden. Projecten zoals ReactPHP, Amp of Revolt bieden een gebeurtenisgestuurde runtime binnen PHP, waarmee sockets of asynchrone taken kunnen worden beheerd zonder dat er per verbinding een blokkerende worker hoeft te worden opgestart.
In de praktijk draait het merendeel van de oudere PHP-applicaties echter nog steeds synchroon met Apache of PHP-FPM en zonder event loop. Voor die apps is de reputatie dat "Node beter is in long polling" grotendeels terecht, omdat je je PHP-stack aanzienlijk zou moeten herontwerpen om een vergelijkbare schaalbaarheid te bereiken.
Hoe lang duurt polling in vergelijking met WebSockets en SSE?
Long polling is slechts één manier om gegevens van de server naar de client te sturen; WebSockets en Server-Sent Events (SSE) zijn vaak beter geschikt voor moderne realtime-applicaties. Elke techniek kent zijn eigen voor- en nadelen wat betreft complexiteit, mogelijkheden en resourceverbruik.
WebSockets leggen een echt bidirectioneel kanaal tot stand tussen client en server via één enkele, geüpgrade TCP-verbinding. Zodra de upgrade-handshake is voltooid, kunnen beide partijen naar believen berichten verzenden zonder de extra belasting van HTTP-headers, wat een enorm voordeel is voor chat-apps, multiplayergames, dashboards en elk scenario met frequente updates.
SSE biedt daarentegen eenrichtingsverkeer van gebeurtenissen van server naar client via een langdurige HTTP-verbinding. Het is zeer geschikt voor notificaties, live feeds of situaties waarin alleen de server gegevens hoeft te versturen en de client zelden informatie terugstuurt na het initiële verzoek.
Long polling zit er ergens tussenin: het simuleert server push met herhaalde HTTP-verzoeken, waardoor je nog steeds te maken hebt met verbindings- en headerkosten bij elke aanvraag. Het voordeel is dat het werkt met een standaard HTTP-infrastructuur en gangbare browsers, zonder extra protocollen of speciale clientondersteuning.
Veel realtimebibliotheken zoals Socket.IO beginnen eigenlijk met long polling en upgraden vervolgens naar WebSockets wanneer dat mogelijk is, waarbij long polling als een terugvaloptie wordt beschouwd in plaats van het primaire mechanisme. Dat zegt veel over de relatieve efficiëntie van long polling op grote schaal.
Beveiligingsaspecten voor endpoints met lange pollingfrequentie
Hoewel long polling misschien aanvoelt als een technisch detail, is elk long polling-eindpunt in wezen niets meer dan een HTTP API-interface die goed beveiligd moet worden. De eerste, ononderhandelbare stap is om de dienst uitsluitend via HTTPS aan te bieden, zodat het verkeer onderweg niet kan worden onderschept of gemanipuleerd.
Naast transportbeveiliging heb je strikte authenticatie en autorisatie nodig voor alle langdurige pollingverzoeken. Of je nu sessiecookies, JWT's, API-tokens of OAuth gebruikt, de server moet controleren of elke open verbinding overeenkomt met een geldige gebruiker en of de gebruiker gemachtigd is om de gevraagde datastroom te ontvangen.
Sommige klassieke beveiligingsproblemen van browsers, zoals CSRF, zijn mogelijk minder relevant als u niet afhankelijk bent van impliciete authenticatie op basis van cookies via standaardformulieren, maar u moet nog steeds rekening houden met uw specifieke context. Als er cookies bij betrokken zijn of als het eindpunt statuswijzigingen kan veroorzaken, blijven anti-CSRF-beveiligingsmaatregelen (tokens, same-site cookies, enz.) belangrijk.
Inputvalidatie is voor long polling net zo cruciaal als voor elke andere HTTP API. Parameters zoals kanaal-ID's, gebruikers-ID's, filters of tijdstempels moeten op de server worden gecontroleerd en gevalideerd om SQL-injectie, path traversal of logische fouten te voorkomen die gegevens tussen gebruikers kunnen lekken.
Long polling vergroot ook de kans op denial-of-service-aanvallen, omdat verbindingen in PHP opzettelijk langdurig en relatief kostbaar zijn. U dient redelijke snelheidslimieten per IP-adres of per account in te stellen, het aantal gelijktijdige verbindingen te beperken en verbindingstime-outs toe te passen om het resourcegebruik onder controle te houden.
Continue monitoring, logging en periodieke beveiligingsaudits vormen de laatste verdedigingslinie. Door fouten bij langdurige polling, authenticatiefouten en ongebruikelijke verbindingspatronen te registreren, beschikt u over de gegevens die u nodig hebt om misbruik, regressies of configuratieproblemen te detecteren voordat ze escaleren onder druk van het daadwerkelijke verkeer.
Foutafhandeling en veerkracht bij long polling
Omdat long polling afhankelijk is van veel langdurige verbindingen, is robuuste foutafhandeling cruciaal om een kettingreactie van storingen of vastgelopen clients te voorkomen. Begin met het instellen van een realistische time-out aan de serverzijde voor elk verzoek, zodat een ontbrekende gebeurtenis er niet toe leidt dat verbindingen voor altijd blijven hangen.
Als de time-out is bereikt zonder dat er nieuwe gegevens zijn ontvangen, moet de server reageren met een duidelijke, goed gedefinieerde payload. Dat kan een lege lijst zijn, een specifieke JSON-structuur of een HTTP 204-status, maar het moet voorspelbaar zijn, zodat de client "nog geen gegevens" kan onderscheiden van echte fouten.
Bij daadwerkelijke serverproblemen – zoals databasestoringen, interne uitzonderingen of ongeldige parameters – is het belangrijk om accurate HTTP-statuscodes te verzenden. Foutcodes zoals 500 (serverfout), 404 (bron niet gevonden) of 401/403 (authenticatieproblemen) stellen de client in staat om adequaat te reageren in plaats van blindelings opnieuw te proberen.
Aan de clientzijde is automatische herhalingslogica met exponentiële backoff vrijwel onmisbaar voor long polling. Als een verzoek onverwacht mislukt of een time-out geeft, moet de client even wachten voordat het volgende verzoek wordt verzonden. Bij herhaalde mislukkingen moet de wachttijd worden verlengd om te voorkomen dat de backend overbelast raakt.
Gezondheidscontroles en het beheer van de verbindingsstatus maken ook deel uit van een goed ontwerp. Als de client een netwerkverlies of herhaalde serverfouten detecteert, kan deze overschakelen naar een eenvoudiger terugvalmechanisme zoals short polling of realtimefuncties uitschakelen, terwijl er een vriendelijke melding aan de gebruiker wordt getoond.
Tot slot moet al dit gedrag waarneembaar zijn: registreer fouten, time-outs en herhalingspatronen, en gebruik die logs en statistieken vervolgens om time-outs, backoff-strategieën en infrastructuurcapaciteit te optimaliseren. Langdurig pollen dat stilletjes mislukt, is een van de snelste manieren om boze gebruikers en ongediagnosticeerde prestatieproblemen te veroorzaken.
Schaalbaarheid, prestaties en optimalisatiestrategieën
Standaard schaalt de naïeve PHP long polling-implementatie niet goed, maar er zijn genoeg instellingen die je kunt aanpassen voordat je het helemaal opgeeft. Het doel is om de kosten per aansluiting te verlagen en uw infrastructuur efficiënter te benutten.
Een van de handigste trucs is om reacties te bundelen in plaats van één bericht per HTTP-reactie te versturen. Als er meerdere gebeurtenissen binnenkomen tijdens één lange pollingperiode, voeg deze dan samen tot één payload om de HTTP-overhead te spreiden en het aantal herverbindingen te verminderen.
Compressie kan ook een aanzienlijk verschil maken, met name bij omvangrijke JSON-gegevens. Door Gzip (of een vergelijkbaar compressiealgoritme) in te schakelen op de webserver of in PHP, worden de bestandsgroottes verkleind, de levering versneld en het bandbreedteverbruik verminderd, wat merkbaar is bij grotere schaal.
Caching mag niet over het hoofd worden gezien: een speciale cachelaag kan veel herhaald werk opvangen dat anders uw database of microservices zou belasten. Als veel gebruikers zich abonneren op vergelijkbare streams, kunnen gecachede momentopnamen of berekende aggregaties de verwerkingstijd per verzoek aanzienlijk verkorten.
Wat de verbindingen betreft, zijn pooling en hergebruik vooral belangrijk voor backend-afhankelijkheden zoals databases of externe API's. Door databaseverbindingen open te houden en opnieuw te gebruiken in plaats van bij elke polling opnieuw verbinding te maken, kunnen de latentie en de CPU-belasting worden verminderd, met name bij zware gelijktijdigheid.
Snelheidsbeperking en bandbreedtebeperking vervullen twee functies: ze beschermen uw infrastructuur tegen misbruik en helpen de prestaties onder belasting voorspelbaar te houden. Door te beperken hoe vaak een bepaalde gebruiker of IP-adres lange pollingverbindingen kan openen, verkleint u het risico op uitputting van resources en creëert u ruimte voor eerlijk gebruik.
Load balancing over meerdere applicatieservers is een ander krachtig middel. Door lange pollingverzoeken over meerdere knooppunten te verdelen, wordt voorkomen dat één enkele machine een knelpunt wordt, vooral in combinatie met sticky sessions of externe statusopslag voor gebruikersabonnementen.
Asynchrone verwerking en achtergrondprocessen moeten alles afhandelen wat niet strikt onderdeel is van de "wacht op gebeurtenis, verstuur gebeurtenis"-cyclus. Berichtwachtrijen, taakverwerkers en gedistribueerde systemen zorgen ervoor dat uw endpoint met lange pollingfrequentie efficiënt en responsief blijft, terwijl het zware werk elders plaatsvindt.
De juiste verbindings- en scripttime-outs vormen de laatste veiligheidskleppen. Sluit inactieve of vastgelopen verbindingen na een redelijke tijd af en houd ze gesloten. max_execution_time Zorg ervoor dat dit aansluit bij uw logica voor lange polling en geef expliciet aan hoe lang zowel de server als de client mogen wachten.
PHP-specifieke implementatietips voor long polling
Bij het implementeren van long polling in pure PHP maken een paar configuratie- en codedetails een groot verschil voor het gedrag en de stabiliteit. Een van de grote jongens belt. session_write_close() zo vroeg mogelijk in het script.
De standaard sessiehandler van PHP maakt gebruik van bestandsvergrendelingen, wat betekent dat een verzoek dat de sessie openhoudt, andere verzoeken van dezelfde gebruiker kan blokkeren. Door de schrijfsessie te sluiten, worden vergrendelingen vrijgegeven, terwijl leesrechten voor sessiegegevens behouden blijven. Zo wordt voorkomen dat extra parallelle verzoeken zich ophopen achter de lange polling.
U zult doorgaans ook de verhoging of overschrijding moeten uitvoeren. max_execution_time Stel een limiet in om scripts 60, 120 of 300 seconden te laten draaien. Zonder die aanpassing kan PHP het script beëindigen voordat uw lange polling-loop is voltooid, wat kan leiden tot verwarrende fouten aan de clientzijde of gedeeltelijk afgeleverde reacties.
Wees binnen de lus zeer voorzichtig met hoe vaak je de database of andere backends benadert. Een strakke lus die elke 100 milliseconden de database opvraagt, zal uw database zelfs bij een matige belasting overbelasten; introduceer verstandige pauzes, caches of push-achtige triggers om het systeem responsief te houden.
Het is ook de moeite waard om na te denken over logging en meetwaarden binnen deze lus. Houd bij hoe vaak je vastloopt door time-outs in vergelijking met de werkelijke gegevens, wat de gemiddelde wachttijd is en hoeveel gelijktijdige lange pollingprocessen je uitvoert. Gebruik deze cijfers vervolgens voor capaciteitsplanning en codeoptimalisatie.
Houd er vooral rekening mee dat elk blokkerend PHP-script overeenkomt met een worker. Het minimaliseren van lussen, pauzes en onnodig werk is daarom essentieel als u meer dan een klein aantal gebruikers wilt ondersteunen. Voor interne tools of apps met weinig verkeer is dit wellicht prima; voor grotere projecten is een robuustere architectuur echter aan te raden.
Patronen uit de praktijk, bibliotheken en alternatieven
Veel ontwikkelaars ontdekken long polling via kleine demo's: een PHP-script houdt een tekstbestand in de gaten, en wanneer je dat bestand bewerkt, verschijnt de wijziging direct in de browser. Dit is een geweldig mentaal model: eenvoudige code, duidelijk gedrag en directe feedback.
In een productieomgeving loopt dat triviale voorbeeld al snel tegen de door ons besproken beperkingen aan, maar het illustreert nog steeds het basisprotocol. Een JavaScript-client verstuurt een AJAX-verzoek, het PHP-script blokkeert totdat het bestand is gewijzigd of een time-out is bereikt, waarna het reageert en het proces zich herhaalt.
Specifiek voor PHP-ecosystemen zijn er diverse frameworks en patronen die dit beheersbaarder proberen te maken. Laravel stimuleert ontwikkelaars bijvoorbeeld om gebeurtenissen via WebSockets of beheerde services te verzenden, hoewel je nog steeds handmatig lange pollingroutes kunt configureren.
Buiten PHP zijn er in vrijwel elke programmeertaal volwaardige frameworks die long polling direct ondersteunen of een betere abstractie bieden rondom realtime communicatie. Node.js met Express.js of Socket.IO, Python met Flask of Django Channels, Java met Spring, Ruby on Rails en .NET met ASP.NET SignalR zijn allemaal populaire keuzes.
Sommige platforms verbergen het hele schaalbaarheids- en verbindingsprobleem volledig voor je. Beheerde realtimediensten – waaronder diensten die zich richten op publiceren/abonneren-berichtenverkeer en aanwezigheidsstatus – bieden client-SDK's, encryptie, gedetailleerde toegangscontrole en een wereldwijde infrastructuur om miljoenen gelijktijdige verbindingen af te handelen, zodat u het wiel niet opnieuw hoeft uit te vinden.
In de PHP-wereld kun je vaak het beste van twee werelden combineren door je bestaande applicatielogica te combineren met zo'n realtime service. PHP blijft verantwoordelijk voor bedrijfsregels, persistentie en API's, terwijl het externe platform de langdurige verbindingen, fan-out en realtime levering via long polling, SSE of WebSockets afhandelt, al naar gelang de situatie.
Andere ecosystemen geven deze realtime-strategieën namen zoals Comet, Reverse Ajax, HTTP Streaming, Pushlet of AJAX long polling. In essentie zijn het allemaal variaties op hetzelfde idee: een protocol dat in principe gebaseerd is op verzoek en antwoord, omzetten in iets dat aanvoelt als een push-protocol.
Voor PHP-ontwikkelaars die worstelen met long polling-problemen, is het essentieel om eerlijk te beoordelen wat de vereisten zijn op het gebied van gelijktijdigheid, de hostingomgeving en hoeveel complexiteit men bereid is te accepteren. Soms is een simpele blokkerende lus voldoende; in andere gevallen is het beter om een event loop-bibliotheek te gebruiken, push-verzoeken uit te besteden aan een aparte service of een deel van je stack over te schakelen naar een technologie die geschikt is voor een enorm aantal open verbindingen.
Als je al deze elementen combineert – HTTP-mechanismen, het uitvoeringsmodel van PHP, serverarchitectuur, beveiliging, foutafhandeling en schaalbare ontwerppatronen – dan is long polling niet langer een mysterieuze prestatiekiller, maar gewoon een hulpmiddel dat je bewust kunt inzetten waar het zinvol is.
