Grupos de conexiones

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

Después de leer esta página, si determinas que debes cambiar el tamaño del grupo de conexiones, consulta Configura los grupos de conexiones a fin de obtener información para determinar el tamaño óptimo y cómo cambiarlo. La cantidad de conexiones en cada grupo se puede configurar en tu código solo cuando usas las bibliotecas 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 round robin.

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 alguna cantidad de conexiones de gRPC, que pueden manejar hasta 100 transmisiones simultáneas. Las solicitudes enviadas a través de estas conexiones pasan por middleware de Google, que luego las enruta a tu tabla. La capa de middleware está compuesta por muchas instancias con balanceo de cargas, y cada solicitud se enruta a través de la instancia de middleware que tiene la mayor disponibilidad.

Puedes pensar en una conexión (o canal) como una autopista que tiene hasta 100 infraestructuras, y cada carril (transmisión) solo puede contener un automóvil (solicitud) en un momento determinado. El límite de 100 transmisiones simultáneas por conexión de gRPC se aplica en la capa de middleware de Google, y no puedes volver a configurar esta cantidad.

Una conexión se actualiza automáticamente una vez por hora. Además, si una conexión no vio una solicitud en cinco minutos, el middleware borra de forma automática la conexión y no la vuelve a crear hasta que se necesite una conexión adicional.

En segundo plano, cada canal tiene un solo subcanal. Cada subcanal tiene una conexión HTTP2 que usa TCP para convertir las solicitudes en bytes y enviarlas a través del middleware y, luego, a tu tabla. El servicio de Bigtable controla este proceso sin problemas, por lo que no necesitas configurar nada para que suceda.

Cómo afectan los grupos de conexiones al rendimiento

Lo ideal sería tener suficientes conexiones de gRPC para controlar tus solicitudes sin almacenamiento en búfer. Sin embargo, no deberías tener tantas conexiones que se descarten con frecuencia debido a la falta de uso.

No hay suficientes conexiones

Si un grupo de conexiones no tiene suficientes conexiones para controlar el tráfico, el middleware comienza a almacenar las solicitudes en búfer y ponerlas en cola. Este almacenamiento en búfer ralentiza el tráfico, ya que reduce la cantidad de solicitudes por segundo y aumenta la latencia a medida que las solicitudes disminuyen.

Hay 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. Luego, cuando llegan nuevas solicitudes que las requieren, se restablecen estas conexiones. Esto significa que cuando el tráfico aumenta, las solicitudes pueden encontrar un error de caché del servidor, lo que causa trabajo y latencia adicionales. Si esto sucede con frecuencia debido a los diferentes niveles de tráfico, esta actividad puede manifestarse como un aumento repentino percibido en la latencia final del cliente.

Nota: En la mayoría de los casos, no puedes controlar la cadencia de actualización. Sin embargo, si esta latencia final es una preocupación y necesitas una latencia predecible con una tasa baja de consultas por segundo (QPS) y usas la biblioteca cliente de Cloud Bigtable para Java, puedes establecer la configuración de actualización con la clase BigtableDataSettings.Builder. Si usas la biblioteca cliente de Cloud Bigtable para Go, consulta el ejemplo de actualización de la conexión en GitHub.

Cuándo cambiar la configuración predeterminada

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

Como regla general, un grupo de conexiones ideal tiene al menos el doble de conexiones que se necesitan para una saturación máxima. Esto deja lugar para las fluctuaciones del tráfico. Por ejemplo, si tienes 4 conexiones y cada una maneja la cantidad máxima de solicitudes posibles (100), te recomendamos reducir la cantidad de solicitudes por conexión a un número entre 10 y 50, por lo que el tamaño ideal del grupo de conexiones es al menos el doble o un mínimo de 8 conexiones.

Los indicadores que debes considerar para cambiar la cantidad de conexiones en el grupo incluyen las siguientes:

Capacidad de procesamiento baja combinada con aumentos repentinos de latencia final del cliente

Si tu capacidad de procesamiento típica es bastante baja, como menos de una solicitud por segundo por conexión, y observas una latencia final periódicamente alta para tu aplicación, es posible que no envíes suficiente tráfico a fin de mantener las conexiones vivas. En este caso, es posible que debas reducir la cantidad de conexiones en el grupo. Consulta Configura grupos de conexiones para obtener información sobre cómo determinar la cantidad correcta.

Solicitudes almacenadas en búfer

Si observas que las solicitudes se están acumulando en el lado del cliente, esto podría indicar que estás enviando más solicitudes simultáneas de las que puede manejar el grupo de conexiones. Calcula la cantidad óptima y, luego, cambia el código si lo necesitas.

Para determinar si las solicitudes se acumulan, puedes usar OpenCensus a fin de ver la diferencia entre las métricas grpc.io/client/started_rpcs y grpc.io/client/completed_rpcs.

Entorno virtual

En casos excepcionales, el cliente de Bigtable no puede saber la cantidad de CPU en las que se ejecuta la aplicación y asigna conexiones como si solo estuviera en uso una CPU. Por ejemplo, esto puede suceder cuando usas instancias de CPU virtuales en Kubernetes o Docker. Si esto es evidente, debes configurar la cantidad de grupos según los lineamientos a partir de las QPS y la latencia de tu aplicación.

Pasos siguientes

• Obtén información para configurar grupos de conexiones.
• Lee más sobre el rendimiento.