Grupos de conexión

En este tema se describe cómo funcionan los grupos de conexiones en Bigtable, el impacto que puede tener el tamaño de los grupos de conexiones en una aplicación que usa Bigtable y cuándo puede ser conveniente cambiar la configuración predeterminada de los grupos de conexiones.

Después de leer esta página, si decides que debes cambiar el tamaño del grupo de conexiones, consulta Configurar grupos de conexiones para saber cómo determinar el tamaño óptimo y cómo cambiarlo. El número de conexiones de cada grupo se puede configurar en el código solo cuando se usan las bibliotecas de cliente de Go, C++ o Java para Cloud Bigtable.

Cómo funcionan los grupos de conexiones

Un grupo de conexiones, también conocido como grupo de canales, es una caché de conexiones de bases de datos que se comparten y reutilizan para mejorar la latencia y el rendimiento de las conexiones. Las conexiones se usan en un sistema de asignación rotatoria.

Cuando usas Bigtable, creas un solo cliente de datos por proceso de aplicación. Cada cliente tiene un grupo de conexiones. Cada grupo de conexiones contiene un número de conexiones gRPC, cada una de las cuales puede gestionar hasta 100 flujos simultáneos. Las solicitudes enviadas a través de estas conexiones pasan por el middleware de Google, que las dirige a tu tabla. La capa de middleware se compone de muchas instancias con equilibrio de carga y cada solicitud se enruta a través de la instancia de middleware que tenga más disponibilidad.

Puedes imaginarte una conexión (o canal) como una autopista que tiene hasta 100 carriles, y cada carril (flujo) solo puede contener un coche (solicitud) en un momento dado. El límite de 100 flujos simultáneos por conexión gRPC se aplica en la capa de middleware de Google y no puedes volver a configurar este número.

Una conexión se actualiza automáticamente una vez cada hora. Además, si una conexión no ha recibido ninguna solicitud en cinco minutos, el middleware elimina automáticamente la conexión y no la vuelve a crear hasta que se necesite otra conexión.

En segundo plano, cada canal tiene un único subcanal. Cada subcanal tiene una conexión HTTP/2 que usa TCP para convertir las solicitudes en bytes y enviarlas a través del middleware y, a continuación, a tu tabla. El servicio Bigtable gestiona este proceso de forma fluida, por lo que no tienes que configurar nada para que se lleve a cabo.

Grupos de conexión y tráfico

Cómo afectan los grupos de conexiones al rendimiento

Lo ideal es que tengas suficientes conexiones gRPC para gestionar tus solicitudes sin necesidad de almacenamiento en búfer. Sin embargo, no deberías tener tantas conexiones que se interrumpan con frecuencia por falta de uso.

No hay suficientes conexiones

Si un grupo de conexiones no tiene suficientes conexiones para gestionar tu tráfico, el middleware empieza a almacenar en búfer y a poner en cola las solicitudes. Este almacenamiento en búfer ralentiza el tráfico, lo que reduce el número de solicitudes por segundo y aumenta la latencia a medida que se acumulan las solicitudes.

Demasiadas conexiones

Si un grupo tiene demasiadas conexiones, lo que significa que algunas de las conexiones están inactivas, el middleware desconecta las conexiones inactivas. Después, cuando se reciban nuevas solicitudes que los requieran, se restablecerán estas conexiones. Esto significa que, cuando aumenta el tráfico, las solicitudes pueden encontrarse con un fallo de caché del lado del servidor, lo que provoca trabajo y latencia adicionales. Si esto ocurre con frecuencia debido a las variaciones en los niveles de tráfico, esta actividad puede manifestarse como un aumento percibido de la latencia de cola en el lado del cliente.

Cuándo cambiar la configuración predeterminada

El tamaño predeterminado del grupo de conexiones es adecuado para la mayoría de las aplicaciones y, en la mayoría de los casos, no es necesario cambiarlo. En función de la biblioteca de cliente que uses en tu aplicación, es posible que no puedas cambiar el tamaño del grupo de conexiones. El número de conexiones de cada grupo se puede configurar en el código solo cuando se usan las bibliotecas de cliente de Go, C++ o Java para Cloud Bigtable.

Por lo general, un pool de conexiones ideal tiene al menos el doble de conexiones que se necesitan para alcanzar la saturación máxima. De esta forma, se deja margen para las fluctuaciones del tráfico. Por ejemplo, si tienes 4 conexiones y cada una de ellas gestiona el número máximo de solicitudes posible (100), y quieres reducir el número de solicitudes por conexión a un valor entre 10 y 50, el tamaño ideal del grupo de conexiones es al menos el doble, es decir, un mínimo de 8 conexiones.

Entre las señales que indican que deberías cambiar el número de conexiones del grupo, se incluyen las siguientes:

Bajo rendimiento combinado con picos en la latencia final del lado del cliente

Si tu tasa de transferencia típica es bastante baja (por ejemplo, menos de una solicitud por segundo por conexión) y observas una latencia de cola alta periódicamente en tu aplicación, es posible que no estés enviando suficiente tráfico para mantener las conexiones activas. En este caso, es posible que tengas que reducir el número de conexiones del grupo. Consulta Configurar grupos de conexiones para saber cómo determinar el número adecuado.

Solicitudes almacenadas en el búfer

Si observas que las solicitudes se acumulan en el lado del cliente, puede que estés enviando más solicitudes simultáneas de las que puede gestionar el grupo de conexiones. Calcula el número óptimo y, a continuación, cambia el código si es necesario.

Para determinar si las solicitudes se están acumulando, puedes usar OpenCensus y consultar la diferencia entre las métricas grpc.io/client/started_rpcs y grpc.io/client/completed_rpcs.

Entorno virtual

En algunos casos excepcionales, el cliente de Bigtable no puede determinar el número de CPUs en los que se está ejecutando la aplicación y asigna conexiones como si solo se estuviera usando una CPU. Por ejemplo, esto puede ocurrir cuando usas instancias de CPU virtual en Kubernetes o Docker. Si es evidente, debes configurar el número de grupos según las directrices en función de las consultas por segundo y la latencia de tu aplicación.

Siguientes pasos