Verbindungspools

In diesem Thema wird beschrieben, wie Verbindungspools in Bigtable funktionieren, welche Auswirkungen die Größe des Verbindungspools auf eine Anwendung haben kann, die Bigtable verwendet, und wann Sie die Standardeinstellungen für den Verbindungspool ändern sollten.

Wenn Sie nach dem Lesen dieser Seite festgestellt haben, dass Sie die Größe Ihres Verbindungspools ändern sollten, finden Sie unter Verbindungspools konfigurieren Informationen zum Bestimmen der optimalen Größe und zum Ändern der Größe. Die Anzahl der Verbindungen in jedem Pool kann nur dann in Ihrem Code konfiguriert werden, wenn Sie die Go-, C++- oder Java-Clientbibliotheken für Cloud Bigtable verwenden.

Funktionsweise von Verbindungspools

Ein Verbindungspool, auch als Kanalpool bezeichnet, ist ein Cache aus Datenbankverbindungen, die zur Verbesserung der Verbindungslatenz und -leistung gemeinsam genutzt und wiederverwendet werden. Verbindungen werden in einem Round-Robin-System verwendet.

Wenn Sie Bigtable verwenden, erstellen Sie einen einzelnen Datenclient pro Anwendungsprozess. Jeder Client hat genau einen Verbindungspool. Jeder Verbindungspool enthält eine bestimmte Anzahl von gRPC-Verbindungen, die jeweils bis zu 100 gleichzeitige Streams verarbeiten können. Anfragen, die über diese Verbindungen gesendet werden, werden über die Google-Middleware weitergeleitet, die sie dann an Ihre Tabelle weiterleitet. Die Middleware-Ebene besteht aus vielen Instanzen mit Load-Balancing. Jede Anfrage wird über die Middleware-Instanz mit der höchsten Verfügbarkeit weitergeleitet.

Sie können sich eine Verbindung (oder einen Kanal) wie eine Autobahn mit bis zu 100 Spuren vorstellen. Jede Spur (Stream) kann jeweils nur ein Auto (Anfrage) enthalten. Das Limit von 100 gleichzeitigen Streams pro gRPC-Verbindung wird auf der Middleware-Ebene von Google erzwungen. Diese Anzahl kann nicht neu konfiguriert werden.

Eine Verbindung wird jede Stunde automatisch aktualisiert. Wenn eine Verbindung innerhalb von fünf Minuten keine Anfrage erhalten hat, löscht die Middleware die Verbindung automatisch und erstellt sie erst dann wieder, wenn eine zusätzliche Verbindung erforderlich ist.

Im Hintergrund hat jeder Kanal einen einzelnen Subkanal. Jeder Subkanal hat eine HTTP2-Verbindung, die TCP verwendet, um Anfragen in Byte umzuwandeln und diese über die Middleware an Ihre Tabelle zu senden. Dieser Prozess wird nahtlos vom Bigtable-Dienst ausgeführt und Sie müssen nichts konfigurieren, um dies zu erreichen.

Verbindungspools und Traffic

Auswirkungen von Verbindungspools auf die Leistung

Idealerweise sollten Sie genügend gRPC-Verbindungen haben, um Ihre Anfragen ohne Zwischenspeicherung zu verarbeiten. Sie sollten jedoch nicht so viele Verbindungen haben, dass sie aufgrund einer fehlenden Nutzung häufig unterbrochen werden.

Nicht genügend Verbindungen

Wenn ein Verbindungspool nicht genügend Verbindungen zur Verarbeitung des Traffics hat, beginnt die Middleware damit, Anfragen zwischenzuspeichern und in Warteschlangen zu platzieren. Die Zwischenspeicherung verlangsamt den Traffic, reduziert die Anzahl der Anfragen pro Sekunde und erhöht die Latenz bei Eingehen der Anfragen.

Zu viele Verbindungen

Wenn ein Pool zu viele Verbindungen hat, was bedeutet, dass einige der Verbindungen inaktiv sind, trennt die Middleware die inaktiven Verbindungen. Wenn neue Anfragen eingehen, die diese Verbindungen benötigen, werden sie wiederhergestellt. Dies bedeutet, dass Anfragen bei Erhöhung des Traffics zu einem serverseitigen Cache-Fehler führen können, was zusätzliche Arbeit und Latenz verursacht. Wenn dies aufgrund unterschiedlicher Traffic-Ebenen häufig der Fall ist, kann sich diese Aktivität als wahrgenommene Spitze bei der Extremwertlatenz auf der Clientseite bemerkbar machen.

Standardeinstellungen ändern

Die Standardgröße des Verbindungspools ist für die meisten Anwendungen geeignet und in den meisten Fällen muss sie nicht geändert werden. Abhängig von der Clientbibliothek, die Sie in Ihrer Anwendung verwenden, können Sie die Größe des Verbindungspools möglicherweise nicht ändern. Die Anzahl der Verbindungen in jedem Pool kann im Code nur konfiguriert werden, wenn Sie die Go-, C++- oder Java-Clientbibliotheken für Cloud Bigtable verwenden.

In der Regel hat ein idealer Verbindungspool mindestens die doppelte Anzahl von Verbindungen, die für die maximale Sättigung erforderlich sind. Dies schafft Raum für Trafficschwankungen. Wenn Sie beispielsweise vier Verbindungen haben und jede von ihnen die maximal mögliche Anzahl von Anfragen bearbeitet (100), sollten Sie die Anzahl der Anfragen pro Verbindung auf eine Zahl zwischen 10 und 50 senken. Die ideale Größe des Verbindungspools ist also mindestens doppelt so groß, also mindestens 8 Verbindungen.

Bei folgenden Anzeichen sollten Sie eine Änderung der Anzahl der Verbindungen im Pool in Betracht ziehen.

Niedriger Durchsatz kombiniert mit Spitzen bei der clientseitigen Extremwertlatenz

Wenn Ihr typischer Durchsatz relativ niedrig ist, z. B. weniger als eine Anfrage pro Sekunde und Verbindung, und Sie regelmäßig eine hohe Extremwertlatenz für Ihre Anwendung beobachten, senden Sie möglicherweise nicht genügend Traffic, um die Verbindungen aufrechtzuerhalten. In diesem Fall müssen Sie möglicherweise die Anzahl der Verbindungen im Pool verringern. Unter Verbindungspools konfigurieren erfahren Sie, wie Sie die richtige Anzahl ermitteln.

Zwischengespeicherte Anfragen

Wenn Sie feststellen, dass sich Anfragen auf der Clientseite stapeln, kann dies darauf hindeuten, dass Sie mehr gleichzeitige Anfragen senden, als der Verbindungspool verarbeiten kann. Berechnen Sie die optimale Anzahl von Anfragen und ändern Sie bei Bedarf den Code.

Wenn Sie feststellen möchten, ob sich Anfragen stapeln, können Sie mit OpenCensus den Unterschied zwischen den Messwerten grpc.io/client/started_rpcs und grpc.io/client/completed_rpcs prüfen.

Virtuelle Umgebung

In seltenen Fällen kann der Bigtable-Client nicht die Anzahl der CPUs bestimmen, die die Anwendung ausführt. Verbindungen werden dann so zugeordnet, als würde nur eine CPU verwendet. Dies kann beispielsweise der Fall sein, wenn Sie virtuelle CPU-Instanzen in Kubernetes oder Docker verwenden. Wenn dies offensichtlich ist, sollten Sie die Anzahl der Pools gemäß den Richtlinien entsprechend der QPS und Latenz Ihrer Anwendung konfigurieren.

Weitere Informationen