A percepção do seu usuário

Por Mauricio Medina

Observem os seguintes gráficos:

Gráfico 1

Gráfico 2

Qual a diferença?

Estes são 2 gráficos de antes e depois de uma analise de problemas e uma intervenção no código da aplicação. Na minha última matéria, apresentei um modelinho de processo com ferramentas para analisar o comportamento de uma aplicação.

Neste pretendo discutir como é a percepção dos usuários dos sites e aplicações Web.

Se olharem o gráfico 1, com uma quantidade de 13 usuários o tempo de resposta médio é de 5 segundos e depois o tempo cai. Como o teste foi feito com 20 usuários virtuais simultâneos, alguma coisa deve ter acontecido, tipo cachê ou outra coisa para baixar o tempo, mas neste gráfico fica explicito que há uma oscilação muito forte.

Quando fizemos este teste, monitoramos o ambiente com os monitores disponíveis para os servidores e rede. Estes não apontaram nenhum problema enquanto a aplicação era testada, o que confirma minha teoria de que não adianta somente monitorar a infra, mas também a aplicação e suas transações como descrevi na matéria anterior.

Nós analisamos as transações da aplicação que estavam sendo executadas durante o teste e identificamos vários pontos suspeitos de criar os vários gargalos usando o que mostrei na matéria anterior.

Incrivelmente, os monitores de infra não acusaram nenhum comportamento estranho quando os tempos oscilaram quando os tempos de resposta foram altos, o que já era esperado... Mais uma vez o problema estava na aplicação e não na infra, que muitas vezes é superestimada para suportar a aplicação.

Fizemos várias alterações na aplicação, sempre orientados para resolver um problema de cada vez, sem cair na tentação de tentar descobrir e resolver tudo ao mesmo tempo. Para cada alteração, disparamos o teste com os 20 usuários virtuais até conseguir o comportamento descrito no gráfico 2.

Observem que os tempos de resposta ficaram bastante consistentes, com uma média de 1,9 segundo quando todos os usuários virtuais estavam ativos. O ponto aqui não foi somente monitorar as transações e seus componentes, mas realizar o teste de carga a cada intervenção no código, uma vez que mesmo tendo indícios de quais os componentes eram suspeitos, a melhor confirmação era o relatório com os tempos de resposta após cada intervenção.

Simplifiquei o processo de mostrar os vários relatórios para apenas o antes e o depois para ilustrar que sem estes testes, fica muito difícil se realizar de fato correções objetivas nas aplicações. A idéia é que se possa fazer o teste de carga com a simplicidade e a qualquer tempo, num processo que se possa disparar o tempo todo, desde uma migração de versão até uma correção de emergência.

Ao contrário das ferramentas do passado, que exigiam um enorme investimento de infra-estrutura e custos elevados das ferramentas, usamos um serviço de testes remoto, que permite que se faça testes quantas vezes houver a necessidade, mantendo todos os ativos de teste em nosso poder e por um preço muito acessível.

Esta é a forma mais simples, barata e confiável de se garantir que a percepção dos seus usuários vai ser a melhor, e que além disto, você ficará sabendo de problemas de tempos de resposta antes dos problemas chegarem aos seus usuários.

O quê seu usuário acha da sua aplicação?

Abraços