Quando sua aplicação mantém milhares de conexões simultâneas ou cria conexões com alta frequência, o PolarDB for PostgreSQL (Compatible with Oracle) sofre pressão: cada conexão exige um processo de backend dedicado, e a sobrecarga desses processos degrada o desempenho. O recurso de pool de conexão no nível de transação direciona todo o tráfego do cliente pelo PolarProxy, permitindo que várias conexões de frontend compartilhem uma única conexão de backend. Isso reduz significativamente a quantidade de processos de backend e melhora o throughput do banco de dados.
Pré-requisitos
Antes de começar, verifique se você possui:
PolarProxy V2.3.46 ou posterior
Como funciona
O PolarProxy atua entre sua aplicação e o banco de dados de backend. Em vez de criar uma conexão de backend para cada conexão de cliente, o PolarProxy mantém um pool de conexões de backend e as reutiliza entre transações:
Um cliente se conecta ao PolarProxy.
O PolarProxy verifica no pool se existe uma conexão de backend ociosa correspondente às configurações de
user,dbnamee variáveis de sistema da solicitação.Se houver uma conexão ociosa correspondente, o PolarProxy a reutiliza. Caso contrário, abre uma nova conexão de backend.
Após o commit da transação, a conexão retorna ao pool e fica disponível para a próxima solicitação.
Essa multiplexação permite manter milhares de conexões entre clientes e o PolarProxy, enquanto este abre apenas dezenas ou centenas de conexões com o banco de dados de backend.
O PolarProxy não limita o número de conexões de cliente. O limite máximo de conexões para um endpoint de cluster do PolarDB depende das especificações dos nós de computação do banco de dados de backend. Com o pool de conexão no nível de transação desativado, o sistema cria uma conexão dedicada no nó primário e em cada nó somente leitura para cada solicitação de cliente.
Quando usar o pool de conexão no nível de transação
|
Cenário |
Usar pool de conexão? |
Motivo |
|
Dezenas de milhares de conexões simultâneas |
Sim |
O pool reduz significativamente a quantidade de conexões de backend |
|
Cargas de trabalho serverless com dimensionamento horizontal |
Sim |
A quantidade de conexões cresce linearmente com a escala do servidor; o pool absorve esse aumento |
|
Poucas conexões, majoritariamente persistentes |
Não |
Conexões persistentes já amortizam a sobrecarga de conexão; o pool não traz benefícios adicionais |
|
A aplicação já utiliza seu próprio pool de conexões |
Não |
Um pool no lado do cliente bem estabelecido alcança o mesmo efeito |
Para os cenários marcados como "Sim" acima, ative o pool de conexão no nível de transação apenas se o seu serviço não operar nas condições descritas na seção Fixação de conexão abaixo.
Ativar o pool de conexão no nível de transação
Faça login no console do PolarDB.
Clique em Clusters no painel de navegação à esquerda. No canto superior esquerdo da página Clusters, selecione a região onde o cluster está localizado.
Localize o cluster e clique no ID do cluster.
Na seção URL, clique em Configure.
-
Na seção Connection Pool Settings, defina Connection Pool como Transaction-level.
Clique em OK.
Desativar o pool de conexão no nível de transação
Faça login no console do PolarDB.
Clique em Clusters no painel de navegação à esquerda. No canto superior esquerdo da página Clusters, selecione a região onde o cluster está localizado.
Localize o cluster e clique no ID do cluster.
Na seção URL, clique em Configure.
Na seção Connection Pool Settings, defina Connection Pool como Off.
Clique em OK.
Fixação de conexão
Algumas operações fazem com que uma conexão de backend seja fixada, ou seja, bloqueada na sessão atual do cliente até o encerramento da sessão. Uma conexão fixada não retorna ao pool e outros clientes não podem reutilizá-la.
Se sua carga de trabalho aciona frequentemente a fixação, o pool não consegue multiplexar as conexões de forma eficaz. Analise as operações abaixo e considere utilizar uma conexão direta.
|
Operação |
Por que causa fixação |
|
Executar uma instrução |
A instrução preparada fica vinculada a um processo de backend específico |
|
Processar pacotes maiores que 16 MB |
O processamento de pacotes grandes requer um estado de conexão dedicado |
|
Insira no modo de cópia |
O comando |
|
Insira no modo de flush |
O modo de flush exige um estado de conexão persistente entre chamadas |
|
Crie uma tabela temporária, sequência ou visualize |
Esses objetos ficam vinculados a uma sessão de backend específica |
|
Utilizar uma transação |
Uma transação aberta retém a conexão até o |
|
Declarar um cursor |
O conjunto de resultados de um cursor reside no processo de backend que o abriu |
Como as conexões de backend são compartilhadas entre clientes, opidretornado porSELECT pg_backend_pid()pode mudar entre transações. Da mesma forma, o endereço IP e a porta do cliente exibidos empg_stat_activitye no SQL Explorer podem diferir do endereço real do cliente.