Uma dica valiosa para configuração do pool de conexão JDBC para o Weblogic 10.3. Esta dica deve servir para todas as versão do Weblogic.
A aplicação estava apresentando problemas de lentidão, com demora para responder as interfaces para os usuários.
Lentidão é um problema difícil de ser diagnosticado, com isso, monitorei todos os aspectos de infraestrutura e da aplicação. Uma ferramenta útil e cara que ajuda no monitoramento de performance das aplicações é o Introscope, da CA, com ela conseguimos identificar alguns gargalos da aplicação. Identificamos que o pool de conexão estava com problemas de performance, apresentando um tempo de espera para retorno de uma conexão. Com isso, a aplicação estava esperando uma conexão do pool de conexão, com isso gerando a lentidão para a aplicação.
Para identificar este problema através do console do Weblogic, verificar em Monitoring do Pool de Conexão, os seguintes campo de Waiting for connection, demonstram problemas de performance do pool.
No exemplo, identificamos que está com uma pequena espera no tempo total. Nesse caso, não geraria lentidão aparente, mas serve como exemplo.
Pela
Oracle, uma forma de resolver este problema é definir o Initial Capacity igual
o Maximum Capacity.
Em ambientes produtivos não é recomendável deixar o Initial Capacity igual a 1, com isso, ele vai abrindo as conexões conforme a demanda e em caso de precisar de mais conexões, irá demandar mais recursos.
Em ambientes produtivos não é recomendável deixar o Initial Capacity igual a 1, com isso, ele vai abrindo as conexões conforme a demanda e em caso de precisar de mais conexões, irá demandar mais recursos.
A
configuração de Initial Capacity igual a 1 é definida em ambiente de
desenvolvimento na máquina local, com isso ganhamos tempo em subir o servidor. Evidênciando
que abrir conexão é um processo lento e custoso para a máquina. Definindo o
mesmo igual a 1, o Pool irá abrir a conexão e depois de um tempo irá fechar a
mesma, conforme a demanda.
Para ilustrar este comportamento, segue abaixo um gráfico do Introscope de número
de conexões no pool de conexão durante um mês. Identificamos que o mesmo vai
utilizando conforme a demanda, colocando e retirando conexões no pool. Este
gráfico é do pool de configuração de Inicial igual a 1 e final igual a 30.
Abaixo
gerei o gráfico deste mesmo pool no período de 2 horas, nele fica mais
explicito a reclamação de lentidão dos usuários. Neste tempo de abrir conexões
acaba gerando lentidão para o usuário, pois o mesmo fica na espera de uma
conexão livre. Pelo gráfico, identificamos que o número de conexões abertas no
pool vai variando, abrindo e fechando conexões conforme a demanda.
Em sistemas
com grande utilização, esta demora para abrir conexões acaba gerando grandes
transtornos, podendo o servidor entrar em overload. Em sistemas com pouca
utilização, vai gerar reclamação de alguns usuários e se esses usuários forem
chatos, vai gerar transtornos para o responsável do sistema.
A forma de aumentar a performance deste pool, seria definir o initial capacity para 30, deixando igual ao valor máximo permitido. Pelo gráfico mensal de número de conexões, identificamos que a máxima deste pool foi de 30 conexões, talvez poderíamos aumentar o máximo para 50 e o inicial para 50, assim verificando se estas 50 conexões serão necessárias para suportar a aplicação.Para verificar a eficiência desta configuração, no gráfico abaixo que foi gerado pelo Introscope, exibindo o tempo de espera para uma conexão do pool. Este gráfico exibe o tempo médio de espera para uma conexão do pool de conexão. Até o dia 25/02, o pool estava configurado como inicial e final do mesmo valor. Contudo, no dia 26/02, algum economista de conexões, resolveu abaixar o initial capacity para igual a 1. Depois deste dia, identificamos no gráfico que começou a ter na média de 1 segundo para a espera de uma conexão, chegando no máximo a 4 segundos. Com isso o sistema começou a gerar reclamações dos usuários. Depois de analisarmos, identificamos que houve esta troca de valor do initial capacity e voltamos para o valor correto no dia 14/03. Pelo gráfico, identificamos que depois de voltar o parâmetro, o tempo de espera de uma conexões voltou para 0.
A forma de aumentar a performance deste pool, seria definir o initial capacity para 30, deixando igual ao valor máximo permitido. Pelo gráfico mensal de número de conexões, identificamos que a máxima deste pool foi de 30 conexões, talvez poderíamos aumentar o máximo para 50 e o inicial para 50, assim verificando se estas 50 conexões serão necessárias para suportar a aplicação.Para verificar a eficiência desta configuração, no gráfico abaixo que foi gerado pelo Introscope, exibindo o tempo de espera para uma conexão do pool. Este gráfico exibe o tempo médio de espera para uma conexão do pool de conexão. Até o dia 25/02, o pool estava configurado como inicial e final do mesmo valor. Contudo, no dia 26/02, algum economista de conexões, resolveu abaixar o initial capacity para igual a 1. Depois deste dia, identificamos no gráfico que começou a ter na média de 1 segundo para a espera de uma conexão, chegando no máximo a 4 segundos. Com isso o sistema começou a gerar reclamações dos usuários. Depois de analisarmos, identificamos que houve esta troca de valor do initial capacity e voltamos para o valor correto no dia 14/03. Pelo gráfico, identificamos que depois de voltar o parâmetro, o tempo de espera de uma conexões voltou para 0.
Existem
outras dicas para aumentar a performance do pool de conexão no Weblogic, com o
tempo vou apresentando para vocês mais dicas. Esta certamente é a mais
eficiente.
Segue a documentação da oracle que fala sobre esta técnica:http://docs.oracle.com/cd/E14571_01/web.1111/e13814/jdbc_tuning.htm