Mudanças entre as edições de "Orientações gerais para testes de desempenho"
(→Definição de indicadores) |
m (Protegeu "Orientações gerais para testes de desempenho" ([edit=sysop] (tempo indefinido) [move=sysop] (tempo indefinido))) |
||
| (67 edições intermediárias de 3 usuários não apresentadas) | |||
| Linha 1: | Linha 1: | ||
== '''INTRODUÇÃO''' == | == '''INTRODUÇÃO''' == | ||
| − | Testes de desempenho têm a função de verificar se o sistema alvo atende aos requisitos de desempenhos especificados. Além disso, permitem avaliar características não funcionais do sistema relacionadas, como capacidade, vazão e tempo de resposta [http://www.computer.org/web/swebok]. Contudo, o objetivo do teste de desempenho é o mesmo de qualquer outro teste, que é o mesmo da | + | Testes de desempenho têm a função de verificar se o sistema alvo atende aos requisitos de desempenhos especificados. Além disso, permitem avaliar características não funcionais do sistema relacionadas, como capacidade, vazão e tempo de resposta [http://www.computer.org/web/swebok]. Contudo, o objetivo do teste de desempenho é o mesmo de qualquer outro teste, que é o mesmo da própria disciplina de Engenharia de Software: entregar produto de qualidade. E qualidade, do ponto de vista do usuário, além dos aspectos funcionais, certamente inclui a velocidade de resposta para as operações realizadas no sistema. Apesar disso, testes de desempenho frequentemente deixam de ser realizados, fadando inclusive sistemas ''bug free'' ao fracasso pela baixa percepção de qualidade por parte dos usuários. |
== '''PREMISSAS''' == | == '''PREMISSAS''' == | ||
| − | Executar testes de desempenho é uma | + | Executar testes de desempenho é uma atividade complexa e, por consequência, bastante onerosa ao processo de desenvolvimento. Contudo, são inúmeras as vantagens colhidas de testes bem executados [http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx] [http://www.testar.me/#!teste-de-performance/c1oeb]. Esta complexidade está relacionada principalmente às atividades necessárias antes da execução propriamente dita dos testes de desempenho. Este capítulo descreve algumas destas atividades e como elas contribuem para o sucesso do processo de teste. |
=== '''Funções testadas''' === | === '''Funções testadas''' === | ||
| Linha 10: | Linha 10: | ||
=== '''Definição de indicadores''' === | === '''Definição de indicadores''' === | ||
| − | Como apresentado na introdução deste documento, testes de desempenho têm a função de verificar se o sistema alvo atende aos '''requisitos de desempenho especificados'''. Para tanto, é necessário definir estes requisitos. É preciso definir, para cada função eleita, consideradas suas características, qual o requisito de desempenho esperado. | + | Como apresentado na introdução deste documento, testes de desempenho têm a função de verificar se o sistema alvo atende aos '''requisitos de desempenho especificados'''. Para tanto, é necessário definir estes requisitos. É preciso definir, para cada função eleita, consideradas suas características, qual o requisito de desempenho esperado. Esse requisito é uma definição de Acordo de Nível de Serviço (ANS) para cada uma das funções e para o sistema como um todo. Isso pode ser feito considerando as diversas dimensões do teste de desempenho: vazão, capacidade e tempo de resposta. Contudo, do ponto de vista do usuário, o principal componente é a velocidade de resposta. Desta forma, parece coerente definir um ANS para o tempo de resposta das funções críticas do sistema. |
Um estudo apresenta alguns indicadores com base na percepção humana considerando suas aspirações e limitações [http://www.nngroup.com/articles/website-response-times]. Os números apresentados no estudo não levam em consideração as características específicas de cada aplicação web, contudo, é importante levá-los em consideração especialmente porque refletem o sentimento do usuário, a sua percepção de qualidade do site que está sendo utilizado. | Um estudo apresenta alguns indicadores com base na percepção humana considerando suas aspirações e limitações [http://www.nngroup.com/articles/website-response-times]. Os números apresentados no estudo não levam em consideração as características específicas de cada aplicação web, contudo, é importante levá-los em consideração especialmente porque refletem o sentimento do usuário, a sua percepção de qualidade do site que está sendo utilizado. | ||
| Linha 16: | Linha 16: | ||
Com base neste estudo, há dois aspectos a serem considerados: a) não é razoável esperar que o tempo de resposta '''sempre''' esteja dentro dos valores definidos nos indicadores, ou seja, pode-se considerar aceitável que uma pequena parcela das requisições tenham tempo de resposta superior ao limite estabelecido; b) como já mencionado, deve-se levar em consideração as características da aplicação alvo do teste na definição dos indicadores. | Com base neste estudo, há dois aspectos a serem considerados: a) não é razoável esperar que o tempo de resposta '''sempre''' esteja dentro dos valores definidos nos indicadores, ou seja, pode-se considerar aceitável que uma pequena parcela das requisições tenham tempo de resposta superior ao limite estabelecido; b) como já mencionado, deve-se levar em consideração as características da aplicação alvo do teste na definição dos indicadores. | ||
| − | Com relação ao '' | + | Com relação ao '''item a''', é aceita uma definição chamada '''90 percentile response time''', que diz que 90% das requisições devem ter o tempo de resposta dentro dos parâmetros estabelecidos [http://www.quotium.com/performance/90-percentile-response-time/]. Outros estudos apontam que, para aplicações web, comumente é aceito o percentual de 95% para a definição dos ANS de tempo de resposta [https://perfwork.wordpress.com/2012/04/09/response-time-metric-for-sla/] [https://msdn.microsoft.com/en-us/library/ms404705.aspx]. |
| + | |||
| + | Com relação ao '''item b''', considerando válida a afirmação de que sistemas diferentes podem ter tempos de resposta diferentes, é comumente aceito que sistemas online, onde usuários fazem múltiplas tarefas simultaneamente, o tempo de resposta seja menor que 1 segundo em 90% das requisições [http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx]. | ||
| + | |||
| + | Outro complicador é a possibilidade de acesso ao sistema web a partir de dispositivos móveis. É sabido que nestes equipamentos o tempo de resposta para uma requisição pode ser consideravelmente maior, pois a comunicação ocorre na velocidade das redes móveis (WiFi, 2G, 3G, 4G, etc). Esta característica também deve ser levada em consideração no momento da definição dos indicadores. | ||
| + | |||
| + | Apesar de os números darem um ponto de partida e um norte para a definição de parâmetros aceitáveis para o PJe, parece temerário considerá-los de maneira absoluta no início da definição do processo de teste de desempenho. Entretanto, considerando que o PJe2 será executado sobre uma nova arquitetura com objetivo de melhorar, dentre outros aspectos, o desempenho geral da aplicação, é razoável considerar que '''cada funcionalidade do PJe 2 deve possuir tempo de resposta menor que a mesma funcionalidade no PJe1 em X% das requisições'''. Considerando válida esta abordagem, deve-se definir o valor ideal para X. Com base nestas considerações, é necessário definir o percentual de tempos de resposta dentro dos limites e quais são estes limites. | ||
| + | |||
| + | === '''Definição de metas''' === | ||
| + | Sendo definidos os indicadores necessários apresentados na seção anterior, devem ser definidas a meta de desempenho para cada função crítica e a meta de desempenho geral da aplicação. Por exemplo, pode ser uma meta do PJe2 que o tempo de resposta geral da aplicação deve ser 20% menor que tempo de resposta geral no PJe1 em 90% das requisições. | ||
| + | |||
| + | === '''Disponibilização de ambiente alvo para testes''' === | ||
| + | O ideal é que os testes de desempenho possam ser realizados em ambiente de produção sem interferir no correto funcionamento da aplicação. Contudo, sabe-se que esta abordagem é inviável. Tento isso em conta, é necessária a disponibilização de um ambiente que seja réplica do ambiente de produção para a realização dos testes. Esta similaridade estende-se a todas as características dos ambientes, tanto de hardware quando de software. | ||
| + | |||
| + | Além disso, é importante que estejam disponíveis diferentes bases de dados para a realização dos testes. É sabido que junções em tabelas com diferentes massas de dados podem resultar em tempos de processamento bastante discrepantes. Esta heterogeneidade de massas de dados permite a descoberta de gargalos relacionados às características das diferentes bases de dados. Por exemplo, poderiam estar disponíveis bases de dados de cada tipo de justiça, em cada grau de jurisdição, de diferentes tribunais. | ||
| + | |||
| + | === '''Disponibilização de ambiente de cliente''' === | ||
| + | Testes de desempenho em aplicações web consistem basicamente em criar um número grande de '''usuários virtuais''' que fazem requisições às páginas da aplicação. Ferramentas como o [http://jmeter.apache.org JMeter] permitem a criação de milhares de usuários que disparam requisições para diversas páginas de uma aplicação web [http://jmeter.apache.org/]. | ||
| + | |||
| + | Num cenário em que '''uma máquina''' dispara milhares de requisições para um site, é fácil concluir que esta máquina passará a ser o gargalo da comunicação, visto que provavelmente seus recursos computacionais (processador, memória e placa de rede) são inferiores aos recursos do servidor hospedeiro do site alvo. Além disso, as requisições dos milhares de usuários virtuais seguirão provavelmente o mesmo caminho para comunicação (navegador, sistema operacional, placa de rede, cabos de rede, ''hubs'', roteadores, ''firewalls'' e outros softwares de rede), não representando a heterogeneidade dos ambientes computacionais que ligam os equipamentos dos usuários ao servidor. | ||
| + | |||
| + | Por todas estas características, é necessário também a disponibilização de um ambiente (fisicamente distribuído, se possível) com o maior número possível de máquinas (físicas ou virtuais) que servirão como clientes para os testes de desempenho. Num cenário ideal, cada Tribunal possuiria um conjunto de clientes que sincronizadamente disparariam milhares de requisições para o servidor alvo dos testes. Este cenário representaria com mais precisão o que ocorre realmente em ambiente de produção. | ||
| + | |||
| + | === '''Definição da infraestrutura da aplicação''' === | ||
| + | Esta atividade é obrigatória mesmo sem a existência dos testes de desempenho. Entretanto, tendo-se o conhecimento da infraestrutura de servidor necessária para rodar a aplicação, é possível orientar melhor a definição dos indicadores e das metas de desempenho desejáveis. Esta definição pode acontecer da seguinte maneira: | ||
| + | |||
| + | # definir a quantidade de usuários simultâneos que o sistema deve suportar; | ||
| + | # criar uma infraestrutura mínima para atender a esta demanda; | ||
| + | # simular esta quantidade de usuários fazendo as requisições na infraestrutura criada; | ||
| + | # ajustar a infraestrutura de acordo com os resultados das requisições simuladas. | ||
| + | |||
| + | Idealmente esta simulação deve ser realizada em um ambiente de clientes virtuais distribuídos, como aquele especificado na [http://www.cnj.jus.br/wikipje/index.php/Testes_de_desempenho#Disponibiliza.C3.A7.C3.A3o_de_ambiente_de_cliente seção anterior], para representar com maior fidelidade a realidade que ocorre em ambiente de produção. | ||
== '''REFERÊNCIAS''' == | == '''REFERÊNCIAS''' == | ||
1. IEEE. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, 2014. Disponível em http://www.computer.org/web/swebok. | 1. IEEE. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, 2014. Disponível em http://www.computer.org/web/swebok. | ||
| − | 2. Teste de desempenho: Conceitos, Objetivos e Aplicação: | + | 2. Teste de desempenho: Conceitos, Objetivos e Aplicação: http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx |
| − | 3. Teste de desempenho: | + | 3. Teste de desempenho: http://www.testar.me/#!teste-de-performance/c1oeb |
4. Tempos de resposta em Websites: http://www.nngroup.com/articles/website-response-times | 4. Tempos de resposta em Websites: http://www.nngroup.com/articles/website-response-times | ||
| − | JMeter: http://jmeter.apache.org | + | 5. Performance & Load Testing: http://www.quotium.com/performance/90-percentile-response-time/ |
| + | |||
| + | 6. Response time metric for SLA: https://perfwork.wordpress.com/2012/04/09/response-time-metric-for-sla/ | ||
| + | |||
| + | 7. Run performance tests on your app: https://msdn.microsoft.com/en-us/library/ms404705.aspx | ||
| + | |||
| + | 8. Teste de desempenho: Conceitos, Objetivos e Aplicação: http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx | ||
| + | |||
| + | 9. JMeter: http://jmeter.apache.org | ||
| − | + | [[Category:PJe2]] | |
Edição atual tal como às 14h32min de 21 de janeiro de 2016
Conteúdo |
[editar] INTRODUÇÃO
Testes de desempenho têm a função de verificar se o sistema alvo atende aos requisitos de desempenhos especificados. Além disso, permitem avaliar características não funcionais do sistema relacionadas, como capacidade, vazão e tempo de resposta [1]. Contudo, o objetivo do teste de desempenho é o mesmo de qualquer outro teste, que é o mesmo da própria disciplina de Engenharia de Software: entregar produto de qualidade. E qualidade, do ponto de vista do usuário, além dos aspectos funcionais, certamente inclui a velocidade de resposta para as operações realizadas no sistema. Apesar disso, testes de desempenho frequentemente deixam de ser realizados, fadando inclusive sistemas bug free ao fracasso pela baixa percepção de qualidade por parte dos usuários.
[editar] PREMISSAS
Executar testes de desempenho é uma atividade complexa e, por consequência, bastante onerosa ao processo de desenvolvimento. Contudo, são inúmeras as vantagens colhidas de testes bem executados [2] [3]. Esta complexidade está relacionada principalmente às atividades necessárias antes da execução propriamente dita dos testes de desempenho. Este capítulo descreve algumas destas atividades e como elas contribuem para o sucesso do processo de teste.
[editar] Funções testadas
Sabe-se que testar é uma atividade estatística. Raramente é possível testar um sistema de grande porte em sua totalidade, por conta da quantidade de combinações possíveis para todas as funções existentes: testes infinitos têm custos também infinitos. Neste cenário, é preciso encontrar um ponto de equilíbrio em que se teste o máximo possível usando a menor quantidade possível de recursos. Para isso é necessário definir quais funções são críticas e devem ser alvo dos testes de desempenho. Isso porque provavelmente nem todas as funções são críticas em relação ao desempenho. Por exemplo, no PJe, os CRUDs de tabelas básicas provavelmente não possuem restrição forte com relação ao tempo de resposta. Já a consulta processual é um caso que provavelmente possui este requisito. Logo, é necessário definir quais funções serão alvo dos testes de desempenho.
[editar] Definição de indicadores
Como apresentado na introdução deste documento, testes de desempenho têm a função de verificar se o sistema alvo atende aos requisitos de desempenho especificados. Para tanto, é necessário definir estes requisitos. É preciso definir, para cada função eleita, consideradas suas características, qual o requisito de desempenho esperado. Esse requisito é uma definição de Acordo de Nível de Serviço (ANS) para cada uma das funções e para o sistema como um todo. Isso pode ser feito considerando as diversas dimensões do teste de desempenho: vazão, capacidade e tempo de resposta. Contudo, do ponto de vista do usuário, o principal componente é a velocidade de resposta. Desta forma, parece coerente definir um ANS para o tempo de resposta das funções críticas do sistema.
Um estudo apresenta alguns indicadores com base na percepção humana considerando suas aspirações e limitações [4]. Os números apresentados no estudo não levam em consideração as características específicas de cada aplicação web, contudo, é importante levá-los em consideração especialmente porque refletem o sentimento do usuário, a sua percepção de qualidade do site que está sendo utilizado.
Com base neste estudo, há dois aspectos a serem considerados: a) não é razoável esperar que o tempo de resposta sempre esteja dentro dos valores definidos nos indicadores, ou seja, pode-se considerar aceitável que uma pequena parcela das requisições tenham tempo de resposta superior ao limite estabelecido; b) como já mencionado, deve-se levar em consideração as características da aplicação alvo do teste na definição dos indicadores.
Com relação ao item a, é aceita uma definição chamada 90 percentile response time, que diz que 90% das requisições devem ter o tempo de resposta dentro dos parâmetros estabelecidos [5]. Outros estudos apontam que, para aplicações web, comumente é aceito o percentual de 95% para a definição dos ANS de tempo de resposta [6] [7].
Com relação ao item b, considerando válida a afirmação de que sistemas diferentes podem ter tempos de resposta diferentes, é comumente aceito que sistemas online, onde usuários fazem múltiplas tarefas simultaneamente, o tempo de resposta seja menor que 1 segundo em 90% das requisições [8].
Outro complicador é a possibilidade de acesso ao sistema web a partir de dispositivos móveis. É sabido que nestes equipamentos o tempo de resposta para uma requisição pode ser consideravelmente maior, pois a comunicação ocorre na velocidade das redes móveis (WiFi, 2G, 3G, 4G, etc). Esta característica também deve ser levada em consideração no momento da definição dos indicadores.
Apesar de os números darem um ponto de partida e um norte para a definição de parâmetros aceitáveis para o PJe, parece temerário considerá-los de maneira absoluta no início da definição do processo de teste de desempenho. Entretanto, considerando que o PJe2 será executado sobre uma nova arquitetura com objetivo de melhorar, dentre outros aspectos, o desempenho geral da aplicação, é razoável considerar que cada funcionalidade do PJe 2 deve possuir tempo de resposta menor que a mesma funcionalidade no PJe1 em X% das requisições. Considerando válida esta abordagem, deve-se definir o valor ideal para X. Com base nestas considerações, é necessário definir o percentual de tempos de resposta dentro dos limites e quais são estes limites.
[editar] Definição de metas
Sendo definidos os indicadores necessários apresentados na seção anterior, devem ser definidas a meta de desempenho para cada função crítica e a meta de desempenho geral da aplicação. Por exemplo, pode ser uma meta do PJe2 que o tempo de resposta geral da aplicação deve ser 20% menor que tempo de resposta geral no PJe1 em 90% das requisições.
[editar] Disponibilização de ambiente alvo para testes
O ideal é que os testes de desempenho possam ser realizados em ambiente de produção sem interferir no correto funcionamento da aplicação. Contudo, sabe-se que esta abordagem é inviável. Tento isso em conta, é necessária a disponibilização de um ambiente que seja réplica do ambiente de produção para a realização dos testes. Esta similaridade estende-se a todas as características dos ambientes, tanto de hardware quando de software.
Além disso, é importante que estejam disponíveis diferentes bases de dados para a realização dos testes. É sabido que junções em tabelas com diferentes massas de dados podem resultar em tempos de processamento bastante discrepantes. Esta heterogeneidade de massas de dados permite a descoberta de gargalos relacionados às características das diferentes bases de dados. Por exemplo, poderiam estar disponíveis bases de dados de cada tipo de justiça, em cada grau de jurisdição, de diferentes tribunais.
[editar] Disponibilização de ambiente de cliente
Testes de desempenho em aplicações web consistem basicamente em criar um número grande de usuários virtuais que fazem requisições às páginas da aplicação. Ferramentas como o JMeter permitem a criação de milhares de usuários que disparam requisições para diversas páginas de uma aplicação web [9].
Num cenário em que uma máquina dispara milhares de requisições para um site, é fácil concluir que esta máquina passará a ser o gargalo da comunicação, visto que provavelmente seus recursos computacionais (processador, memória e placa de rede) são inferiores aos recursos do servidor hospedeiro do site alvo. Além disso, as requisições dos milhares de usuários virtuais seguirão provavelmente o mesmo caminho para comunicação (navegador, sistema operacional, placa de rede, cabos de rede, hubs, roteadores, firewalls e outros softwares de rede), não representando a heterogeneidade dos ambientes computacionais que ligam os equipamentos dos usuários ao servidor.
Por todas estas características, é necessário também a disponibilização de um ambiente (fisicamente distribuído, se possível) com o maior número possível de máquinas (físicas ou virtuais) que servirão como clientes para os testes de desempenho. Num cenário ideal, cada Tribunal possuiria um conjunto de clientes que sincronizadamente disparariam milhares de requisições para o servidor alvo dos testes. Este cenário representaria com mais precisão o que ocorre realmente em ambiente de produção.
[editar] Definição da infraestrutura da aplicação
Esta atividade é obrigatória mesmo sem a existência dos testes de desempenho. Entretanto, tendo-se o conhecimento da infraestrutura de servidor necessária para rodar a aplicação, é possível orientar melhor a definição dos indicadores e das metas de desempenho desejáveis. Esta definição pode acontecer da seguinte maneira:
- definir a quantidade de usuários simultâneos que o sistema deve suportar;
- criar uma infraestrutura mínima para atender a esta demanda;
- simular esta quantidade de usuários fazendo as requisições na infraestrutura criada;
- ajustar a infraestrutura de acordo com os resultados das requisições simuladas.
Idealmente esta simulação deve ser realizada em um ambiente de clientes virtuais distribuídos, como aquele especificado na seção anterior, para representar com maior fidelidade a realidade que ocorre em ambiente de produção.
[editar] REFERÊNCIAS
1. IEEE. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, 2014. Disponível em http://www.computer.org/web/swebok.
2. Teste de desempenho: Conceitos, Objetivos e Aplicação: http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx
3. Teste de desempenho: http://www.testar.me/#!teste-de-performance/c1oeb
4. Tempos de resposta em Websites: http://www.nngroup.com/articles/website-response-times
5. Performance & Load Testing: http://www.quotium.com/performance/90-percentile-response-time/
6. Response time metric for SLA: https://perfwork.wordpress.com/2012/04/09/response-time-metric-for-sla/
7. Run performance tests on your app: https://msdn.microsoft.com/en-us/library/ms404705.aspx
8. Teste de desempenho: Conceitos, Objetivos e Aplicação: http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx
9. JMeter: http://jmeter.apache.org
