Análise das Métricas Performance - Measurement-and-Metrics-2018-1/2017.1-SIGS GitHub Wiki
| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 27/05/2018 | 0.1 | Criação do Documento | Gabriel Ziegler |
| 01/06/2018 | 0.2 | Elaboração da estrutura do artefato | Gabriel Ziegler |
| 02/06/2018 | 0.3 | Adição dos gráficos do teste de estresse com 50, 500 e 2500 requisições | Gabriel Ziegler |
| 03/06/2018 | 0.4 | Análise dos resultados das medições do teste de estresse | Gabriel Ziegler |
| 22/06/2018 | 0.5 | Linking Smartmeter to tools, linking coleta | Thiago Ferreira |
| 22/06/2018 | 0.6 | Adição de gráficos dos testes de Server Hits, Transactions/Seconds, Controller Byter Over Time, Response Codes/Seconds, Threads Over Time, Response Times Percentiles, Local Performance | Gabriel Ziegler |
| 22/06/2018 | 0.7 | Adição de análise dos resultados dos testes de uso | Gabriel Ziegler |
| 22/06/2018 | 0.8 | Adição de análise dos resultados dos testes de desempenho local e aumento de threads | Thiago Ferreira |
| 22/06/2018 | 0.9 | Adição de análise das etapas do teste realizado | Gabriel Ziegler |
| 23/06/2018 | 1.0 | Conclusão e providências a serem tomadas | Gabriel Ziegler e Thiago Ferrreira |
As medições apresentadas a seguir seguem os planejamentos levantados no GQM de Performance.
Para uma análise mais aprofundada do processo de coleta das métricas de performance, clique aqui
A análise dos resultados foi feita utilizando de ferramentas como Jupyter e Plotly como recursos de visualização de dados em cima das métricas geradas com as ferramentas de medição.
Um gráfico apresentado foi o de latência por requisições executadas pela ferramenta de teste.
Os testes realizados acima possuem resultados com alto grau de correlação, isto é, os procedimentos efetuados durante o teste do sistema afetaram de forma congruente todos os setores acima analisados. Os gráficos apresentados acima apresentam três etapas mais acentuadas que devemos analisar. Essas três etapas se dão pelas diferentes funcionalidades que foram estressadas ao longo do teste de uso. Podemos definir essas três etapas da seguinte maneira.
Cenário: Usuário conhecendo o sistema e navegando por páginas que aparecem no menu principal.
Nessa etapa, o sistema não apresenta alta demanda de recursos computacionais localmente e nem dos servidores.
Cenário: Usuário usando de funcionalidades que usam de requisições HTTP, leitura e escrita no disco rígido, etc.
Ex: Gerar Relatórios
Esta etapa se caracteriza por tem uma alta demanda de recursos computacionais. Os picos nos gráficos, que representam alto número de requisições de diversos usuários diferentes acompanha uma crescente de aumento na latência das respostas do servidor e aumento também no número de requisições falha.
Cenário: Usuário usando de funcionalidades que usam de requisições HTTP, leitura e escrita no disco rígido, etc.
Essa etapa compreende as ações que o usuário produziria após a geração de relatórios, essas ações geram demanda computacional assim como a etapa 2, porém uma demanda de menor esforço para o sistema processar.
Durante a execução dos testes, no plano de teste, estabeleceu-se um aumento de threads para atuarem no sistema, evantando o número de usuários virtuais por 1 a cada 7,2 segundos, durante 12 minutos, totalizando um total de 100 ramp-ups/threads.
Fazendo uma relação com os demais gráficos gerados, pode-se observar que, mesmo elevando o número de usuários para 100, gradativamente, não houve uma diferença considerável se tomado em conta os demais resultados.
O gráfico de desempenho local, derivado do teste realizado, representa a quantidade de memória RAM e CPU que o uso contínuo do sistema, durante a realização do teste,consumia.
Com o gráfico gerado, pode-se observar que, o sistema testado não gerou um impacto de consumo muito grande no sistema testante, tendo um uso de memória RAM fortemente constante e um consumo de CPU baixo com exceção da primeira instância, provavelmente devido ao ínicio do teste e a instância final que consistia da etapa de geração de relatórios, analisada anteriormente.
Comportamento do sistema homogêneo entre duas faixas predominantes de latência. Mínimos casa dos 200. Máximas entre 350 e 400 de latência. Comportamento OK.
Comportamento do sistema com mais divergências. Mínimos entre 200 e 250, com alguns outliers ultrapassando 250. Máximas entre 350 e 450 de latência. Comportamento já com algumas discrepâncias.
Análise Uma vez que concluída as medições, o time de medição analisa que o sistema, caso vir a ser utilizado por um número maior que o atual de usuários (mais que 50 usuários em paralelo), deverá atualizar os hardwares e serviços que o mantém ativo, como: servidor de hospedagem do sistema.
Comportamento equilibrado em duas faixas predominantes. Mínimos aproximadamente em 200, com alguns outliers ultrapassando 250. Máximas entre 350 e 450 de latência com alguns outliers ultrapassando 500 e um ponto perto de 1000 de latência. O sistema mostrou-se mais vulnerável nesse teste, onde o estresse gerado ao sistema foi maior.
Quanto as análises das métricas coletadas nos testes de performance e a análise dessas comparando com as baselines propostas no plano de medição, vemos que as baselines, apesar de darem uma ideia um tanto quanto abstrata, batem com os resultados dos testes realizados.
O sistema no quesíto performance, apresenta um rendimento sólido com uma quantidade reduzida de usuários (50 usuários por vez), algumas requisições começam a ter latências maiores e maior índice de falhas quando o número de usuários cresce. Isso pode se dar pelo sistema de hospedagem utilizado, pela modelagem do banco de dados, pela complexidade de código, número de APIs utilizadas, quantidade de requisições por tarefas, etc.
Com Relação ao desempenho local do sistema, foi possível observar resultados bons, trazendo que, não houve uma elevada demanda nem variação de desempenho tanto no processador quanto na memória.
Uma vez que concluída as medições, o time de medição analisa que o sistema, caso vir a ser utilizado por um número maior que o atual de usuários (mais que 50 usuários em paralelo), deverá atualizar os hardwares e serviços que o mantém ativo, como: servidor de hospedagem do sistema. Também conclui-se que, para melhorar a latência do site, seria necessário trocar a hospedagem do aplicativo, que hoje, é hospedada pelo Heroku, servidor que, localiza-se a uma distância considerável da região de uso do site.
Além disso, os códigos fonte do sistema devem ser reavalidos visando: número de APIs utilizadas, complexidade de funções e modelagem do banco de dados.
Uma vez que essas etapas forem solucionadas, deverá-se gerar um novo plano de medição e novas métricas para analisar a evolução da baseline.