Pools de conexões

Neste tópico, você vai aprender como os pools de conexões funcionam no Bigtable, os impactos que o tamanho do pool de conexões pode ter em um aplicativo que usa o Bigtable e quando convém mudar as configurações padrão do pool de conexões.

Depois de ler esta página, se você determinar que precisa alterar o tamanho do pool de conexões, consulte Como configurar pools de conexões para saber como determinar o tamanho ideal e como alterá-lo. O número de conexões em cada pool só pode ser configurado no código quando você usa as bibliotecas de cliente Go, C++ ou Java para o Cloud Bigtable.

Como funcionam os pools de conexão

Um pool de conexões, também conhecido como pool de canais, é um cache de conexões de banco de dados que são compartilhadas e reutilizadas para melhorar a latência e o desempenho da conexão. As conexões são usadas em um sistema round-robin.

Ao usar o Bigtable, você cria um único cliente de dados por processo do aplicativo. Cada cliente tem um pool de conexões. Cada pool de conexões contém algum número de conexões gRPC, que podem processar até 100 fluxos simultâneos. As solicitações enviadas por meio dessas conexões passam pelo middleware do Google, que as encaminha para sua tabela. A camada de middleware é composta de muitas instâncias com balanceamento de carga, e cada solicitação é encaminhada por meio da instância de middleware com maior disponibilidade.

Você pode pensar em uma conexão (ou canal) como uma rodovia que tem até 100 pistas, e cada faixa (stream) pode conter apenas um carro (solicitação) por vez. vez. O limite de 100 streams simultâneos por conexão do gRPC é aplicado na camada de middleware do Google, e não é possível reconfigurar esse número.

Uma conexão é atualizada automaticamente a cada hora. Além disso, se uma conexão não tiver visto uma solicitação em cinco minutos, o middleware excluirá automaticamente a conexão e não a recriará até que uma conexão adicional seja necessária.

Em segundo plano, cada canal tem um único subcanal. Cada subcanal tem uma conexão HTTP2 que usa TCP para converter solicitações em bytes e enviá-las por meio do middleware e depois para sua tabela. Esse processo é processado perfeitamente pelo serviço Bigtable, e você não precisa configurar nada para que isso aconteça.

Pools de conexão e tráfego

Como os pools de conexão afetam o desempenho

O ideal é ter conexões gRPC suficientes para processar as solicitações sem buffer. No entanto, você não deve ter tantas conexões que elas são descartadas com frequência por falta de uso.

Conexões insuficientes

Se um pool de conexões não tiver conexões suficientes para processar o tráfego, o middleware começará a armazenar as solicitações em fila e em buffer. Esse buffer diminui o tráfego, reduzindo o número de solicitações por segundo e aumentando a latência à medida que o backup é feito.

Muitas conexões

Se um pool tiver muitas conexões, o que significa que algumas das conexões estão ociosas, o middleware desconectará as conexões inativas. Em seguida, quando novas solicitações forem necessárias, essas conexões serão restabelecidas. Isso significa que, quando o tráfego aumenta, as solicitações podem encontrar uma falha de cache do lado do servidor, causando trabalho extra e latência. Se isso acontecer com frequência devido à variação dos níveis de tráfego, essa atividade poderá se manifestar como um pico percebido na latência de cauda no lado do cliente.

Quando mudar as configurações padrão

O tamanho padrão do pool de conexões é adequado para a maioria dos aplicativos e, na maioria dos casos, não é necessário mudá-lo. Dependendo da biblioteca de cliente usada no aplicativo, talvez não seja possível alterar o tamanho do pool de conexões. O número de conexões em cada pool é configurável no código somente quando você usa as bibliotecas de cliente Go, C++ ou Java para o Cloud Bigtable.

Como regra geral, um pool de conexões ideal tem pelo menos duas vezes o número de conexões necessárias para a saturação máxima. Isso deixa espaço para oscilações de tráfego. Por exemplo, se você tem quatro conexões e cada uma processa o número máximo de solicitações possíveis (100), reduza o número de solicitações por conexão para um número entre 10 e 50. O tamanho ideal do pool de conexões será pelo menos o dobro ou no mínimo oito conexões.

Os sinais que você precisa considerar para alterar o número de conexões no pool incluem:

Baixa capacidade combinada com picos na latência de cauda do lado do cliente

Se a capacidade típica for relativamente baixa, como menos de uma solicitação por segundo por conexão e você observar uma latência de cauda periodicamente alta para o aplicativo, talvez não esteja enviando tráfego suficiente para manter as conexões vivo. Nesse caso, talvez seja necessário diminuir o número de conexões no pool. Consulte Como configurar pools de conexão para saber como determinar o número certo.

Solicitações armazenadas em buffer

Se as solicitações estiverem se acumulando no lado do cliente, isso pode indicar que você está enviando mais solicitações simultâneas do que o pool de conexões pode processar. Calcule o número ideal e altere o código, se necessário.

Para determinar se as solicitações estão se acumulando, use o OpenCensus para analisar a diferença entre as métricas grpc.io/client/started_rpcs e grpc.io/client/completed_rpcs.

Ambiente virtual

Em alguns casos raros, o cliente Bigtable não consegue informar o número de CPUs em que o aplicativo está sendo executado e aloca conexões como se apenas uma CPU estivesse em uso. Por exemplo, isso pode acontecer quando você usa instâncias de CPU virtual no Kubernetes ou no Docker. Se isso for evidente, configure o número de pools de acordo com as diretrizes com base no QPS e na latência do aplicativo.

A seguir