Connection-Pooling für Redis-Clients richtig konfigurieren

1. Warum der Verbindungsaufbau zu Redis teuer ist

Eine neue TCP-Verbindung erfordert einen Drei-Wege-Handshake zwischen Client und Server, bevor überhaupt ein einziges Byte an Nutzdaten übertragen werden kann. Innerhalb eines Rechenzentrums mit sehr niedriger Latenz fällt das kaum ins Gewicht, aber bei jeder Anfrage, die eine neue Verbindung aufbaut, statt eine bestehende wiederzuverwenden, summiert sich dieser Overhead über viele Requests hinweg zu einer spürbaren Gesamtverzögerung, besonders in Umgebungen mit vielen kurzlebigen Prozessen wie klassischen PHP-FPM-Workern.

Deutlich teurer wird der Verbindungsaufbau, sobald TLS im Spiel ist, was für Redis-Verbindungen über unsichere Netzwerke oder zu Managed-Redis-Diensten in der Cloud der Standard ist. Zusätzlich zum TCP-Handshake muss ein TLS-Handshake mit Zertifikatsprüfung und Schlüsselaustausch erfolgen, der je nach Konfiguration mehrere zusätzliche Netzwerk-Roundtrips benötigt. Bei einer Verbindung mit einer Round-Trip-Zeit von wenigen Millisekundern kann allein der TLS-Handshake mehr Zeit kosten als mehrere anschließende Redis-Commands zusammen.

2. Wie Connection-Pooling das Problem löst

Ein Connection-Pool hält eine Menge bereits aufgebauter, authentifizierter Verbindungen zum Redis-Server bereit und verleiht sie an anfragende Threads oder Prozesse, statt bei jeder Anfrage eine neue Verbindung von Grund auf aufzubauen. Nach Abschluss der Operation wird die Verbindung nicht geschlossen, sondern an den Pool zurückgegeben und steht für die nächste Anfrage sofort wieder zur Verfügung. Der teure Verbindungsaufbau inklusive TLS-Handshake fällt damit nur einmal pro Verbindung an, nicht einmal pro Anfrage.

In Umgebungen mit persistenten Prozessen, etwa einem lang laufenden Node.js-Server oder einem Python-Worker-Prozess, lässt sich ein Pool über die gesamte Lebensdauer des Prozesses hinweg wiederverwenden. In Umgebungen mit kurzlebigen Prozessen pro Request, wie klassischem PHP-FPM ohne persistente Verbindungen, ist echtes Pooling über Prozessgrenzen hinweg schwieriger und erfordert entweder persistente Verbindungen über pconnect oder einen externen Verbindungs-Proxy wie einen dedizierten Connection-Pooler.

import redis

# Pool einmalig beim Anwendungsstart erzeugen, NICHT pro Request
pool = redis.ConnectionPool(
    host="cache.internal",
    port=6379,
    max_connections=50,
    socket_connect_timeout=2,
    socket_timeout=3,
)

# Jeder Client-Aufruf leiht sich eine Verbindung aus dem Pool aus
r = redis.Redis(connection_pool=pool)
r.get("produkt:1234")

3. Fallstrick: eine zu klein dimensionierte Pool-Größe

Wird die maximale Pool-Größe zu niedrig angesetzt, müssen anfragende Threads warten, bis eine Verbindung frei wird, sobald die Anzahl gleichzeitiger Redis-Operationen die Pool-Größe übersteigt. Diese Wartezeit ist in Monitoring-Tools oft schwer von echter Redis-Latenz zu unterscheiden, weil sie clientseitig entsteht und nicht in der Server-Verarbeitungszeit auftaucht. Das Ergebnis sind rätselhaft wirkende Latenzspitzen, die verschwinden, sobald der Pool vergrößert wird, obwohl der Redis-Server selbst die ganze Zeit über freie Kapazität hatte.

Besonders in Umgebungen mit hoher Parallelität, etwa einem Webserver mit vielen gleichzeitigen Worker-Threads, die alle Redis für Session-Zugriffe nutzen, zeigt sich dieses Muster deutlich: Unter niedriger Last läuft alles einwandfrei, weil selten mehr Anfragen als Pool-Verbindungen gleichzeitig anstehen. Sobald aber die Last steigt, etwa bei einem Traffic-Peak im Onlineshop, wachsen die Wartezeiten für freie Pool-Verbindungen überproportional an, ein klassisches Symptom für Warteschlangen-Effekte bei begrenzter Ressourcenzahl.

4. Fallstrick: eine zu großzügig dimensionierte Pool-Größe

Das gegenteilige Extrem ist ebenso problematisch. Jede offene Verbindung verbraucht auf dem Redis-Server Arbeitsspeicher für Verbindungspuffer und belegt einen Dateideskriptor im Betriebssystem. Wird der Pool großzügig überdimensioniert, etwa mehrere hundert Verbindungen pro Anwendungsinstanz, und läuft diese Anwendung zusätzlich in vielen parallelen Instanzen, etwa hinter einem Kubernetes-Deployment mit zwanzig Pods, summiert sich das schnell zu tausenden gleichzeitiger Verbindungen auf einem einzigen Redis-Server.

Der Redis-Server begrenzt die Anzahl gleichzeitiger Verbindungen über die Konfigurationsoption maxclients, standardmäßig 10000. Wird dieses Limit erreicht, lehnt Redis neue Verbindungsversuche mit einer expliziten Fehlermeldung ab, was bei einem plötzlichen Anstieg der Instanzzahl, etwa bei einem automatischen horizontalen Skalierungsereignis, zu Verbindungsfehlern führen kann, die schwer zu diagnostizieren sind, weil der eigentliche Redis-Server dabei gar nicht überlastet im Sinne von CPU oder Speicher sein muss.

# Aktuelle Verbindungszahl und Limit prüfen
redis-cli INFO clients | grep -E "connected_clients|maxclients"
# connected_clients:842
# maxclients:10000

redis-cli CONFIG GET maxclients

5. Die richtige Pool-Größe berechnen

Eine sinnvolle Ausgangsgröße ergibt sich aus der erwarteten Anzahl gleichzeitig aktiver Anfragen, multipliziert mit einem moderaten Sicherheitspuffer, nicht aus einer willkürlich hoch gegriffenen Zahl. Für einen Webserver mit einer bekannten maximalen Anzahl paralleler Worker-Prozesse oder Threads bietet sich als erste Näherung eine Pool-Größe an, die der maximalen Worker-Anzahl entspricht, da im Regelfall nicht mehr als ein Redis-Aufruf pro aktivem Worker gleichzeitig ansteht.

Wichtig ist dabei die Gesamtbetrachtung über alle Anwendungsinstanzen hinweg: Bei zehn parallel laufenden Anwendungsinstanzen mit jeweils einem Pool von fünfzig Verbindungen ergeben sich in der Spitze fünfhundert gleichzeitige Verbindungen zum selben Redis-Server. Diese Gesamtzahl sollte immer gegen maxclients und die tatsächlich verfügbare Server-Kapazität gepruft werden, nicht nur gegen die Pool-Größe einer einzelnen Instanz isoliert betrachtet.

# Faustregel: Pool-Größe ~ maximale parallele Worker pro Instanz
# Bei 10 Instanzen mit je 50 Worker-Threads: 500 Verbindungen gesamt

pool = redis.ConnectionPool(
    host="cache.internal",
    port=6379,
    max_connections=50,       # pro Anwendungsinstanz
    socket_connect_timeout=2,
    socket_timeout=3,
    health_check_interval=30,
)

6. Timeout-Konfiguration: connect_timeout vs. socket_timeout

Ein häufig übersehener Unterschied liegt zwischen dem Timeout für den Verbindungsaufbau selbst und dem Timeout für eine einzelne Operation über eine bereits bestehende Verbindung. Der connect_timeout bestimmt, wie lange der Client wartet, bis der TCP- und gegebenenfalls TLS-Handshake abgeschlossen ist, bevor er den Verbindungsversuch als fehlgeschlagen betrachtet. Ein zu hoch gesetzter Wert lässt die Anwendung bei einem nicht erreichbaren Redis-Server unnötig lange hängen, bevor ein Fehler zurückgegeben wird.

Der socket_timeout hingegen bestimmt, wie lange auf die Antwort eines einzelnen Commands über eine bereits etablierte Verbindung gewartet wird. Dieser Wert sollte großzügiger bemessen sein als der connect_timeout, aber trotzdem realistisch begrenzt bleiben, damit ein einzelner, ungewöhnlich langsamer Command, etwa ein KEYS-Aufruf auf einer großen Datenbank, nicht die gesamte Anwendung für beliebig lange Zeit blockiert. Beide Werte gemeinsam bestimmen, wie schnell eine Anwendung auf einen gestörten oder überlasteten Redis-Server reagiert und in einen kontrollierten Fehlerzustand wechselt.

7. Health-Check-Konfiguration für den Pool

Verbindungen in einem Pool können mit der Zeit ungültig werden, ohne dass der Client das sofort bemerkt, etwa weil ein zwischengeschalteter Load Balancer, eine Firewall oder ein Netzwerk-Proxy eine inaktive Verbindung nach einer gewissen Leerlaufzeit stillschweigend trennt. Ohne Health-Checks liefert der Pool eine solche tote Verbindung an die nächste Anfrage aus, was zu einem Fehler führt, obwohl der Redis-Server selbst völlig gesund ist.

Die Option health_check_interval in vielen Client-Bibliotheken sorgt dafür, dass Verbindungen, die länger als das konfigurierte Intervall im Leerlauf waren, vor der nächsten Nutzung mit einem leichten PING-Befehl geprüft werden. Schlägt dieser PING fehl, entfernt der Pool die Verbindung und baut bei Bedarf eine neue auf, statt die tote Verbindung an Anwendungscode weiterzureichen. Dieser Mechanismus verhindert insbesondere in Cloud-Umgebungen mit aggressiven Idle-Timeouts an zwischengeschalteten Netzwerkkomponenten schwer reproduzierbare, sporadische Verbindungsfehler.

# Health-Check gegen stille Idle-Timeouts von Load Balancern/Firewalls
pool = redis.ConnectionPool(
    host="cache.internal",
    port=6379,
    max_connections=50,
    health_check_interval=30,   # PING bei Leerlauf > 30s vor Wiederverwendung
    retry_on_timeout=True,
)

8. TLS-spezifische Aspekte des Pooling

Bei TLS-verschlüsselten Redis-Verbindungen, etwa zu Managed-Redis-Angeboten in der Cloud, ist der Nutzen von Connection-Pooling noch ausgeprägter als bei unverschlüsselten Verbindungen, weil der zusätzliche TLS-Handshake den relativen Kostenanteil des Verbindungsaufbaus weiter erhöht. Gleichzeitig lohnt es sich, session_cache oder ähnliche TLS-Session-Resumption-Mechanismen zu prüfen, falls die verwendete Client-Bibliothek und der Server sie unterstützen, da diese den Handshake für neu aufgebaute Verbindungen zusätzlich beschleunigen können.

Ein weiterer TLS-spezifischer Punkt betrifft Zertifikatsvalidierung: Ist die Client-Konfiguration so eingestellt, dass bei jedem Verbindungsaufbau eine vollständige Zertifikatskette inklusive Sperrlistenprüfung validiert wird, kann das den Verbindungsaufbau zusätzlich verlangsamen. Ein großzügig dimensionierter, gut konfigurierter Pool reduziert die Häufigkeit, mit der dieser Overhead überhaupt anfällt, was den Effekt einer sauberen Pool-Konfiguration bei TLS-Verbindungen noch verstärkt.

9. Praxis-Fazit: Pool-Größe messen statt raten

Connection-Pooling ist bei Redis fast immer sinnvoll, aber die konkrete Pool-Größe sollte auf Basis realer Messwerte festgelegt werden, nicht auf Basis einer pauschal überall kopierten Zahl. Ein zu kleiner Pool erzeugt clientseitige Wartezeiten, die im Monitoring leicht mit echter Redis-Latenz verwechselt werden, ein zu großer Pool belastet den Server unnötig mit offenen Verbindungen und nähert sich im schlimmsten Fall dem maxclients-Limit.

In der Praxis bewährt sich ein iteratives Vorgehen: Mit einer konservativen Pool-Größe starten, connected_clients auf dem Server sowie Wartezeiten auf Client-Seite über Metriken beobachten, und die Größe gezielt anpassen, sobald Engpässe sichtbar werden. Kombiniert mit realistischen Timeouts und aktiviertem Health-Check-Intervall entsteht so eine robuste, gut nachvollziehbare Verbindungskonfiguration, statt einer im Blindflug gewählten Zahl.

10. Zusammenfassung

11. FAQ: Connection-Pooling