Table of Contents
Significado do pool de conexões
Um conjunto de conexões é um cache de conexões de banco de dados mantido para que as conexões possam ser reutilizadas quando solicitações futuras ao banco de dados forem necessárias. Os conjuntos de conexões são usados para aprimorar o desempenho da execução de comandos em um banco de dados. Abrir e manter uma conexão de banco de dados para cada usuário, especialmente solicitações feitas a um aplicativo dinâmico controlado por banco de dados, é caro e desperdiça recursos. No pool de conexões, depois que uma conexão é criada, ela é colocada no pool e é usada novamente para que uma nova conexão não precise ser estabelecida.
Você também pode definir um número máximo de conexões que um pool irá criar, e isso pode ser muito interessante para reduzir o número de licenças de banco de dados necessárias. Em um caso como esse, quando o pool atinge o limite e chega uma nova solicitação, essa solicitação não será processada se uma conexão vaga não for disponibilizada antes de um determinado tempo limite previamente definido.
A chave para um pool de conexões com conexões de banco de dados limitadas é definir o número ideal para esse pool com base no número final de usuários e na arquitetura do aplicativo. Mais sobre isso no exemplo abaixo.
O mecanismo de pool de conexão FireDAC
O mecanismo de pool de conexão do FireDAC é muito fácil de usar e pode ser ativado definindo apenas uma propriedade de conexão adicional da sua conexão (Pooled=True).
É claro que o recurso de pooling se destaca em aplicativos multiencadeados, onde várias tarefas curtas são executadas simultaneamente (ou quase), e cada uma dessas tarefas requer o estabelecimento de uma conexão. Ao utilizar o recurso de polling, a conexão já estará estabelecida e aguardando a tarefa, resultando em um tempo de processamento muito mais rápido e menor consumo de recursos.
Para cenários avançados, além do parâmetro “Pooled”, existem outros três parâmetros que podem ser considerados:
| Parâmetro | Parâmetro | Exemplo |
|---|---|---|
| POOL_CleanupTimeout | O tempo (msecs) até que o FireDAC remova as conexões que não foram usadas por mais tempo que o tempo POOL_ExpireTimeout. O valor padrão é 30.000 ms (30 segundos). | 3600000 |
| POOL_ExpireTimeout | O tempo (msecs) após o qual a conexão inativa pode ser excluída do pool e destruída. O valor padrão é 90.000 ms (90 segundos). | 600000 |
| POOL_MaximumItems | O número máximo de conexões no pool. Quando o aplicativo requer mais conexões, uma exceção é gerada. O valor padrão é 50. | 100 |
FireDAC permite que você use conexões “Persistentes” (armazenadas no arquivo .ini do FireDAC), conexões “Privadas” (disponíveis na memória para um aplicativo) e “Temporárias” (não armazenadas e não nomeadas nem gerenciadas pelo FDManager). Você pode ler mais sobre como definir e estabelecer uma conexão (com ou sem pool) seguindo a documentação abaixo:
- https://docwiki.embarcadero.com/RADStudio/en/Multithreading_(FireDAC)
- https://docwiki.embarcadero.com/RADStudio/en/Defining_Connection_(FireDAC)
Pool de conexão com servidor RAD (EMS)
Para qualquer aplicativo de back-end sério, incluindo o RAD Server, é quase obrigatório ter algum mecanismo de pool à medida que o número de chamadas para seu aplicativo cresce. Nosso exemplo demonstrará isso usando uma conexão “Privada” definida por meio do FDManager. Claro, você também pode reutilizar conexões já definidas no arquivo .ini do FireDAC, ou até mesmo carregar o arquivo .ini através do FDManager e alterá-lo adicionando os parâmetros de pool de conexões que são específicos para seu aplicativo de servidor, mas não tão úteis em um aplicativo de desktop.
Nosso aplicativo de demonstração foi criado usando o RAD Server Wizard ( https://docwiki.embarcadero.com/RADStudio/en/Creating_a_RAD_Server_Package ) e fazendo uso do recentemente adicionado EMSDataSetResource ( https://docwiki.embarcadero.com/RADStudio/en/ Using_RAD_Server_Components e https://blogs.embarcadero.com/using-emsdatasetresource-component-with-rad-server/ ), mas o mesmo se aplica a endpoints do RAD Server definidos explicitamente.
Importante notar que apenas uma instância do FDManager pode existir por instância do aplicativo, então você notará que o FDManager está sendo criado na seção de inicialização do nosso recurso EMS, assim:
Executando um teste de estresse com nosso projeto de demonstração
O vídeo abaixo mostra o mecanismo de pooling sendo testado usando o JMeter com uma carga total de 100 usuários:
Como dica adicional, se seu aplicativo RAD Server for composto por vários pacotes, você ainda poderá usar o mecanismo de pooling. Tudo o que você precisa fazer é criar um recurso RAD Server destinado a definir apenas a configuração do pool de conexão pelo FDManager e certificar-se de carregar esse recurso como o primeiro em seu ambiente de implantação.