Long polling vs WebSocket in PHP: Was für Echtzeit-Projekte wählen?

Einleitung: Warum Ihre Website in Echtzeit „lahmt“?

Stellen Sie sich vor, Sie besuchen eine Börsenseite, und der Dollarkurs aktualisiert sich erst nach einem Seitenneuladen. Oder Sie senden eine Nachricht im Chat, und Ihr Gesprächspartner sieht sie erst nach 10 Sekunden. Kommt Ihnen bekannt vor? Das ist der Schmerz eines jeden Entwicklers, der versucht, eine Anwendung „lebendig“ zu machen.

In der Welt von PHP, wo jede Anfrage ein kurzes Leben hat, ist die Implementierung von Echtzeit-Funktionen eine nicht triviale Aufgabe. Die beiden wichtigsten Ansätze, die zur Hilfe kommen, sind Long polling und WebSocket. Welchen sollten Sie für Ihr PHP-Projekt wählen? Lassen Sie es uns ohne Umschweife mit lebendigen Codebeispielen analysieren.

Was ist Long polling in PHP? Eine lange Anfrage mit einem Geheimnis

Long polling ist ein eleganter Trick, der es ermöglicht, eine Echtzeit-Verbindung unter Verwendung gewöhnlicher HTTP-Anfragen zu simulieren. Der Client sendet eine Anfrage an den Server, aber der Server antwortet nicht sofort. Er hält die Verbindung offen, bis ein neues Ereignis eintritt (z. B. eine neue Nachricht im Chat). Sobald das Ereignis eintritt, sendet der Server eine Antwort, der Client verarbeitet sie und erstellt sofort eine neue „lange“ Anfrage.

Wie es in PHP funktioniert: Ein einfaches Beispiel

Angenommen, wir haben einen einfachen Chat. Der Client sendet eine AJAX-Anfrage an ein PHP-Skript, das in einer Schleife „hängt“, bis eine neue Nachricht in der Datenbank erscheint.

<?php\n// long_polling.php\nheader('Content-Type: application/json');\nheader('Cache-Control: no-cache');\n\n$lastMessageId = $_GET['last_id'] ?? 0;\n$timeout = 30; // warte bis zu 30 Sekunden\n$startTime = time();\n\nwhile (time() - $startTime < $timeout) {\n    // Simuliere eine DB-Prüfung (in der Realität - eine Abfrage an MySQL/PostgreSQL)\n    $newMessages = getNewMessagesFromDB($lastMessageId);\n    \n    if (!empty($newMessages)) {\n        echo json_encode([\n            'status' => 'success',\n            'messages' => $newMessages\n        ]);\n        exit;\n    }\n    \n    // Schlafe 1 Sekunde, um die CPU nicht zu belasten\n    sleep(1);\n}\n\n// Wenn in 30 Sekunden nichts kam\necho json_encode(['status' => 'timeout', 'messages' => []]);\nexit;\n?>

Auf dem Client (JavaScript) sieht das so aus:

function startLongPolling(lastId) {\n    fetch('/long_polling.php?last_id=' + lastId)\n        .then(response => response.json())\n        .then(data => {\n            if (data.status === 'success') {\n                data.messages.forEach(msg => addMessageToChat(msg));\n                startLongPolling(data.messages[data.messages.length - 1].id);\n            } else {\n                startLongPolling(lastId); // Timeout — einfach neu starten\n            }\n        })\n        .catch(() => setTimeout(() => startLongPolling(lastId), 1000));\n}\n

Vorteile von Long polling in PHP

\n
• Einfachheit der Implementierung — keine zusätzlichen Server oder Bibliotheken nötig. Alles funktioniert auf normalem Apache/Nginx + PHP-FPM.
\n
• Kompatibilität — funktioniert überall, wo es HTTP gibt. Keine Probleme mit Proxys, Unternehmens-Firewalls.
\n
• Niedrige Einstiegshürde — wenn Sie PHP und AJAX kennen, können Sie bereits Long polling umsetzen.
\n

Nachteile von Long polling

\n
• Serverlast — jede „lange“ Anfrage hält einen PHP-FPM-Prozess belegt. Bei 1000 Benutzern benötigen Sie 1000 Prozesse.
\n
• Latenz (Verzögerung) — minimale Verzögerung = 1 Sekunde (aufgrund von sleep). Wenn Sie sleep reduzieren, beginnt die CPU zu glühen.
\n
• Schwierigkeit der Skalierung — Long polling verträgt sich schlecht mit Lastverteilern (Benutzer müssen an einen bestimmten Server gebunden werden).
\n

WebSocket in PHP: Echte Echtzeit ohne Kompromisse

WebSocket ist ein vollwertiger bidirektionaler Kommunikationskanal über TCP. Nach dem Handshake über HTTP,