Neste artigo, vamos discutir os principais aspectos sobre a taxa de transferência em testes de desempenho.
Antes de começar com os detalhes, vamos dar uma olhada em alguns fundamentos do teste de desempenho.
O teste de desempenho é importante porque:
Você pode iniciar o teste de desempenho o mais cedo possível nos estágios de desenvolvimento de seu aplicativo de software. Desta forma, você pode otimizar seu servidor web e evitar custos de negócios em estágios posteriores.
Descobrir os problemas no desempenho após a implantação do aplicativo significa muitas horas de trabalho para corrigir os problemas. Portanto, pode ser muito caro.
Assim que as páginas da web básicas do aplicativo funcionarem, a equipe de garantia de qualidade deverá realizar os testes de carga iniciais. A partir desse ponto, eles devem realizar testes de desempenho regularmente para cada compilação.
Existem diferentes ferramentas e critérios para testar o desempenho dos aplicativos. Aqui vamos falar sobre uma medida importante, ou seja, throughput.
Cada aplicativo de software ou site tem muitos usuários que realizam diferentes solicitações. Os testadores precisam garantir que o aplicativo atenda à capacidade necessária de solicitações antes de entrar no ar.
Existem alguns princípios básicos de teste de desempenho que precisam ser medidos durante o processo. A taxa de transferência é um deles . Vamos descobrir o que é rendimento em testes de desempenho.
Antes de iniciar o teste, precisamos definir uma meta realista de taxa de transferência de desempenho, para que possamos obter resultados mais precisos e confiáveis.
Estes são alguns fatores importantes para determinar a taxa de transferência realista:
Aqui, explicaremos o conceito de taxa de transferência com a ajuda de um exemplo da vida real. Imagine que há uma barraca de fast food chamada “Yummy Burgers”. Eles servem hambúrgueres e batatas fritas para os clientes.
Digamos que os “Hambúrgueres Gostosos” tenham três funcionários na barraca, e cada funcionário sempre leva 5 minutos para servir a comida a um cliente.
Portanto, se eles tiverem três clientes na fila para serem atendidos por três funcionários, isso significa que “Yummy Burgers” pode servir comida para três clientes em 5 minutos.
Portanto, se precisarmos fazer um relatório de desempenho de “Yummy Burgers”, ele mostrará que sua taxa de transferência é de três clientes a cada cinco minutos.
O dilema do Yummy Burgers é que, não importa quantos clientes estejam esperando pela comida, o número máximo que eles podem atender durante um período de tempo específico será sempre o mesmo, ou seja, três. Este é o rendimento máximo .
À medida que mais clientes fazem fila para comer, eles devem esperar sua vez, criando uma fila.
O mesmo conceito se aplica ao teste de um aplicativo da web.
Se um aplicativo da Web receber 100 solicitações por segundo, mas puder lidar com apenas 70 solicitações por segundo, as 30 solicitações restantes deverão aguardar em uma fila.
Nos testes de desempenho, denotamos taxa de transferência como “Transações por segundo” ou TPS .
O uso do Apache JMeter é bastante popular para testar o desempenho de um aplicativo de software. O JMeter é útil para determinar o número máximo de usuários simultâneos que o aplicativo pode manipular e também fornece uma análise gráfica para testes de desempenho.
O JMeter fornece várias maneiras de registrar o valor da taxa de transferência. Aqui estão alguns ouvintes do JMeter que você pode usar para essa finalidade:
O JMeter também fornece um componente de cronômetro, ' Constant Throughput Timer' , que você pode usar para definir o valor de Transações por segundo (TPS) para testar a carga do aplicativo.
Agora, mostraremos o uso do throughput no teste de desempenho usando o JMeter. Digamos que vamos realizar um teste de amostra com 100 threads simultâneos e rastrear o valor do throughput.
Suponha que temos a versão mais recente do JMeter instalada em nosso sistema e já realizamos todas as outras configurações necessárias. Agora, temos que construir um plano de teste.
Neste teste, vamos definir cinco elementos ThreadGroup. Cada um desses elementos terá um tempo de aceleração diferente, ou seja, 0, 15, 25, 35 e 45. O tempo de aceleração é a duração para iniciar cada thread. Vamos configurar 100 usuários nesses elementos ThreadGroup.
Se quisermos configurar um número maior de usuários, será necessário mais tempo de ramp-up.
Esses grupos de encadeamentos terão um amostrador HTTP que gerará solicitações na página inicial de um site de amostra (suponha que www.samplesite.com).
No Caso de Uso 1, temos um elemento ThreadGroup configurado com 100 threads, e seu tempo de ramp-up é 0.
Ele terá o campo “Number of Threads” definido como 100. Isso significa que 100 usuários enviarão solicitações de uma só vez. Da mesma forma, também podemos configurar os 4 threads restantes e definir seu tempo de aceleração como 15, 25, 35 e 45. Além disso, nomeie os samplers para cada grupo de threads.
Conforme mencionado anteriormente, esses exemplos de HTTP apontarão para a página inicial do site de exemplo.
É necessário executar esses grupos de encadeamentos em uma sequência adequada. Para isso, selecione “Test Plan” no painel de controle e marque o campo “Run Thread Groups consecutivamente”.
“Aggregate Report” é um ouvinte usado para analisar e observar os resultados do teste. Para usar este listener, clique com o botão direito em “Test Plan” e selecione:
Adicionar → Ouvinte → Relatório agregado
Em seguida, clique no ícone Iniciar para executar o teste.
Agora, vamos ver como entender os resultados de throughput do Relatório Agregado.
O primeiro grupo de encadeamentos com tempo de aceleração 0 mostra que todos os encadeamentos colocam uma carga instantânea no servidor iniciando de uma só vez. Este cenário tem um throughput razoavelmente alto, mas não é prático. Portanto, isso não mostrará uma saída realista.
O segundo e o terceiro grupos de encadeamentos têm um tempo de aceleração de um intervalo realista, portanto, é mais provável que eles mostrem rendimento de desempenho adequado e tempo de carregamento de solicitação.
Os grupos de encadeamentos quatro e cinco têm tempo de aceleração mais alto, o que significa que seu rendimento diminuirá.
Portanto, a saída confiável pode ser determinada a partir dos resultados do segundo e terceiro grupo de threads.
A decisão de implantação de uma nova versão ou alteração depende da capacidade do aplicativo de lidar com TPS específico. Assim, o plano de teste de desempenho tem certas metas de rendimento. Mas precisamos garantir que essas metas sejam realistas e representem as verdadeiras características da produção.
O plano de teste é em vão se passarmos usando condições irrealistas. Por exemplo, o plano de teste descrito acima tinha valores mais altos de taxa de transferência para o primeiro grupo de threads, mas não representava o cenário real do ambiente ativo.
Portanto, ao usar esses métodos, não podemos ter uma ideia adequada se nosso aplicativo vai lidar com a carga real ou não. Portanto, a criação de testes adequados é crucial.
Resumindo, a taxa de transferência é um indicador de desempenho crucial de aplicativos da web . Porém, depender apenas das métricas de throughput não é suficiente. Portanto, ele precisa ser verificado com latência e tempos de resposta .
Também é muito importante criar uma taxa de transferência realista para atingir as metas de teste de desempenho definidas.