Testes de Carga - Parte 2 - Redes e SO

March 03, 2021

No post passado Testes de carga parte 1, falei sobre testes de carga e vimos algumas questões importantes relacionadas à infraestrutura e ao ambiente onde sua aplicação está localizada.

Neste post ainda não vamos disparar toda a artilharia contra o alvo. Calma!! Calma!! Vamos preparar o(s) alvo(s) para suportar carga, vamos ver pontos importantes que podem fazer diferença na hora que sua aplicação estiver aberta para o público.

Como primeira etapa, eu adoto um pensamento que é o seguinte, preparar os componentes da aplicação para uma carga bastante expressiva, porém, sem se descolar de uma realidade possível. Por exemplo, um único RaspberryPi, nunca seria capaz de dar conta de todas as buscas do Google, não existe configuração para isso :).

Como fazer para levantar os dados de uma aplicação nova ou desconhecida? Como saber seus limites e pontos de falha? Se não tiver nenhum dado de testes do passado que ajude a estabelecer esse limite mínimo, eu adoto as seguintes estratégias como ponto de partida: pegar os números uma aplicação semelhante, identificar os momentos de pico de utilização no ano anterior e buscar informações tipo:

Perfil da aplicação utiliza mais disco ou mais memória?
Quantidade de acesso ao front end
Quantidade de acesso ao back end
Quantidade de objetos guardado no cache
Quantidade de acesso ao banco de dados
Consumo de CPU
Consumo de memória

Com essas informações eu multiplicaria os valores por dois (2x), assim tenho um ponto de partida. Mas isso é um chute, sim é um chute mas não é no escuro, o importante é que agora que temos uma referência, vamos preparar os componentes para suportar essa carga.

Sistema operacional

Na parte de sistema operacional eu tive mais contatos com sistemas Linux/Unix as recomendações podem ser úteis para outros sistemas também. O sistema operacional é a alma da sua aplicação, ele é equivalente ao meio de campo fazendo um paralelo com o futebol, tudo passar por ele.

Em um sistema Linux/Unix todas operações envolvem abertura, leitura e escrita de arquivos, sejam arquivos que você mesmo gera com um simples vim teste.txt ou que o próprio sistema operacional gerando, chamando arquivos de comandos que chamam arquivos de bibliotecas que chamam outras bibliotecas que acessam um dado e trazem um resultado. Duvida que seja assim? Vamos testar? Roda aeee então!!

$ strace -t ls -las /etc

Viu?? Agora imagine um sistema operacional sob alta carga realizando essas e muitas outras atividades o tempo todo além de executar a sua aplicação :0? Minhas recomendações ajustar os seguintes parâmetros:

Aumentar a quantidade de arquivos abertos
Ajuste de prioridades de processos
Ajustes dos parâmetros de swap do sistema
Aumentar no tamanho das páginas de memória
Ajuste os tempos da fila de gerenciamento de acesso ao filesystem
Escolha um filesystem adequado para sua aplicação
Escolha um disco adequado para o filesystem
Escolha o tamanhos dos blocos de filesystem para sua aplicação

Redes

A parte mais legal de mexer é a parte de redes. Os ajustes na pilha TCP/IP vão depender muito do tipo de aplicação que será executada, seja qual for sua aplicação é necessário observar esses parâmetros de configuração:

Ajuste os buffers de memória da pilha IPv4
Ajuste o tempo time_outs e de keepalive das conexões
Ajuste o tempo de time_wait das conexões
Ajuste o tamanho do janelamento do TCP

Sistemas de cache distribuído

Durante os testes encontre uma maneira de desligar todos os mecanismos de cache da sua aplicação ou configure para zero segundos o tempo de armazenamento. Essa recomendação se aplica para todos os componentes da sua aplicação, na nossa arquitetura de exemplo estamos falando em desligar o cache do web server (front end), do application server (back end), do cache server e do banco de dados. Nesse primeiro momento não vamos testar os caches ainda.

Banco de dados

Bancos de dados sem dúvida será um problema para aplicações dinâmicas que precisam ser protegido por outros componentes da aplicação, mas para os testes recomendo os seguintes ajustes:

Limite as queries (sempre)
Identifique as querys mais demoradas e reveja seus planos de execução
Sempre que possível substitua queries com (%)
Faça as inserções todas de uma vez

Monitoração

Último ponto!!! Não vai adiantar nada fazer todos os passos citados se você não tiver um bom sistema de monitoração. Um bom sistema de monitoração deve mostrar as seguintes informações:

Histórico de utilização
picos e quedas de utilização
Média de utilização de CPU, memória, discos
Gráficos de tendências de alta e de baixa

Uma boa ferramenta de monitoração deve ser capaz de fornecer uma visão de cada componente separado ou por grupo. Gosto bastante da combinação Promethues + Grafana.

Conclusão

Fazer tuning de aplicação não é ciência de foguete mas também não é só ligar ou desligar uma chave, requer tempo, observação, método e principalmente paciência. Siiimmmm paciência, paciência para testar cada modificação e entender o efeito causado por ela em todo o sistema.

Importante falar, todas as recomendações seguem uma linha geral de recomendações e de boas práticas, aplicações específicas requerem modificações específicas. Os sistemas na sua empresa certamente possuem restrições bem específicas e será necessário fazer algumas adaptações.

No próximo post vamos finalmente falar de testes de carga!!!

Vida longa e próspera!!

Referências

Convido você a ver os outros posts do blog Infra-as-Code.

Nossos contatos são:
Email – [email protected]
Twitter - @infraascodebr

--- --- IMPORTANTE --- ---
As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.