Teste performance carga stress jmeter

(48) 3285 5615 / 9645 5506
contato@qualister.com.br

•  Terceirização de profissionais
•  Consultoria de teste Qualister

•  Avaliação de usabilidade
•  Automação de testes
Testes
de
performance

•  Testes de performance
•  Treinamentos

www.qualister.com.br

Quer saber mais?

Estes
são
apenas
alguns
slides
do
curso
de
testes

de
performance
com
JMeter
e
outras

ferramentas
oferecido
pela
Qualister.

Para
maiores
informações
visite
nosso
site:

h?p://www.qualister.com.br/cursos


Direitos autorais

Importante er
produção de qualqu
proibida a cópia e re
–  É resentação incluindo,
parte do conteúdo desta ap
, imagens, gráficos e
mas não limitado a, textos
é protegida pelas leis
tabela s. Esta apresentação no
opriedade de Cristia
de Copyright e são pr e Treinamento
Caetano e Qualister Consultoria
LTDA.

r, copiar, guardar em
–  Não é permitido modifica
ugar, vender ou
banco de dados público, al
apresentação,
republicar qualquer parte desta
o explícita do autor.
sem prévia permissã

o deste material,
–  Quando ho uver permissão de us e
bibliográfica conform
é ob rigatória a referência
as normas vigentes.


Instrutor

Cristiano Caetano
Email: cristiano.caetano@qualister.com.br
Apresentações: slideshare.net/cristianocaetano
Blog: cristianocaetano.wordpress.com
É certificado CBTS pela ALATS. Diretor técnico da Qualister com mais de 10 anos de experiência, já
trabalhou na área de qualidade e teste de software para grandes empresas como Zero G, DELL e HP
Invent. É colunista na área de Teste e Qualidade de software do site linhadecodigo.com.br e autor dos
livros "CVS: Controle de Versões e Desenvolvimento Colaborativo de Software" e "Automação e
Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções Open Source e
Gratuitas". Participante ativo da comunidade de teste de software brasileira, é o criador e mantenedor
do portal TestExpert: A sua comunidade gratuita de teste e qualidade de software
(www.testexpert.com.br).


Twitter

twitter.com/c_caetano


Sobre a Qualister

•  Fundação: 2007.
•  Sobre a Qualister: A Qualister é uma empresa nacional, constituída a partir da união
de profissionais qualificados e certificados na área de testes e qualidade de software,
com o objetivo de integrar, implementar e implantar soluções com base nas melhores
práticas do mercado e normas internacionais.
•  Colaboradores: A Qualister é composta por colaboradores pós-graduados e
certificados na área de testes (CBTS, CSTE) com larga experiência na indústria de
Tecnologia da Informação.
•  Área de atuação: A Qualister é uma empresa especializada em serviços de
qualidade e teste de software. Tem como linhas de atuação consultoria em teste/
qualidade de software, outsourcing (terceirização dos serviços através da alocação
de profissionais) e treinamentos.


Parcerias internacionais

Soluções para automação, profilling e gestão de testes

Soluções para testes de performance

Soluções de apoio a avaliação de usabilidade


Agenda

•  Parte 1:
–  Por que os testes de perfomance são importantes?
–  Performance: Carga, Volume e Estresse
–  O que o teste de performance não é
–  Visão geral da arquitetura
–  Termos e conceitos

•  Parte 2:
–  Objetivos dos testes de performance
–  Validar os requisitos de performance
–  Validar o impacto da adição de novas funcionalidades (Regressão)
–  Descobrir os bottlenecks (gargalos)

•  Parte 3:
–  Planejamento dos testes de performance
–  Identificar workload e criar casos de teste
–  Definir métricas, baseline e benchmarks
–  Definir ferramentas, infra-estrutura e recursos humanos
–  Executar os testes e analisar os resultados
–  Tuning e troubleshooting

•  Parte 4:
–  Exercícios


Tópico

• Introdução


Por que os testes de performance são importantes

–  Garantir um tempo de resposta dentro de padrões
aceitáveis para evitar o abandono do site ou aplicação
em função de tempos de resposta inaceitáveis (perda de
receita);

–  Garantir o uptime (alta disponibilidade) de aplicações e
serviços de missão crítica (perda de receita, riscos de
vida);

–  Evitar o fracasso dos projetos em virtude de problemas
de performance e escalabidade (imagem e credibilidade
da empresa);

–  Garantir os investimentos de TI por meio da previsão da
escalabilidade e performance da aplicação (pouco ou
muito investimento em infra-estrutura);


O que o teste de performance não é

•  Teste de performance não é teste funcional. As
técnicas, ferramentas e habilidades necessárias
para executar os testes de performance são
diferentes. Pode haver uma intersecção entre
ambos tipos de testes, mas eles nunca serão
iguais.

Testes Testes de
Funcionais Performance


O que o teste de performance não é


Page Response Time

•  É o tempo entre a requisição de uma operação e a
subsequente exibição da página esperada. É a
medida de performance que importa ao usuário
final.


Qual a performance ideal?


Page Response Time - Estudos Formais

•  Um estudo conduzido por Nina Bhatti, et al,
observou como os usuários reagiam quando eles
eram direcionados a usar um website para
configurar e comprar um computador. O estudo
identificou que existia frustação quando o tempo de
resposta era por volta de 10 segundos. Por outro
lado, essa tolerância diminuía de 10 para 4
segundos quando o processo e configuração de
compra do computador estava próximo do fim.

Integrating User-Perceived Quality into Web Server Design by Nina Bhatti, Anna Bouch, Allan
Kuchinsky, 9th International World Wide Web Conference, 2000.


Page Response Time - Estudos Formais

•  Jared M. Spool conduziu outro estudo com diversos
usuários que deveriam visitar 10 sites diferentes e utilizar os
recursos dos sites conforme o interesse de cada um. Cada
usuário deveria pontuar a velocidade de cada site conforme
a sua percepção. Ao final dos testes, percebeu-se que o site
considerado o mais devagar de todos pelos usuários
(about.com) era, na verdade, o mais rápido de todos, com
um tempo de resposta de 8 segundos. Por outro lado, o
site amazon.com foi considerado o mais rápido de todos,
mas no entanto, o seu tempo de resposta era de 36
segundos. Concluíram que essa percepção contraditória
está ligada aos elementos visuais da página. Em média, os
usuários gastam cerca de 4 segundos lendo cada
elemento. O site amazon.com oferece vários elementos
interessantes do ponto de vista do usuário, dessa forma,
após a requisição de uma operação, o usuário gasta vários
segundos lendo esses elementos o que torna a perceção de
que o tempo de resposta do site é inferior aos 36 segundos
mensurados.
Jared M. Spool, An interview with Jared Spool of User Interface Engineering, conducted by John Rhodes
for WebWord,July 2001.

Page Response Time Fórmula


Page Response Time - Page Size

•  O tamanho da página e a quantidade de
elementos (imagens, applets, etc) são fatores que
afetam o Page Response Time.
http://www.websiteoptimization.com/services/analyze/


Page Response Time - Minimum Bandwidth

•  A banda efetiva entre o cliente
e o servidor é determinada pela
banda mais lenta.


Page Response Time – Round Trip/Turns

•  O termo Turns define o número de conexões TCP necessárias para
fazer o download de uma página. No protocolo HTTP 1.0 são
necessários quatro Turns para fazer o download de uma página. Para
fazer o download dos elementos da página (imagens, applets, etc) são
necessários no mínimo três Turns.


Page Response Time - Server Processing Time

•  Indica o tempo que um servidor leva para
processar uma requisição. O tempo de
processamento em cada uma das camadas, a
velocidade da rede e o sistema operacional afetam
o valor total do tempo de processamento.


Page Response Time - Server Processing Time


Page Response Time - Client Processing Time

•  Indica o tempo que o cliente (browser) leva para
processar e exibir uma página. O tempo de
download e execução dos plug-ins e o tempo de
renderização dos elementos da página afetam o
valor total do tempo de processamento.


Page Response Time - Client Processing Time (Cont.)

•  Load Time Analyzer
–  https://addons.mozilla.org/firefox/3371/
•  YSlow
–  http://developer.yahoo.com/yslow/help/
•  Safari Web Inspector
•  Google SpeedTracer
–  http://code.google.com/intl/pt-BR/webtoolkit/speedtracer/
•  Ajax DynaTrace http://ajax.dynatrace.com/ajax/en/


Tópico

• Conceitos


Throughput

•  Throughput é uma medida de trabalho
(processamento) por unidade de tempo.

–  Quantidade de cliques por segundo;
–  Quantidade de páginas aberta por segundo;
–  Quantidade bytes transferidos entre o servidor e o cliente por
segundo;
–  Quantidade de requisições processadas pelo servidor por segundo;
–  Entre outros;


Utilização

•  Utilização indica o percentual de ocupação de
um recurso (Processador, Disco, Memória, etc) por
unidade de tempo.


Escalabilidade

•  Escalabilidade indica a capacidade da aplicação (e infra-
estrutura) em lidar com cargas além dos limites previstos
sem afetar o tempo de resposta ou a capacidade de
processamento. A aplicação e a infra-estrutura podem ser
escalados por meio da adição de recursos extras (maior
capacidade de processamento, maior quantidade de
memória, banda de rede, armazenamento, etc).

•  Em geral, os testes de escalabilidade são utilizados para
determinar o número máximo de usuários que podem
utilizar a aplicação sem degradar o tempo de resposta e o
throughput.


Profiler

•  Profiler é uma aplicação utilitária que mede a
performance e utilização de recursos durante a
execução da aplicação. O objetivo do Profiler é
auxiliar o desenvolvedor a encontrar as áreas da
aplicação que necessitam de otimização.


Virtual Users

•  Testes de performance realizados por testadores
de verdade são difíceis de coordenar, não são
repetitíveis, são suscetíveis a erros, etc.


Virtual Users

•  Virtual Users (VU) simulam usuários de verdade
para a realização dos testes de performance. O
comportamento dos VU é controlável, previsível e
repetitível, produzindo resultados confiáveis.


User Think Time

•  O User Think Time faz os Virtual Users se
comportarem como se fossem usuários reais. Por
meio do Think Time, são injetados atrasos e
paradas variáveis nos testes para simular cargas
de utilização mais realistas.


User Think Time

•  Durante a definição do User Think Time, devemos
considerar que, mesmo os usuários reais
navegam com maior ou menor velocidade de
acordo com a sua familiaridade com o site.


Bottlenecks (Gargalos)

•  Em um sistema com mais de um componente, o
bottleneck (gargalo) é o recurso com a menor
capacidade de trabalho (Throughput) por unidade
de tempo. A performance do bottleneck (gargalo)
limita a performance do sistema inteiro.


Benchmarks

•  Benchmark é um tipo de teste ou testes designados para
comparar a performance e outros atributos de dispositivos
ou sistemas da mesma categoria. Podemos comparar
diversos aspectos da performance da infra-estrutura de
testes contra Benchmarks realizados pela indústria de TI.

http://www.mindcraft.com/whitepapers/first-nts4rhlinux.html


Tópico

•  Estratégias de teste
de performance


Objetivos dos testes de performance

•  Os principais objetivos do teste de
performance são:
–  Validar os requisitos de performance
–  Validar o impacto da adição de novas
funcionalidades (Regressão)
–  Descobrir os bottlenecks (gargalos)


Testes de Regressão de performance

•  Modificações que podem impactar na performance
da aplicação:

–  Adição/modificação de funcionalidades;

–  Redesign do sistema;

–  Mudança de infra-estrutura (HW);

–  Upgrade ou mudança de software (OS, Banco de
dados, etc);


Descobrir os gargalos (bottlenecks)

•  Caso algum requisito de performance não atingir o
seu SLA durante os testes, todos os esforços
devem ser direcionados para as atividades de
investigação e troubleshooting para descobrir
quais são os bottlenecks (gargalos).

“Podem existir bottlenecks mesmo quando as
aplicações atingem os seus requisitos de
performance”



•  Os bottlenecks (gargalos) podem ser encontrados
em qualquer elemento da arquitetura.



•  Os bottlenecks (gargalos) também podem ser
encontrados em elementos fora da arquitetura.



•  Causadores de bottlenecks (métricas da indústria
de TI).



•  Problemas no design e no código da aplicação
também podem causar bottlenecks.
for( int i=0; i<object.size(); i++ ) {
for( int j=0; j<object2.size(); j++ ) {
int threshold = system.getThreshold();
if( object.getThing() – object2.getOtherThing() > threshold ) {
// Do something
}
}
}

int threshold = system.getThreshold();
for( int i=0; i<object.size(); i++ ) {
for( int j=0; j<object2.size(); j++ ) {
if( object.getThing() – object2.getOtherThing() > threshold ) {
// Do something
}
}
}



•  Problemas de performance, gargalos e memory
leakage no código podem ser detectados por meio
da utilização de profilers de memória e código
durante a execução dos testes de unidade ou
durante a execução dos testes de performance.
JProbe - http://www.quest.com/jprobe/



ANTS Profiler (.NET) - http://www.red-gate.com/products/ants_profiler/index.htm


Tópico

•  Planejamento e execução
dos testes de performance


Planejamento dos testes de performance

•  Perguntas essenciais para iniciar o planejamento:

1.  Qual a quantidade de usuários concorrentes esperados em situações normais e de pico?

2.  Quem são os usuários típicos? Quais navegadores eles usam? Que computadores eles usam?
Qual a banda de rede que eles usam?

3.  Quais são as funcionalidades mais usadas ou tarefas/transações comumente realizadas pelos
usuários?

4.  Qual o tempo de resposta aceitável para tais tarefas em situações normais e de pico?

5.  Qual a carga de usuários máxima aceitável antes que o tempo de resposta degrade a um
ponto inaceitável?

6.  Qual é a arquitetura e infra-estrutura do sistema?


Workload

•  Com base na distribuição do workload podemos
definir os casos de testes candidatos para a
automação.


Infra-estrutura

•  Definir infra-estrutura de testes (o mais próximo do ambiente de
produção possível)

–  Servidores e software (OS, patches, Web Servers, Application
Servers, Load Balancers, Banco de dados, etc);

–  Infra-estrutura de rede necessária (Placas de rede (10/100 mb),
hubs, switches, etc);

–  Massa de dados;


Papéis e responsabilidades

•  Profissionais envolvidos nos testes de
performance:

–  Testadores;

–  Administradores de Banco de dados;

–  Arquitetos de rede (ou suporte técnico);

–  Desenvolvedores/Arquitetos de software;


Executar os testes e analisar os resultados

•  Melhores práticas:
–  Antes de iniciar os testes reais, execute os testes com uma carga
com cerca de 25% da carga prevista por um período curto de tempo
para aquecer (warm-up) o servidor;
–  Não execute os testes na rede local;
–  Execute o mesmo conjunto de testes várias vezes no mesmo dia e
durante vários dias na semana para garantir que os resultados são
consistentes;
–  Garanta que os requisitos e critérios de aceitação sejam específicos;
–  Use monitores também no computador(es) que irão executar os
geradores de carga para evitar bottlenecks (gargalos);
–  Utilize uma massa de dados equivalente aos dados de produção;
–  Stakeholders não querem relatórios com gráficos e tabelas confusas,
eles querem conclusões e conselhos;


Troubleshooting & Tuning

•  Prováveis causadores de bottlenecks
(gargalos)
–  Confirme se a aplicação ou o Web Server não estão com opções de DEBUG ou
TRACE ativadas;
–  Memory Leaks;
–  Páginas grandes com muitos elementos gráficos e CSS;
–  Confirme se o protolo SSL (Secure Sockets Layer) é usado apenas onde é necessário
(causa cerca de 20 a 30% de perda de performance);
–  SQL Queries ou Stored Procedures escritos incorretamente;
–  Problemas no design do banco de dados relacional (5 formas normais usadas ao pé
da letra);
–  Uso incorreto ou falta de índices no banco de dados;
–  Muitas conexões abertas com o banco de dados (connection pools não liberadas);
–  Firewalls e switches malconfigurados podem causar bottlenecks de rede;
–  CPU/Memória/Disco/Rede (mal dimensionados);
–  Elementos externos (autorizadores de crédito, sistemas legados, etc);


Dúvidas?

•  Contato:
–  Email: cristiano.caetano@qualister.com.br


Teste performance carga stress jmeter

Mais conteúdo relacionado

Mais procurados

Semelhante a Teste performance carga stress jmeter

Teste performance carga stress jmeter