{"id":2890,"date":"2014-10-15T13:04:55","date_gmt":"2014-10-15T16:04:55","guid":{"rendered":"http:\/\/blog.dialhost.com.br\/?p=2890"},"modified":"2014-10-15T13:04:55","modified_gmt":"2014-10-15T16:04:55","slug":"como-fazer-um-tunning-de-aplicacoes-web","status":"publish","type":"post","link":"https:\/\/www.dialhost.com.br\/blog\/como-fazer-um-tunning-de-aplicacoes-web\/","title":{"rendered":"Como fazer um tunning de aplica\u00e7\u00f5es web"},"content":{"rendered":"
\"Carregando...\"<\/a>
Carregando…<\/figcaption><\/figure>\n

A velocidade da aplica\u00e7\u00e3o em executar os processos est\u00e1 intimamente ligada com a experi\u00eancia do usu\u00e1rio final. Na pr\u00e1tica, vejo que os respons\u00e1veis pela cria\u00e7\u00e3o de sistemas (gerentes, projetistas e programadores) n\u00e3o t\u00eam colocado isso como um fator de preocupa\u00e7\u00e3o nos ciclos de desenvolvimento. O resultado \u00e9 o mesmo de sempre, em ambiente de testes, homologa\u00e7\u00e3o e durante algum tempo inicial de produ\u00e7\u00e3o, o sistema acaba enganosamente funciona lindo e maravilhoso, mas depois de algum tempo, as reclama\u00e7\u00f5es relacionadas com a lentid\u00e3o come\u00e7am a aparecer. Diante desse contexto, segue abaixo as principais pr\u00e1ticas que eu venho utilizando como sucesso como se fosse uma \u201creceita de bolo\u201d para resolver esse tipo de situa\u00e7\u00e3o:<\/p>\n

Acesso ao banco de dados<\/strong><\/p>\n

Reduzir ao m\u00e1ximo o n\u00famero de vezes que a solu\u00e7\u00e3o faz acesso ao banco de dados.<\/p>\n

Problema:<\/strong> Muitos programadores t\u00eam a mania de ir desenvolvendo classes, componentes e m\u00f3dulos sem antes e\/ou durante fazer uma an\u00e1lise organizada de como estas partes do sistema est\u00e3o fazendo estes acessos. Com isso, vemos como resultado aplica\u00e7\u00f5es com baixa performance devido aos v\u00e1rios e desnecess\u00e1rios acessos ao banco \u201cround-trips\u201d que se multiplicam a medida do n\u00famero de usu\u00e1rios simultaneamente conectados.<\/p>\n

Solu\u00e7\u00e3o:<\/strong> Analisar quantas vezes a aplica\u00e7\u00e3o est\u00e1 acessando o banco, o porqu\u00ea do acesso e assim tentar uma forma de evitar este acesso. Neste momento, muitos profissionais pecam por n\u00e3o conhecerem recursos b\u00e1sicos de banco de dados e de SQL-ANSI, principalmente pelas propaga\u00e7\u00f5es de frameworks ORM. Qualquer meio \u00e9 v\u00e1lido, alguns recursos usados para alcan\u00e7ar isso s\u00e3o o uso de VIEWS, JOIN, SUBQUERYS e o Pattern Store Procedure Facade<\/a>. Todos os programadores t\u00eam que possuir um lema em mente: \u201cO acesso remoto \u00e9 que mais degrada a performance de uma aplica\u00e7\u00e3o e o acesso ao banco de dados \u00e9 um deles, ent\u00e3o eu tenho que fazer de tudo para evitar ou minimizar ao m\u00e1ximo.\u201c<\/p>\n

\u00cdndices adequados<\/strong><\/p>\n

Criar os \u00edndices para as todas as tabelas que sofrem consultas na aplica\u00e7\u00e3o.<\/p>\n

Problema:<\/strong> Muitos programadores n\u00e3o conhece o m\u00ednimo dos fundamentos de banco de dados, criando bancos sem nenhum \u00edndice de busca para as tabelas que sofrem alto n\u00famero de SELECT + WHERE CAMPO. A quest\u00e3o problem\u00e1tica \u00e9 que quando uma tabela sem \u00edndice sofre um SELECT +WHERE CAMPO, o registro \u00e9 buscado, na maioria das vezes, da pior e mais demorada forma poss\u00edvel, que \u00e9 o \u201csequencialmente\u201d. A pior not\u00edcia \u00e9 que isso \u00e9 um problema cumulativo, ou seja, quanto mais registro existente, mais demorada fica a consulta. J\u00e1 tive experi\u00eancias de diminuir o tempo de um procedimento de fechamento mensal em 50% do tempo, pelo simples ato de criar os \u00edndices nas tabelas usados pelo processo.<\/p>\n

Solu\u00e7\u00e3o:<\/strong> Para cada SELECT que o programa faz, em cada tabela, verifique os campos de busca colocados no WHERE e, assim, crie um \u00edndice para cada um deles.<\/p>\n

Consultas gigantescas<\/strong><\/p>\n

Sistemas que permitem o usu\u00e1rio consultar e trazer do banco de dados um alto n\u00famero de registros.<\/p>\n

Problema<\/strong>: Algumas situa\u00e7\u00f5es que costumam ocorrer em sistemas no modelo desktop, ou mais conhecido como \u201cFAT CLIENT\u201d, n\u00e3o se encaixam em aplicativos web. Um destes casos \u00e9 quando sistemas permitem aos usu\u00e1rios filtrar e trazer do banco de dados consultas com um alto n\u00famero de registros complemente desnecess\u00e1rio. Em casos em que o modelo era desktop, isso n\u00e3o acarretava problemas devido \u00e0 pr\u00f3pria natureza da solu\u00e7\u00e3o. Entretanto em sistemas web, onde recursos de execu\u00e7\u00e3o s\u00e3o compartilhados e o numero de acesso simult\u00e2neos \u00e9 ilimitado, o sistema estar\u00e1 gastando um alto e precioso n\u00famero relevante de mem\u00f3ria.<\/p>\n

Explicando de forma pr\u00e1tica, eu j\u00e1 peguei sistemas na redondezas onde os programadores estavam replicando a arquitetura que continha uma camada de persist\u00eancia CRUD. O problema era que o framework replicava um m\u00e9todo que sempre retornava todos os registros existente. Isto estava sendo propagado para todo o sistema e seus processos relacionados. Se paramos para analisar, mecanismos de busca s\u00e3o disponibilizados ao usu\u00e1rio para que ele tenha autonomia de buscar registros individuais ou grupos l\u00f3gicos deles. Qual seria o motivo, ou o que poderia fazer um usu\u00e1rio com 500 linhas de resultados de uma consulta? Que ser humano na face da terra gostaria de visualizar 500 registros em uma olhada? Mesmo que a regra de neg\u00f3cio ainda apoiasse o caso, o usu\u00e1rio final, sendo um humano comum, n\u00e3o teria tamanha visibilidade para isso.<\/p>\n

Solu\u00e7\u00e3o<\/strong>: Os processos do sistema em quest\u00e3o devem ser analisados e devem ser implementadas valida\u00e7\u00f5es l\u00f3gicas corretas, que n\u00e3o permitam\u00a0 executar consultas que retornem uma alto n\u00famero de registros no banco de dados. Duas pr\u00e1ticas neste t\u00f3pico s\u00e3o bem comuns \u2013 o uso sistem\u00e1tico de pagina\u00e7\u00e3o, e a implementa\u00e7\u00e3o de filtros inteligentes, baseados em regra do pr\u00f3prio neg\u00f3cio, que n\u00e3o deixassem a ocorr\u00eancia de grandes intervalos. Como tudo na vida, existem exce\u00e7\u00f5es e podemos, sim, encontrar situa\u00e7\u00f5es em sistemas que teriam a necessidade de consultar grandes volumes de registros, mas isso j\u00e1 est\u00e1 mais que comprovado que \u00e9 uma porcentagem pequena e restrita do total da automa\u00e7\u00e3o.<\/p>\n

Ordena\u00e7\u00e3o de dados<\/strong><\/p>\n

Ordenar dados em mem\u00f3ria usando java ao inv\u00e9s de usar ORDER BY.<\/p>\n

Problema<\/strong>: Uma funcionalidade muito comum \u00e9 disponibilizar a ordena\u00e7\u00e3o das tabelas apresentadas na aplica\u00e7\u00e3o pelas suas pr\u00f3prias colunas. A quest\u00e3o problem\u00e1tica \u00e9 quando a aplica\u00e7\u00e3o efetua mais um acesso ao banco a cada ordena\u00e7\u00e3o requisitada. Ou seja, o programador usa o recurso de SELECT ORDER BY para fazer a ordena\u00e7\u00e3o.<\/p>\n

Solu\u00e7\u00e3o<\/strong>: Transformar as linhas da tabela em objetos Java e, assim, orden\u00e1-los usando recursos do JSE, evitando gasto com tempo, acesso ao banco e recursos de mem\u00f3ria. Esta solu\u00e7\u00e3o pode ser facilmente implementando com a interface Comparable<\/a>.<\/p>\n

Pool de conex\u00f5es<\/strong><\/p>\n

Use indiscutivelmente a abordagem de pool como paradigma de acesso ao banco de dados.<\/p>\n

Problema<\/strong>: Eu realmente n\u00e3o sei o motivo, mas j\u00e1 peguei alguns aplicativos web por a\u00ed que abrem e fecham objetos de conex\u00e3o com o banco de dados a cada requisi\u00e7\u00e3o. Ou seja, a cada pedido enviado ao container Java, no m\u00ednimo duas chamadas remotas s\u00e3o efetuadas, uma para autenticar o usu\u00e1rio\/senha e outra para efetuar a comando SQL desejado. Esta op\u00e7\u00e3o \u00e9 uma das piores gafes que um desenvolvedor web pode fazer para deixar o sistema com a pior performance poss\u00edvel, sem falar que o sistema pode \u201cbaleiar\u201d o banco quando o n\u00famero de acesso simult\u00e2neos exceder a capacidade de resposta do determinado banco de dados.<\/p>\n

Solu\u00e7\u00e3o<\/strong>: Na web existe uma \u00fanica solu\u00e7\u00e3o comprovada que \u00e9 o uso efetivo da abordagem de Pool de conex\u00f5es. No momento da disponibiliza\u00e7\u00e3o \u2013 deploy da aplica\u00e7\u00e3o, o sistema deve abrir um n\u00famero X de conex\u00f5es com o banco de dados que ser\u00e1 posteriormente usado em toda a aplica\u00e7\u00e3o. Esta abordagem mistura o conceito de compartilhamento e concorr\u00eancia, sendo que pedidos em tempos diferentes reutiliza\u00e7\u00e3o a mesma conex\u00e3o e pedidos simult\u00e2neos usar\u00e3o diferentes conex\u00f5es. Este n\u00famero X deve ser levantando e configurado de forma parametrizada, de acordo com o perfil da aplica\u00e7\u00e3o e do modo\/quantidades que os usu\u00e1rios estar\u00e3o gastando conex\u00f5es durante utiliza\u00e7\u00e3o do sistema.<\/p>\n

Cache<\/strong><\/p>\n

Cachear informa\u00e7\u00f5es que sofrem alto \u00edndice de acesso e baixa ocorr\u00eancia de altera\u00e7\u00e3o.<\/p>\n

Problema<\/strong>: Sistemas em geral implementam administra\u00e7\u00e3o de informa\u00e7\u00f5es na qual poder\u00edamos classificar em dois tipos: dados de manuten\u00e7\u00e3o\/par\u00e2metrose de processos:<\/p>\n