Testes de Carga - Parte 2 - Redes e SO
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
- https://www.mysql.com/why-mysql/performance/index.html
- https://docs.oracle.com/cd/E23389_01/doc.11116/e21036/perf002.htm
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/performance_tuning_guide/index
- https://cromwell-intl.com/open-source/performance-tuning/tcp.html
- https://prometheus.io/
- https://grafana.com/
Eu adoraria ouvir suas outras histórias e situações semelhantes ao que acabei de escrever neste post, você pode me encontrar em @infraascode_br ou linkedin.com/in/leonardoml/ .
Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!
|
|
