Nesses anos trabalhando especificamente com desempenho de aplicações é muito comum, em salas de guerra principalmente, a busca por um “culpado”; e a culpa muitas vezes recai sobre o banco de dados.
Antes de continuar eu gostaria de fazer uma ressalva que, atualmente, com o foco na cultura DevOps, a atuação não deveria ser no sentido da busca por um “culpado”, mas sim um time único buscando oportunidades de otimizar o ambiente.
Quando uso o termo “buscando oportunidades de otimizar” o sentido é o de resolver o problema o mais rápido possível, já que muitas vezes tentar entender porque num determinado horário do dia o sistema fica lento pode demandar muito mais tempo do que identificar oportunidades de tornar o ambiente resiliente e escalável. Ou mesmo quando se encontra o “culpado”, este pode ser fruto de falta de testes adequados, mudança no comportamento de uso do ambiente, etc. Por isso o “culpado” pode não ser tão culpado.
Voltemos ao tema foco deste artigo.
Otimizar queries é um ótimo primeiro passo!
Antes de ser um gestor, eu era (e sou) um dos especialistas em desempenho com foco em banco de dados, e sempre foi muito comum em nossas análises identificarmos que a lentidão vinha do banco de dados, mas em muitos casos o banco refletia um problema de construção nas aplicações. Por exemplo, comandos gerando compilação a cada execução por conta da versão e do mapeamento de objetos feito na camada do NHibernate. E nesse caso nem adianta definir o parâmetro:
cursor_sharing=force
Se o banco de dados for Oracle, pois as compilações continuarão a ocorrer, já que os aliases de tabelas e colunas é que estão sendo alterados.
Em alguns cenários as principais oportunidades de otimização no banco de dados estão em:
- Rescrita de Comandos;
- Rescrita na lógica de processamento;
- Tecnologia
- Criação de Índices.
Vejam que nesses casos a culpa não é do banco de dados, mas na forma com que as queries e processos foram escritos.
Identifique as contenções
Em algumas análises identificamos que havia alguma contenção na camada de aplicação, especificamente em trechos de códigos (lógica ou através de componentes), porém ao avaliar a camada de banco de dados houve a identificação de alto volume de bloqueios (locks) e teve-se a visão errada de que esse era o problema, quando na verdade o tempo no banco correspondia a cerca de 6% do tempo total da transação.
Outros cenários interessantes foram alguns casos em que o comando foi escrito usando-se subqueries na cláusula select, e essas subqueries tinham plano de execução com “range scan” em algum índice ou tabela. Imaginem esse comando retornando 300 linhas e sendo executado 2K vezes por minuto, cada subquery do comando será executada 600K vezes por minuto. Nessa situação o próprio mecanismo interno do banco de dados causava um bloqueio em sua estrutura, um tipo de serialização (latch), devido ao alto volume de leituras nos mesmos blocos de dados.
O que tento mostrar aqui é que de modo geral a culpa não é do banco.
Eu considero “culpa” do banco no caso de algum bug de versão, parametrização incorreta ou algo do tipo. Nos outros casos o banco apenas reflete um problema na concepção do sistema, seja por codificação, componentes desatualizados, etc.
Analisar aplicação ou banco de dados?
Iniciar análise de um problema pela camada de banco de dados pode ser uma boa estratégia para eliminar a possibilidade de problema na camada ou até mesmo identificar algum problema gerada nas outras camadas, mas que está refletindo no BD.
A análise a partir da camada de banco de dados pode refletir em ajustes na aplicação, em lógica de programação ou ajustes nas escritas dos comandos, porém a camada de aplicação não deve ser esquecida, pois o foco é ter um ambiente escalável e resiliente.
Muitas vezes iniciar a análise pela camada de aplicação pode ser mais assertivo em termos de identificação do principal gargalo, porém pode demandar mais tempo, já que mais de uma camada pode deve ser avaliada.
Conclusão
Em suma a “culpa do banco” é algo relativo, pois em algumas vezes a contenção identificada na camada de BD pode ter um “peso” insignificante no tempo total de uma transação. Por isso cuidado ao falar que a culpa é do BD, monitore corretamente seu ambiente, avalie o peso do problema no todo e ataque o problema se ele for um “quick win”, uma “bala de prata”, só que na maioria das vezes o ajuste vai ter que ser feito na camada de aplicação.
Estamos cada vez mais num mundo DevOps, um time todo construindo e sustentando uma solução, não tem Dev ou Ops, não tem banco ou aplicação. Também não deveria ser o foco apenas pedir mais e mais infra para rodar um sistema que está lento, desde a sua concepção até sua utilização ele deve ser desenvolvido, testado e preparado para ser escalável e resiliente.
Por Ronaldo Sales – Gerente de Serviços