O controle de conexões ao banco de dados em aplicações web é uma tarefa trabalhosa e pode levar a problemas de desempenho. Para resolver esse problema foram criados frameworks nomeados como pool de conexões que fazem este controle. Como resultado, é preciso responder a algumas perguntas: qual é o melhor pool de conexões para uso em aplicações web? O que é importante analisar para decidir isso? Este trabalho apresenta testes com base na configuração, suporte, velocidade e uso de recurso de pools de conexão para determinar qual é mais recomendado para uso em aplicações web.
1. Introdução
Em aplicações que utilizam bancos de dados, uma parte fundamental é a conexão entre eles. Segundo (FIELDS; KOLB, 2000), estabelecer uma conexão com um banco de dados é uma das tarefas mais demoradas de uma aplicação e deve ser evitado o máximo possível.
Para tentar resolver esse problema foram desenvolvidos os pools de conexões.
Segundo (FIELDS; KOLB, 2000), os pools de conexões mantêm um determinado número de conexões ativas e as empresta para as classes ou páginas quando essas a requisitarem. Esses pools são implementados pelos próprios drivers1 de banco de dados ou por classes específicas para criação dos mesmos. Um pool de conexão é uma boa solução para evitar o desperdício de tempo ao abrir e fechar várias conexões.
Mas como existem vários pools disponíveis, gera-se um questionamento: qual é o melhor pool para uma aplicação web?
Este trabalho apresenta comparações e testes realizados com alguns dos pools de conexões encontrados no mercado. São realizadas comparações quanto à configuração, suporte, velocidade e uso de recursos de hardware.
Para a realização de comparações de configuração e suporte, foram realizados pesquisas em sites e fóruns de discussão, já para comparar a velocidade e o uso de recursos foram realizados testes de estresse.
Estas comparações e testes ajudam a definir qual é o melhor pool de conexão para ser utilizado em uma aplicação web.
2. Ambiente Computacional
Nesta seção é descrito os cinco pools de conexões testados neste trabalho em conjunto com as ferramentas de testes empregadas.
Descrição dos cinco pools:
- Para o pool de conexão Proxool foi necessário configurar o parâmetro simultaneous-build-throttle que estabelece um número default máximo de threads4 simultâneas igual a 10, impossibilitando assim os testes com mais de 10 conexões simultâneas. Foi alterado esse valor, no arquivo context.xml, para 500 para a realização dos testes.
- No arquivo postgresql.conf, que estabelece algumas configurações do banco de dados PostgreSQL, foi aumentado o parâmetro max_connections para 500 para a realização dos testes, esse parâmetro é responsável por determinar quantas conexões ativas o postgreSQL pode manter, o default é de 100 conexões.
- No arquivo server.xml, que se encontra na pasta conf do Apache Tomcat e determina algumas configurações do Tomcat, foi alterado o parâmetro maxThreads para 550, o valor padrão é de 150. Esse parâmetro é responsável por determinar o número máximo de threads que o Tomcat pode receber na sua porta de conexão.
3. Realização dos Testes e Resultados
São usados dois computadores para realização dos testes:
- Notebook Dell Inspiron 1525 – 160GB de HD, 2GB de RAM, CPU Core 2 Duo de 2.0 GHz com sistema operacional Windows Seven Ultimate;
- Desktop com CPU Core 2 Duo 2.2 GHz, 2GB de RAM, 120GB de HD, e com sistema operacional CentOS 5.4 (Linux).
Serão realizadas comparações nos seguintes aspectos: configuração, suporte, velocidade e uso de recursos.
3.1. Configuração
As configurações de todos os pools de conexões, utilizados neste artigo, são realizadas no arquivo context.xml e referenciadas no arquivo persitence.xml.
A Figura 1 exibe a configuração de um pool de conexão no arquivo context.xml.
Figura 1: Exemplo da configuração de um pool de conexão
Nessa configuração definimos alguns atributos importantes para a conexão com o banco de dados:
- name: nome do pool de conexões;
- url: determina qual banco de dados utilizaremos, o servidor que ele se encontra, a porta utilizada e o nome da database;
- username: usuário do banco de dados;
- password: senha do banco de dados;
- driverClassName: o driver utilizado para a conexão com o banco;
- maxActive: determina o número máximo de conexões ativas no pool ao mesmo tempo;
- maxIdle: determina o número máximo de conexões inativas no pool;
- maxWait: determina o tempo máximo que o pool vai esperar por uma resposta de uma conexão.
Estes parâmetros são configurados em todos os pools, mas com nomes diferentes.
A Figura 2 mostra como é referenciado o uso do pool no arquivo persistence.xml. Apenas é apontando o nome do pool a ser utilizado, esse nome é definido no arquivo context.xml.
Figura 2: Exemplo do arquivo persistence.xml
O DBCP já é disponibilizado no Apache-Tomcat não necessitando de nenhuma biblioteca5 ou jar6 extra. Já para o BoneCP é necessário adicionar ao projeto de cinco a seis jars, dois para criação do pool e os outros para sua configuração.
Todos os outros pools utilizam apenas um jar cada.
3.2. Suporte
Todos os pools, usados neste projeto, têm em seus respectivos sites, modelos e exemplos de configurações, além de explicações sobre a utilização dos mesmos.
O DBCP e o C3P0 apresentam muitos materiais e artigos espalhados pela web, além de muitos comentários em fóruns. O BoneCP também possui seu próprio fórum de discussões, mas não é tão difundido na web quanto o DBCP e C3P0. Já os outros dois, Proxool e DBPool, apresentam pouco material na web para consulta.
3.3. Velocidade
A velocidade de criação e utilização das conexões pelos pools é uma das características que mais interessam aos desenvolvedores.
Nesta seção são apresentados alguns dos testes realizados para determinar esta velocidade. Os testes são simulados da seguinte maneira: um número x de usuários em determinado tempo e em um número de vezes selecionado, realizam uma requisição cada à aplicação web criando e excluindo uma conexão com o banco de dados.
A primeira bateria de teste, cujos resultados estão ilustrados na Figura 3, foi realizada no notebook com sistema operacional Windows, simulando o acesso de 150 usuários ao mesmo tempo uma única vez. Foram realizados 9 testes com cada pool de conexão e foram descartados os dois melhores e os dois piores resultados de cada um.
Figura 3:
Figura 3. Tempo de resposta nos testes com 150 usuários no Windows
Conforme pode ser observado na Figura 3, o pool de conexão que obteve o melhor resultado foi o BoneCP com uma média de 1821,8 ms e o pior resultado ficou com o DBPool com uma média de 5474,8 ms.
O tempo médio de respostas da primeira bateria de teste pode ser observado na Tabela 1.
Tabela 1: Tempo médio de resposta dos pools na primeira bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| Tempo de Resposta (ms) | 1821,8 | 4604,8 | 2231,4 | 5474,8 | 2059,8 |
A segunda bateria de teste, também foi realizada no notebook com sistema operacional Windows, porém simulando o acesso de 500 usuários ao mesmo tempo uma única vez. Foram realizados 9 testes com cada pool de conexão e foram descartados os dois melhores e os dois piores resultados de cada um. Os resultados desta bateria de teste são apresentados na Figura 4.
Figura 4: Tempo de resposta nos testes com 500 usuários no Windows
O pool de conexão que obteve o melhor resultado foi o DBCP com uma média de 2421,8 ms e o pior resultado ficou com o DBPool com uma média de 17680,2 ms. É importante ressaltar que não foi possível realizar os testes com o C3P0, pois, em todas as tentativas apresentou travamento no sistema operacional em decorrência do alto consumo de memória RAM.
Na Tabela 2 são exibidas as médias dos tempos de respostas de todos os pools da segunda bateria de teste.
Tabela 2: Tempo médio de resposta dos pools na segunda bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| Tempo de Resposta (ms) | 2892,4 | 2421,8 | 17680,2 | 2971,6 |
A terceira bateria de teste, foi realizada no desktop com sistema operacional CentOS 5.4, simulando o acesso de 150 usuários ao mesmo tempo uma única vez. Foram realizados 9 testes com cada pool de conexão e foram descartados os dois melhores e os dois piores resultados de cada um. Os resultados dessa bateria de teste são apresentados na Figura 5.
Figura 5: Tempo de resposta nos testes com 150 usuários no Linux
O pool de conexão que obteve o melhor resultado foi o BoneCP com uma média de 1266,6 ms e o pior resultado ficou com o DBPool com uma média de 1736 ms.
As médias dos tempos de respostas de todos os pools de conexões obtidas na terceira bateria de teste podem ser observadas na Tabela 3.
Tabela 3: Tempo médio de resposta dos pools na terceira bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| Tempo de Resposta (ms) | 1266,6 | 1723 | 1301,2 | 1736 | 1601,4 |
Na quarta bateria de teste, também realizada no notebook com sistema operacional CentOS 5.4, foi simulado o acesso de 500 usuários ao mesmo tempo uma única vez. Foram realizados 9 testes com cada pool de conexão e foram descartados os dois melhores e os dois piores resultados de cada um. A Figura 6 apresenta os testes desta bateria.
Figura 1: Tempo de resposta nos testes com 500 usuários no Linux
O pool de conexão que obteve o melhor resultado foi o DBCP com uma média de 3650,2 ms e o pior resultado ficou com o Proxool com uma média de 5113,4 ms.
A Tabela 4 exibe as médias de tempos de respostas obtidas na quarta bateria de testes.
Tabela 4: Tempo médio de resposta dos pools na quarta bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| Tempo de Resposta (ms) | 5043,2 | 4662 | 3650,2 | 4363,8 | v |
3.4. Uso de recursos
O consumo de recursos de hardware é uma característica importante no uso de uma aplicação web, o que afeta diretamente o desempenho e pode ocasionar travamentos da aplicação e do sistema operacional.
Nesta seção são apresentados os resultados de medições quanto ao uso desses recursos enquanto foram realizadas as baterias de testes apresentados na seção 3.3.
Os resultados demonstrados nos gráficos das figuras 7 e 8 referem-se à primeira bateria de teste, realizada no notebook com sistema operacional Windows simulando o acesso de 150 usuários ao mesmo tempo uma única vez.
Figura 1: Uso da CPU nos testes com 150 usuários no Windows
O pool de conexão que apresentou o melhor resultado foi o DBCP que teve uma média de 99,6% de uso de CPU enquanto o C3P0, DBPool e BoneCP obtiveram o pior resultado com 100% do uso de CPU.
Figura 2: Uso de memória nos testes com 150 usuários no Windows
O pool de conexão que apresentou o melhor resultado foi o Proxool que teve uma média de 1023,8 MB de uso de memória, já o C3P0 obteve o pior resultado com 1547 MB de uso de memória.
A Tabela 5 mostra as médias de consumo de hardware de todos os pools obtidas na primeira bateria de teste.
Tabela 5: Consumo de recursos dos pools na primeira bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| CPU (%) | 100 | 100 | 99,6 | 100 | 99,8 |
| Memória (MB) | 1492,2 | 1547 | 1186,8 | 1101,2 | 1023,8 |
Os resultados da segunda bateria de teste, realizada no notebook com sistema operacional Windows simulando o acesso de 500 usuários ao mesmo tempo uma única vez, são demonstrados nos gráficos das figuras 9 e 10.
Figura 9: Uso da CPU nos testes com 500 usuários no Windows
O pool de conexão que apresentou o melhor resultado foi o Proxool que teve uma média de 98,2% de uso de CPU enquanto o DBPool obteve o pior resultado com 100% do uso de CPU. Lembrando que não foi possível a realização dos testes com o C3P0, pois, em todas as tentativas apresentou travamento no sistema operacional em decorrência do alto consumo de memória RAM.
Figura 10: Uso de memória nos testes com 500 usuários no Windows
O pool de conexão que apresentou o melhor resultado foi o DBCP que teve uma média de 1161,6 MB de uso de memória, já o BoneCP obteve o pior resultado com 1692 MB de uso de memória. Ressaltando que não foi possível a realização dos testes com o C3P0, pois, em todas as tentativas travou o sistema operacional devido ao alto consumo de memória RAM.
O consumo médio de CPU e Memória RAM obtido na segunda bateria de testes pode ser observado na Tabela 6.
Tabela 6: Consumo de recursos dos pools na segunda bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| CPU (%) | 99,6 | 99,6 | 100 | 98,2 | |
| Memória (MB) | 1692 | 1161,6 | 1262,4 | 1223,8 |
Os resultados demonstrados nos gráficos das figuras 11 e 12 referem-se á terceira bateria de teste, realizada no notebook com sistema operacional CentOS 5.4 simulando o acesso de 150 usuários ao mesmo tempo uma única vez.
Figura 11: Uso da CPU nos testes com 150 usuários no Linux
O pool de conexão que apresentou o melhor resultado foi o DBPool que teve uma média de 75,2% de uso de CPU enquanto o DBCP obteve o pior resultado com 86% do uso de CPU.
Figura 12: Uso de memória nos testes com 150 usuários no Linux
O pool de conexão que apresentou o melhor resultado foi o DBPool que teve uma média de 1365 MB de uso de memória, já o BoneCP obteve o pior resultado com 1509,4 MB de uso de memória.
As médias de consumo de hardware de todos os pools obtidas na terceira bateria de teste são apresentadas na Tabela 7.
Tabela 7: Consumo de recursos dos pools na terceira bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| CPU (%) | 81,6 | 83,8 | 86 | 75,2 | 84 |
| Memória (MB) | 1509,4 | 1460 | 1383,8 | 1365 | 1473,4 |
A quarta bateria de teste, foi realizada no desktop com sistema operacional CentOS 5.4, simulando o acesso de 500 usuários ao mesmo tempo uma única vez. Os resultados dessa bateria de teste são demonstrados nos gráficos das figuras 13 e 14.
Figura 13: Uso da CPU nos testes com 500 usuários no Linux
O pool de conexão que apresentou o melhor resultado foi o Proxool que teve uma média de 85,6% de uso de CPU enquanto o C3P0 obteve o pior resultado com 92% do uso de CPU.
Figura 14: Uso de memória nos testes com 500 usuários no Linux
O pool de conexão que apresentou o melhor resultado foi o DBPool que teve uma média de 1407,4 MB de uso de memória, já o C3P0 obteve o pior resultado com 1618 MB de uso de memória.
A Tabela 8 exibe as médias de consumo de CPU e de Memória RAM de todos os pools de conexões obtidas na quarta bateria de teste.
Tabela 8: Consumo de recursos dos pools na quarta bateria de teste
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| CPU (%) | 86,2 | 92 | 88,8 | 89,8 | 85,6 |
| Memória (MB) | 1548,8 | 1618 | 1426,6 | 1407,4 | 1533,6 |
3.5. Médias Gerais e Definições de cada Pool de Conexão
A média de todos os testes dos tempos de respostas dos pools pode ser observada na Tabela 9.
Tabela 9: Tempo de resposta dos pools
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| Tempo de Resposta (ms) | 2756 | 3663,26 | 2333,65 | 7313,7 | 2936,55 |
Pode-se observar que o tempo de resposta do DBCP foi o menor dentre todos com apenas 2333,65 ms.
O tempo médio de consumo de CPU e de Memória RAM pode ser observado na Tabela 10.
Tabela 10: Consumo de recursos dos pools
| Pool de Conexão | BoneCP | C3P0 | DBCP | DBPool | Proxool |
| CPU (%) | 91,85 | 91,93 | 93,5 | 91,25 | 91,9 |
| Memória (MB) | 1560,6 | 1541,66 | 1289,7 | 1284 | 1313,65 |
Apesar de todos os pools estarem muito parecidos quanto ao uso de CPU, o que apresentou uma pequena vantagem foi o DBPool que obteve uma média de 91,25% de utilização, já o consumo de memória também foi menor no DBPool que apresentou um consumo médio de 1284 MB.
Pelos resultados obtidos em todas as comparações e nos testes individuais realizados pode se definir o seguinte:
- BoneCP: apresentou um bom tempo de resposta principalmente em aplicações com poucas conexões. O consumo de CPU também é normal quando comparado aos outros pools, mas o consumo de memória se mostrou mais elevada que todos os outros na média final, podendo assim ser necessário o uso de um servidor mais robusto. O suporte, apesar de não ser tão quantitativo, é bom, mas é encontrado somente materiais em inglês. A configuração pode ser um pouco mais trabalhosa em relação aos outros devido ao uso de alguns jars extras;
- C3P0: apresentou um tempo um pouco alto de resposta, mas que pode ser até tolerado dependendo da aplicação. O consumo de CPU também é normal quando comparado aos outros pools, já o consumo de memória se mostrou bem alta, ocorrendo até mesmo um travamento do sistema operacional Windows quando realizados tentativas de testes com muitas conexões. O suporte é muito bom, existem muitos materiais e artigos pela web, inclusive em português. A configuração é bem simples.
- DBCP: foi o que teve o menor tempo médio de resposta, sendo assim se a necessidade for ter uma aplicação mais rápida e que não se sabe o número de conexões que ela pode ter ou caso esse número de conexões seja alto, ele é a melhor opção. Ele também apresenta um baixo consumo de memória apesar de o consumo de CPU ser um pouco mais alto, mas se comparado aos outros o uso de CPU também é considerável. O suporte é excelente, existem muitos materiais e artigos pela internet, inclusive na língua portuguesa. A configuração é bem simples;
- DBPool: foi o que obteve o pior tempo médio de resposta, mas em contrapartida a isso, foi o que teve os melhores resultados quanto ao consumo de hardware, podendo assim ser utilizado em aplicações que não necessitam de tanta velocidade e que não dispõe de servidor robusto. O suporte é encontrado apenas em inglês na página do desenvolvedor ou em poucos artigos e fóruns na web. A configuração é bem simples;
- Proxool: teve um tempo médio de respostas razoável nos testes com poucas conexões, mas um pouco elevado quando o número de conexões sobe. O consumo de CPU e memória é considerado bom em comparação aos outros. O suporte é encontrado apenas na língua inglesa na página do desenvolvedor ou em poucos artigos e fóruns na web. A configuração é bem simples
4. Trabalhos Relacionados
Foram encontrados poucos materiais e trabalhos relacionados a esse tema. Geralmente, são apresentadas comparações em forma de respostas a dúvidas em fóruns de discussão.
No site do BoneCP encontram-se alguns testes de velocidade comparando o próprio BoneCP a outros pools de conexão como o C3P0 e o DBCP. Em todos os testes realizados pelo desenvolvedor do BoneCP, apesar de serem um pouco diferentes dos realizados neste artigo, mas com o mesmo objetivo que é a medição da velocidade dos pools, o BoneCP sempre aparece como sendo o mais rápido dentre todos os pools comparados, mas os testes realizados neste artigo apresentam o BoneCP como sendo o pool mais rápido quando o número de conexões é menor, em caso de um número maior de conexões o DBCP demonstra ser um pouco mais rápido que ele. O site também não mostra as outras comparações realizadas neste artigo.
A revista Java Magazine, na sua edição 64, também apresentou a utilização da ferramenta JMeter para testes de carga em aplicações, mostrando as facilidades e benefícios dessa aplicação.
5. Conclusões e Trabalhos Futuros
Com as pesquisas e os testes desenvolvidos neste trabalho, foi possível realizar as definições e comparações dos pools de conexões.
As comparações demonstradas neste artigo devem ajudar desenvolvedores, programadores e gerentes da área de tecnologia da informação a definir qual o melhor pool de conexão para usar em seus projetos web, dependendo dos diversos aspectos que envolvem os mesmos, como o desempenho que a aplicação deve possuir, a capacidade de recursos que seus servidores possuem e até mesmo o nível de especialização das pessoas envolvidas no desenvolvimento.
Em trabalhos futuros, podem ser realizadas outras baterias de teste, como os apresentados neste artigo, incluindo configurações e parâmetros diferentes, dependendo do nível de precisão que se deseja encontrar, além de incluírem novos pools de conexões que venham a surgir no mercado.
Referências
- BONECP. Tradução de Wanderlei L. P. Magri. Disponível em: http://jolbox.com/ Acesso em: 12 abr. 2011.
- COSTA, DANIEL GOUVEIA. Java em rede : programação distribuída na Internet. Rio de Janeiro: Brasport, 2008.
- DOEDERLEIN, OSVALDO PINALI. Testes de carga com o JMeter e Netbeans. Java Magazine ed. 64, p. 68-74, 2008.
- FIELDS, D. K.; KOLB, M. A. Desenvolvimento na Web com JavaServer Pages. Rio de Janeiro: Editora Ciência Moderna Ltda., 2000.
- MCHANGE. Tradução de Wanderlei L. P. Magri. Disponível em: http://www.mchange.com/projects/c3p0/index.html. Acesso em: 20 abr. 2011.
- PROXOOL. Tradução de Wanderlei L. P. Magri. Disponível em: http://proxool.sourceforge.net/. Acesso em: 13 abr. 2011.
- SNAQ. Tradução de Wanderlei L. P. Magri. Disponível em: http://www.snaq.net/java/DBPool/. Acesso em: 12 abr. 2011.
- VELOSO, J. S. et al. Avaliação de Ferramentas de Apoio ao Teste de Sistemas de Informação. Teresina: UFPI, 2010. 12-3 p. Disponível em: http://www.seer.unirio.br/index.php/isys/article/view/1295. Acesso em: 27 abr. 2011.
