Long Polling & Server-Sent Events (SSE)
Also Known As
long poll
HTTP long polling
Comet
TL;DR
Server-side push techniques for PHP — long polling holds HTTP connections open until data is ready; SSE streams events over a persistent HTTP response.
Explanation
Long polling: the client makes a request, the server holds it open (sleeping/waiting) until new data is available or a timeout occurs, then responds and the client immediately reconnects. Simple to implement in PHP but holds a PHP-FPM worker for the duration — inefficient under load. Server-Sent Events (SSE): the server sends a text/event-stream response and pushes data: payloads down over a persistent connection using ob_flush() and flush(). SSE is one-directional (server to client) and reconnects automatically. Both approaches consume a PHP worker per open connection — for high concurrency, a Node.js/Go push service with Redis Pub/Sub as the backend is more scalable.
Diagram
sequenceDiagram
participant C as Client
participant S as Server
Note over C,S: Long Polling
C->>S: GET /events (holds connection)
Note over S: Waits for event...
S-->>C: Response when event ready
C->>S: Immediately reconnect
Note over C,S: Server-Sent Events (SSE)
C->>S: GET /stream (persistent)
S-->>C: data: event1
S-->>C: data: event2
Note over C,S: WebSocket - full duplex
C->>S: WS upgrade
S-->>C: push anytime
C->>S: send anytime
Common Misconception
✗ Long polling and WebSockets are equivalent for real-time data. Long polling holds an HTTP connection open until data is available then the client reconnects — each message incurs connection overhead. WebSockets maintain a persistent bidirectional connection with far lower per-message latency.
Why It Matters
Long polling holds an HTTP connection open until data is available, giving near-real-time updates without WebSockets — but ties up server connections and requires careful timeout handling.
Common Mistakes
- Not setting a server-side timeout — a connection held indefinitely exhausts worker threads.
- Not handling the client reconnect loop — when the server responds, the client must immediately re-poll.
- Using long polling when WebSockets or SSE are available and more efficient for the use case.
- Not tracking which clients are waiting and what data they have already seen — sending duplicate events.
Code Examples
✗ Vulnerable
// Long poll without timeout — holds worker indefinitely:
set_time_limit(0); // Dangerous — worker never freed
while (true) {
$events = getNewEvents($lastId);
if (!empty($events)) { echo json_encode($events); exit; }
sleep(1);
}
// Fix: set_time_limit(30); respond with empty after timeout so client reconnects
✓ Fixed
// SSE in PHP
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
while (true) {
echo 'data: ' . json_encode(getUpdate()) . "\n\n";
ob_flush(); flush();
sleep(1);
}
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
27
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 6
Perplexity 6
Google 2
Unknown AI 2
Ahrefs 2
SEMrush 2
ChatGPT 2
Majestic 1
Also referenced
How they use it
crawler 21
crawler_json 2
Related categories
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: Medium
⚡ Quick Fix
Use Server-Sent Events instead of long polling for PHP — SSE is simpler, uses one connection, and auto-reconnects; long polling creates a new HTTP connection for every update which wastes resources
📦 Applies To
PHP 5.0+
web
🔗 Prerequisites
🔍 Detection Hints
JavaScript polling every second with Ajax; PHP holding connection open without SSE; repeated short-interval fetch calls instead of push
Auto-detectable:
✗ No
⚠ Related Problems
🤖 AI Agent
Confidence: Medium
False Positives: Medium
✗ Manual fix
Fix: Medium
Context: File
Tests: Update