Visão Geral
O conceito de Pooling na computação está relacionado ao agrupamento ou reciclagem de recursos.
Este conceito é popularmente utilizado no gerenciamento de recursos de aplicações que se comunicam com bancos de dados, para manter as conexões que estejam abertas e liberadas, disponíveis para serem utilizadas por outros usuários.
Esta prática evita o custo de estabelecer uma conexão entre cliente e servidor todas as vezes que um acesso ao banco de dados for necessário. Nos casos onde existe muita concorrência de acessos, essa prática pode trazer bons resultados de performance.
Neste tópico abordaremos o uso do Pooling nas conexões de banco de dados do LATROMI.
Ciclo de vida das conexões (padrão)
No LATROMI, as conexões são criadas a cada requisição, quando for necessário acessar o banco de dados, e se mantém abertas até o fim da requisição.
O fluxo abaixo ilustra o comportamento padrão do LATROMI em relação ao ciclo de vida das conexões, e é utilizado tanto para a conexão com o banco de dados interno da plataforma quanto para as conexões cadastradas que estiverem sendo utilizadas na página.
- Início da requisição.
- Abertura da conexão.
- Acesso aos dados (quantas vezes for necessário).
- Fechamento da conexão.
- Fim da requisição.
Ciclo de vida das conexões (pooling)
Utilizando o Pooling, o fluxo ficaria mais ou menos assim:
- Início da requisição.
- Busca de uma conexão disponível ou abertura de uma nova.
- Acesso aos dados (quantas vezes for necessário).
- Liberação da conexão.
- Fim da requisição.
Habilitando o Pooling
O LATROMI utiliza o mecanismo de Pooling de conexões disponível na grande maioria dos provedores de dados .NET, não possuindo um recurso próprio para isso.
A seguir, veremos como habilita o Pooling na conexão interna da plataforma e nas conexões cadastradas.
Conexão da plataforma
No caso do acesso ao banco de dados interno da plataforma, o provedor de dados utilizado é o Npgsql, do PostgreSQL.
A configuração é realizada no elemento <pooling> do arquivo config.xml, que fica na pasta raiz do site:
<?xml version="1.0" encoding="utf-8"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<dbConnection>
<host>localhost</host>
<port>5432</port>
<dbName>latromi</dbName>
<username>postgres</username>
<password></password>
<timezone>America/Sao_Paulo</timezone>
<pooling enabled="false" maxSize="100" minSize="0" idleLifetime="300" pruningInterval="10" />
</dbConnection>
<diagnostics>
<log>
<sql enabled="false" />
<error enabled="true" />
<debug enabled="false" />
</log>
<slowSqlElapsedTime>1000</slowSqlElapsedTime>
</diagnostics>
<performance>
<aspNetViewStateStrategy>Mixed</aspNetViewStateStrategy>
</performance>
<users />
</config>
Basta trocar o valor do atributo enabled para true ao invés de false. Os demais atributos já possuem um valor padrão definido, mas podem ser alterados conforme a necessidade de cada ambiente:
| Atributo | Npgsql equivalente | Descrição |
|---|---|---|
| enabled | Pooling | true se o pool de conexões deve ser usado. |
| maxSize | Maximum Pool Size | O tamanho máximo do conjunto de conexões. |
| minSize | Minimum Pool Size | O tamanho mínimo do conjunto de conexões. |
| idleLifetime | Connection Idle Lifetime | O tempo (em segundos) de espera antes de fechar as conexões ociosas no pool se a contagem de todas as conexões exceder minSize |
| pruningInterval | Connection Pruning Interval | Quantos segundos o pool espera antes de tentar remover conexões inativas que estão além do tempo de inatividade definido em idleLifetime |
Conexões cadastradas
Para ativar o Pooling nas conexões cadastradas (que são utilizadas em objetos como Consultas e Formulários), procure o conjunto de propriedades correspondente nas configurações do Provedor de Dados .NET. Geralmente o nome da propriedade que habilita e desabilita chama-se “pooling”.
Cuidados a serem tomados
O uso do Pooling de conexões, ao mesmo tempo que oferece o benefício de poupar recursos utilizados no momento da abertura da conexão, vai fazer com que o número de conexões ativas com o servidor de banco dedados aumente, pois elas só serão fechadas quando as configurações de limite do pool forem atingidas.
No caso do PostgreSQL por exemplo, se o número máximo de conexões definido nas configurações do banco for excedido (max_connection) , ocorrerá o erro:
FATAL: sorry, too many clients already
Por este motivo, recomendamos que o ambiente seja monitorado durante algum tempo após a ativação do Pooling de conexões.