{"id":2922,"date":"2014-10-24T09:13:00","date_gmt":"2014-10-24T12:13:00","guid":{"rendered":"http:\/\/blog.dialhost.com.br\/?p=2922"},"modified":"2014-10-24T09:13:00","modified_gmt":"2014-10-24T12:13:00","slug":"tunning-de-solucao-java-web","status":"publish","type":"post","link":"https:\/\/www.dialhost.com.br\/blog\/tunning-de-solucao-java-web\/","title":{"rendered":"Tunning de solu\u00e7\u00e3o Java Web"},"content":{"rendered":"
\"solu\u00e7\u00e3o<\/a>
Imagem ilustrativa<\/figcaption><\/figure>\n

Segue abaixo um relato resumido de uma das minhas consultorias para uma empresa que tinha uma solu\u00e7\u00e3o web feita em Java que estava apresentando travamento e tempo de resposta ruim. O objetivo com esse artigo \u00e9 apresentar os problemas encontrados na solu\u00e7\u00e3o e as medidas adotadas de otimiza\u00e7\u00e3o, de forma com que outros profissionais possam aprender com os fatos e ou reutilizar as estrat\u00e9gias encontradas.<\/p>\n

1. Otimiza\u00e7\u00e3o de acesso ao SGDB<\/strong><\/p>\n

Fizemos uma triagem da quantidade de acessos que o sistema faz ao sgdb quando um usu\u00e1rio acessa os principais processos. O resultado foi 117 round-trips. Ap\u00f3s estudos e otimiza\u00e7\u00f5es, reduzimos para 41 nos mesmos processos. Foi uma redu\u00e7\u00e3o de 65%! Dado que o n\u00famero de acessos di\u00e1rio dessa solu\u00e7\u00e3o \u00e9 de +- 7 mil \u2013 isso que dizer que reduzimos por dia (117 \u2013 41 = 76 * 7.000) 532 mil acesso ao sgdb. Essa otimiza\u00e7\u00e3o, al\u00e9m de aumentar o tempo de resposta, reduziu drasticamente o n\u00famero de conex\u00f5es do DataSource e a quantidade de parse de framework ORM, o que resultou em menos gastos com HEAP.<\/p>\n

2. Otimiza\u00e7\u00e3o de auditoria<\/strong><\/p>\n

O sistema usa uma tabela de logg que registra toda a auditoria de seus processos no qual tem uma coluna auto increment\u00e1vel manual com uma chave composta, que por sua vez resulta em algumas consequ\u00eancias negativas:<\/p>\n

Para evitar inconsist\u00eancias de concorr\u00eancia nos MAXID + 1 para inserir registro, o sistema sincroniza a concorr\u00eancia em todos os processos, deixando a execu\u00e7\u00e3o da solu\u00e7\u00e3o em modo \u201cMONO\u201d usu\u00e1rios.
\nPara cada novo registro de logg, o sistema \u00e9 obrigado a fazer + 1 acesso ao sgdb para pegar o pr\u00f3ximo MAXID + 1 a ser gravado.
\nAp\u00f3s estudos e otimiza\u00e7\u00f5es, resolvemos ambos os problemas criando um nova tabela de logg contendo a mesma estrutura, s\u00f3 que utilizando o conceito de UUID como chave prim\u00e1ria. O resultado foi que para cada novo registro de auditoria n\u00e3o \u00e9 mais necess\u00e1rio acessar o sgdb para buscar o pr\u00f3ximo MAXID + 1, uma vez que o UUID \u00e9 gerado pela pr\u00f3pria solu\u00e7\u00e3o. Usando a mesma m\u00e9dia de acesso di\u00e1rio j\u00e1 indicada acima, reduzimos + 7 mil acessos ao sgdb por dia. A partir dessa medida, foi poss\u00edvel retirar todas as sincroniza\u00e7\u00f5es das opera\u00e7\u00f5es de auditoria, fazendo com que eles pudessem ser executados de forma agora 100% concorrentes.<\/p>\n

3. Auditoria ass\u00edncrona<\/strong><\/p>\n

O sistema faz registros de loggs com caracter\u00edsticas somente de acesso, n\u00e3o sendo processos idempotentes. Do ponto de vista arquitetural, n\u00e3o faz sentido o usu\u00e1rio final esperar estes registros de loggs acontecer enquanto navega na solu\u00e7\u00e3o. Com isso,\u00a0 foi elaborada uma nova arquitetura de logg ass\u00edncrona espec\u00edfica para estes processos, no qual o sistema faz uso de threads separadas que v\u00e3o registrando os loggs, sem fazer o usu\u00e1rio pagar o tempo de espera na resposta da sua requisi\u00e7\u00e3o HTTP.<\/p>\n

4. \u00cdndices de acesso<\/strong><\/p>\n

Depois de averigua\u00e7\u00f5es, foi constatado que as tabelas do sistema est\u00e3o sem nenhum \u00edndice, fazendo com que o sgdb busque os registros origin\u00e1rios das consultas do sistema (WHERE) 100% sequencial. Com base em todas as consultas existentes, foi criado uma API de \u00edndices que promova melhor performance nas consultas das tabelas, conforme descrito no livro oficial do provedor do sgdb. Foram criados exatamente 63 \u00edndices.<\/p>\n

5. Evitando bloqueios pessimistas<\/strong><\/p>\n

O sistema faz acesso constante a um banco de dados de uma outra solu\u00e7\u00e3o legada da d\u00e9cada de 90, que por sua vez, utiliza-se do conceito de bloqueio pessimista<\/a> para assegurar a consist\u00eancia nas concorr\u00eancias de seus processos. Em virtude disso, esse sistema sofre intensivo bloqueio, n\u00e3o conseguindo acessar as tabelas dessa outra solu\u00e7\u00e3o e ocasionando diversas paradas di\u00e1rias sentidas constantemente pelos usu\u00e1rios finais. Para contornar isso, aplicamos o n\u00edvel de isolamento das consultas do sistema para READ_UNCOMMITED que faz leituras das tabela independente dos bloqueios existentes. Os \u00fanicos lugares que tivemos que manter o n\u00edvel READ_COMMITED \u00e9 nas opera\u00e7\u00f5es de processos de neg\u00f3cios. Como hoje o sistema \u00e9 praticamente 70% de consultas e 30% de opera\u00e7\u00f5es de neg\u00f3cios transacionais, o usu\u00e1rio final com essa nova otimiza\u00e7\u00e3o n\u00e3o ficar\u00e1 mais\u00a0 impedido de acessar e consultar informa\u00e7\u00f5es quando existir bloqueios pessimistas. Isso reduzir\u00e1 drasticamente a maioria das reclama\u00e7\u00f5es.<\/p>\n

6. Otimiza\u00e7\u00e3o de filtro NO-CACHE<\/strong><\/p>\n

Depois de averigua\u00e7\u00f5es, foi constatado que a solu\u00e7\u00e3o faz uso de um filtro servlet para decorar recursos web como \u201cno-cache\u201d HTTP. Nesse controle, encontramos o uso de opera\u00e7\u00e3o de substring() e contains() da classejava.lang.String. Para otimizar, foi utilizado o recurso de express\u00e3o regular, juntamente com a classe java.lang.Match que funciona bem mais r\u00e1pido na procura de padr\u00f5es de texto. Com base na mesma m\u00e9dia de acesso di\u00e1rio j\u00e1 indicada acima e que em cada requisi\u00e7\u00e3o HTTP o filtro \u00e9 executado +- 6 vezes, essa otimiza\u00e7\u00e3o deixou a tempo de resposta bem melhor.<\/p>\n

7. Mensurando as otimiza\u00e7\u00f5es<\/p>\n

Para podermos quantificar as melhorias das otimiza\u00e7\u00f5es, foi feita uma amostra de teste usando nas seguintes configura\u00e7\u00f5es SEVIDOR LINUX, JAVA7, TOMCAT 6 com 1GB HEAD, ferramenta de testes JMETER e usando um sgdb remoto de homologa\u00e7\u00e3o, executando os principais cen\u00e1rios de processos utilizados pelos usu\u00e1rios. Segue um resumo das estat\u00edsticas do resultado:<\/p>\n

Vers\u00e3o do sistema atual, rodamos os testes usando a vers\u00e3o atual da sistema:<\/p>\n