Você está na página 1de 13

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Um artigo tcnico da Oracle Junho de 2009

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

INTRODUO

Voc est pronto para dar incio a uma aplicao Web crtica. Garantir o bom desempenho da aplicao fundamental, mas o tempo curto. Como voc pode testar a aplicao da melhor forma e ainda atender os prazos?
A Identificao rpida de gargalos (RBI) combina um entendimento abrangente de gargalos com uma metodologia refinada de testes de carga que permitem que as organizaes criem aplicaes Web altamente redimensionveis.

A Identificao rpida de gargalos (RBI) uma nova metodologia de testes que permite que os profissionais de controle de qualidade (QA) descubram rapidamente as limitaes de desempenho da aplicao Web e determinem o impacto dessas limitaes na experincia do usurio final. Desenvolvida durante anos de envolvimento com testes em todos os tipos de plataformas, a metodologia RBI reduz drasticamente os ciclos de testes de carga ao mesmo tempo em que possibilita uma quantidade maior de testes (e testes mais minuciosos). Atravs dessa abordagem, as organizaes podem aumentar a qualidade das aplicaes, melhorar a experincia do usurio e reduzir o custo de implantao de novos sistemas.
DEFINIO DE TESTES DE DESEMPENHO

Os testes de desempenho podem ser grosseiramente definidos como testes realizados para avaliar a conformidade de um sistema ou componente com requisitos especficos de desempenho. Entretanto, todas as aplicaes tm pelo menos um gargalo e poucos sistemas (caso haja algum) atendem aos requisitos iniciais de desempenho. Para ilustrar essa realidade, vamos redefinir os testes de desempenho como testes realizados para isolar e identificar os problemas do sistema e da aplicao (gargalos) que impediro que a aplicao seja redimensionada para atender seus requisitos de desempenho. Essa mudana filosfica no ponto de vista (de testes como uma avaliao para testes como uma investigao ativa para isolar e resolver problemas) o que direcionou a criao da metodologia RBI. A RBI combina um entendimento abrangente de gargalos com uma metodologia refinada de testes que permite que as organizaes criem aplicaes Web altamente redimensionveis.

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 2

ENTENDENDO OS GARGALOS, O THROUGHPUT E A SIMULTANEIDADE

Antes de se aprofundar nos detalhes da metodologia RBI, precisamos estabelecer um entendimento comum sobre os gargalos (e onde eles so encontrados), bem como fazer uma distino entre teste de throughput e teste de simultaneidade.
Gargalos Principais inibidores de desempenho

Qualquer recurso do sistema, como hardware, software ou largura de banda, que estipule limites definidos no fluxo de dados ou na velocidade de processamento cria um gargalo. Em aplicaes Web, os gargalos afetam diretamente o desempenho e a escalabilidade limitando a quantidade de throughput de dados ou restringindo o nmero de conexes da aplicao. Esses problemas ocorrem em todos os nveis da arquitetura do sistema, incluindo a camada de rede, o servidor Web, o servidor de aplicaes e o servidor de banco de dados. Historicamente, com base em nossa experincia de testes em aplicaes reais de clientes, os gargalos aparecem distribudos por esses componentes conforme mostrado na Figura 1.

Em aplicaes Web, os gargalos afetam diretamente o desempenho e a escalabilidade limitando a quantidade de throughput de dados ou restringindo o nmero de conexes da aplicao.

Figura 1. Distribuio estimada de gargalos pela infraestrutura do sistema.

O impacto composto da complexidade dos testes

A abordagem de testes que voc escolhe influencia diretamente a dificuldade de isolar e resolver os gargalos. Infelizmente, muitos procedimentos de testes comeam com cenrios complexos de utilizao onde os testadores tentam simular exatamente como a aplicao ser utilizada na produo. Isso pode envolver a execuo de diversas transaes diferentes para simular os diferentes tipos de usurios que interagem com a aplicao de diversas formas. Infelizmente, isso cria uma barreira de testes significativa, pois os cenrios mais complexos e que envolvem diversas transaes diferentes inserem mais gargalos no teste, o que dificulta a identificao das causas principais. Por exemplo, o grfico na Figura 2 ilustra os resultados de teste de uma aplicao de e-commerce padro que apresentou um gargalo com aproximadamente 2.000 usurios simultneos. Neste exemplo de teste, os cenrios de utilizao envolvem

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 3

navegao, pesquisa e adio de itens em um carrinho de compras para concluir uma compra. Embora houvesse somente trs transaes sendo testadas, cada transao interagiu com todos os nveis da arquitetura da aplicao, e qualquer uma delas poderia ter causado o gargalo. Para complicar ainda mais, o gargalo tambm poderia ter sido causado por um problema no sistema. No final das contas, quanto mais variveis esto envolvidas em um teste, mais difcil determinar a causa do problema.

Figura 2: Resultados grficos do teste de uma aplicao de e-commerce.

Se o problema pode estar em qualquer camada da arquitetura e a probabilidade de estar em uma determinada camada no significativamente maior que a probabilidade de estar em outra, onde mais voc pode procurar orientao?
Dois problemas principais: Throughput e Simultaneidade
A maior parte de todos os problemas de desempenho de sistemas e aplicaes resultado de limitaes no throughput.

O throughput a quantidade de fluxo de dados que um sistema pode suportar, medido em acessos por segundo, pginas por segundo e megabits de dados por segundo. A simultaneidade o nmero de usurios independentes conectados simultaneamente e usando uma aplicao. Pela nossa experincia, a maior parte de todos os problemas de desempenho de sistemas e aplicaes resultado de limitaes no throughput. Entretanto, problemas de simultaneidade tambm so crticos para o desempenho de uma aplicao e podem ser at mais difceis de isolar.
Testes de throughput

Os testes de throughput envolvem a reduo at o mnimo de conexes de usurios de um sistema e o aumento at o mximo da quantidade de trabalho sendo realizado por esses usurios. Isso empurra o sistema e a aplicao em termos de capacidade para que todos os problemas sejam revelados.

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 4

Para testes de throughput no nvel do sistema, arquivos bsicos podem ser adicionados aos servidores Web e de aplicaes para a realizao dos testes. O teste de carga pode ento ser configurado para solicitar que esses arquivos de teste avaliem o throughput mximo do sistema em cada camada. Normalmente, os testadores usam um arquivo grande de imagem para testes de largura de banda, um arquivo pequeno de texto ou imagem para testes de taxa de acessos e uma pgina extremamente simples da aplicao (uma pgina Hello World, por exemplo) para testar a taxa de pginas. Se o sistema no atender aos requisitos bsicos de desempenho da aplicao (apenas solicitando essas pginas simples) os testes devem ser interrompidos at que o sistema em si tenha sido melhorado, seja atravs do ajuste das configuraes, o aumento da capacidade de hardware ou o aumento da largura de banda alocada. Os testes de throughput da aplicao real envolvem o acesso a pginas chave e transaes de usurios na aplicao propriamente dita com tempo de atraso limitado entre as solicitaes para encontrar o limite da capacidade de "pginas por segundo" de vrios componentes funcionais. Obviamente, as pginas ou transaes com o pior throughput de pgina precisam de mais ajustes.

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 5

Testes de simultaneidade

Nos nveis do sistema e da aplicao, a simultaneidade limitada por sesses e conexes de soquete. As falhas de cdigo e configuraes incorretas do servidor podem tambm limitar a simultaneidade. Os testes de simultaneidade envolvem o aumento do nmero de usurios no sistema e a utilizao de tempos de atraso de pginas realistas com um aumento de velocidade lento o suficiente para reunir dados teis durante todo o teste em cada nvel de carga. Assim como com os testes de throughput, importante testar as pginas chave e transaes de usurios na aplicao que est sendo testada.
A diferena entre os testes de throughput e de simultaneidade

Embora a maioria dos gargalos seja encontrada nos testes de throughput, para testar uma aplicao de forma adequada, voc deve testar o throughput e a simultaneidade.

A carga gerada por um teste de carga de 100 usurios virtuais com tempos de raciocnio de 1 segundo no equivalente carga gerada por um teste de carga de 1.000 usurios virtuais com tempos de raciocnio de 10 segundos. Conforme mostrado na Figura 3, os dois testes so idnticos em termos de throughput; entretanto, em termos de simultaneidade, eles so muito diferentes.
Cenrio
100 usurios 1 segundo/pgina

Throughput
Pginas/segundo = (100VU x 1 pgina/VU) 1 segundo = 100

Simultaneidade

Ponto de gargalo
50 Pginas/ segundo 25 Pginas/ segundo

100 Conexes

1.000 usurios 10 segundos/ pgina

Pginas/segundo = (1.000VU x 1 pgina/VU) 10 segundos = 100

1.000 Conexes

Figura 3. Teste de carga de 100 usurios virtuais versus teste de carga de 1.000 usurios virtuais.

No primeiro cenrio, o teste de throughput, a aplicao apresentou um gargalo a uma taxa de 50 pginas por segundo. Entretanto, no segundo cenrio, um teste de simultaneidade das mesmas transaes, a aplicao apresentou um gargalo a uma taxa de 25 pginas por segundo. As nicas diferenas entre esses dois testes foram o nmero de usurios no sistema e o perodo de tempo que esses usurios permaneceram nas pginas. No teste de throughput com menos usurios e menores tempos de atraso de visualizao de pginas, a aplicao apresentou mais capacidade de throughput; o segundo teste mostra que a aplicao estava limitada por sua simultaneidade. Se os testadores tivessem verificado somente o throughput, o problema de simultaneidade no teria sido detectado at que a aplicao estivesse em produo. As figuras 4 e 5 na pgina seguinte mostram os resultados de cada teste e destacam a importncia de testar tanto o throughput como a simultaneidade.

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 6

As nicas diferenas entre esses dois testes foram o nmero de usurios no sistema e o perodo de tempo que esses usurios permaneceram nas pginas. Figura 4. Testes de throughput de 100 usurios com visualizaes de pgina de 1 segundo mostram um gargalo a uma taxa de 50 pginas por segundo.

Figura 5. Testes de simultaneidade de 1.000 usurios com visualizaes de pgina de 10 segundos mostram um gargalo a uma taxa de 25 pginas por segundo.

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 7

A ABORDAGEM RBI DE PROCESSAMENTO DE TESTES

Tradicionalmente, os testadores de desempenho se concentravam no nmero de usurios simultneos, considerando-o a principal mtrica para a escalabilidade da aplicao. Entretanto, se a maioria dos problemas no nvel do sistema e da aplicao encontrada em testes de throughput, uma nova abordagem necessria. Esses trs princpios formam a base da metodologia RBI.

Todas as aplicaes Web tm gargalos. Esses gargalos somente podem ser detectados um por vez. necessrio se concentrar nos gargalos com maior probabilidade de ocorrncia.

Embora reconhea a importncia dos testes de simultaneidade, a metodologia RBI se concentra primeiro nos testes de throughput para eliminar pela raiz os gargalos mais comuns e, em seguida, realiza os testes de simultaneidade sob condies de carga que reflitam o nmero real de usurios esperados na aplicao. O processamento de testes de RBI tambm comea com testes simples e ento aumenta a complexidade de forma que, quando um problema aparecer, todas as outras possveis causas tenham sido descartadas. Concentrar-se nos testes de throughput e, em seguida, nos testes de simultaneidade usando uma abordagem estruturada para o processo de testes garante que os gargalos sejam isolados rapidamente, o que aumenta a eficincia e reduz os custos.
Benefcios do processamento de testes de RBI

A metodologia RBI permite a realizao rpida, (e ainda assim completa) de testes, que descobre sistematicamente todos os problemas do sistema e da aplicao, sejam eles simples ou complexos.
Tempo de testes reduzido

Quanto tempo voc pode economizar se concentrando inicialmente em testes de throughput? Considere um exemplo de um sistema com expectativa de lidar com 5.000 usurios simultneos, com os usurios gastando uma mdia de 45 segundos em cada pgina. Se a aplicao tem um gargalo que ir limitar sua escalabilidade para 25 pginas por segundo, um teste de simultaneidade ir encontrar esse gargalo em aproximadamente 1.125 usurios (25 pginas por segundo a 45 segundos por pgina).

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 8

Ao descobrir os gargalos atravs de uma abordagem em camadas, voc pode rapidamente identificar problemas e isolar problemas em componentes sobre os quais voc no possui muito conhecimento.

No intuito de no influenciar os dados, o aumento de intensidade de um teste de simultaneidade tpico deve ocorrer lentamente. Por exemplo, voc pode pensar em aumentar um usurio a cada cinco segundos. Neste exemplo, o gargalo teria ocorrido em 5.625 segundos ou 94 minutos de teste (1.125 usurios, com um usurio sendo adicionado a cada 5 segundos). Entretanto, para validar o gargalo, o teste deveria continuar alm deste ponto para comprovar que o throughput no estava aumentando conforme os usurios eram adicionados. Um teste de throughput teria encontrado esse problema em menos de 60 segundos.
Eliminar a complexidade inicial dos testes

Com frequncia, os testes de desempenho comeam com cenrios extremamente complexos operando muitos componentes ao mesmo tempo, tornando mais fcil para que os gargalos no apaream. A metodologia RBI comea com testes no nvel do sistema que podem ser realizados antes mesmo que a aplicao tenha sido implantada.
Melhorar a eficincia do controle de qualidade

A metodologia RBI realiza os testcases mais simples primeiro e, em seguida, avana para aqueles mais complexos. Se os testcases mais simples funcionam e o prximo nvel de complexidade falha, o gargalo est relacionado complexidade que acabou de ser adicionada. Ao descobrir os gargalos atravs de uma abordagem em camadas, voc pode rapidamente identificar problemas e isolar problemas em componentes sobre os quais voc no possui muito conhecimento.
Eficincia aprimorada de testes com agregao de conhecimento

A natureza modular e iterativa da metodologia significa que quando um gargalo aparece, todos os componentes testados anteriormente j foram descartados. Por exemplo, se acessar a pgina inicial no mostra gargalos, mas acessar a pgina inicial e executar uma pesquisa mostra um desempenho muito ruim, a causa do gargalo est relacionada funcionalidade de pesquisa.
Processamento de testes de RBI para os gargalos mais comuns do sistema

Todos os testes de desempenho devem comear com uma avaliao da infraestrutura de rede bsica que suporta a aplicao. Se esse sistema bsico no consegue suportar a carga de usurios antecipada em um sistema, mesmo um cdigo de aplicao infinitamente escalvel apresentar gargalos. Os testes no nvel de sistema bsico devem ser executados para validar a largura de banda, a taxa de acessos e as conexes. Alm disso, pginas simples de teste da aplicao devem ser utilizadas (pginas hello world simples, por exemplo).

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 9

A aplicao

Aps validar a infraestrutura do sistema e descobrir que ela atende s necessidades mais bsicas dos usurios, volte-se para a aplicao propriamente dita. Mais uma vez, comece com os testcases mais simples possveis. Se os testes prosseguiram at agora sem descobrir problemas no nvel do sistema (ou se esses problemas j foram resolvidos), todos os problemas restantes sero causados pela prpria aplicao. Por exemplo, se uma pgina de teste da aplicao conseguiu uma taxa de 100 pginas por segundo e a pgina inicial apresenta gargalos a uma taxa de apenas 10 pginas por segundo, o problema est relacionado sobrecarga necessria para exibir a pgina inicial. Neste ponto, a pgina de teste da aplicao fornece duas informaes valiosas. Primeiro, como sabemos que o sistema em si no o gargalo, o culpado s pode ser o cdigo na pgina inicial. Segundo, podemos ver o quanto seria possvel melhorar o desempenho atravs do ajuste da pgina inicial. A diferena entre os desempenhos da pgina de teste da aplicao (100 pginas por segundo) e da pgina inicial (10 pginas por segundo) determina a mxima melhoria de desempenho que o ajuste poderia fornecer. Da mesma forma, as transaes com mltiplas pginas podem ser avaliadas ao separar o desempenho de cada pgina na transao individualmente e avaliar o quanto cada uma contribui para o desempenho da transao como um todo. Como qualquer pgina da aplicao no mundo real provavelmente exige mais capacidade de processamento que uma pgina de teste hello world, razovel esperar uma pequena queda no desempenho. Entretanto, quanto maior essa queda, maior a necessidade (e o ganho potencial) de ajuste. tambm importante observar que se a queda de desempenho entre a pgina de teste e uma pgina real da aplicao no for significativa e o desempenho ainda for insuficiente para atender s necessidades da base de usurios, ser necessrio adicionar mais recursos de hardware. At agora, os tempos de resposta das pginas no foram mencionados. Embora os tempos de resposta sejam uma das principais mtricas do desempenho geral, eles sero os mesmos para 1.000 ou 100.000 usurios a menos que um gargalo seja encontrado. Portanto, nesta metodologia, os tempos de resposta so somente teis como um indicador de que um gargalo foi obtido (caso eles comecem a apresentar picos) ou como um critrio de falha (caso eles comecem a exceder um limite predefinido), com pginas com baixo desempenho (aquelas com erros ou altos tempos de resposta) em sua maioria necessitando de otimizao no cdigo.
Processamento de testes de RBI para os gargalos da aplicao

A diferena entre o desempenho de uma pgina de teste e o desempenho de uma pgina real da aplicao de produo determina o ganho potencial de melhoria no desempenho obtido atravs do ajuste.

Assim como com o teste no nvel do sistema, a metodologia RBI comea com os testcases mais simples possveis e, em seguida, avana em complexidade. Em uma aplicao de e-commerce tpica, voc testaria a pgina principal primeiro e, em seguida, adicionaria pginas e funes de negcios at que transaes completas do mundo real estivessem sendo testadas, primeiro individualmente e depois em

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 10

padres de utilizao com cenrios complexos. Conforme as etapas so adicionadas, quaisquer degradaes nos tempos de resposta ou throughput das pginas ter sido causada pela etapa que acabou de ser adicionada, tornando mais fcil isolar o cdigo que precisa ser investigado. Uma vez que cada uma das funes de negcios e transaes tenha sido testada e otimizada (conforme necessrio), as transaes podem ser combinadas em testes de simultaneidade com cenrios completos. Esses testes de simultaneidade devem se concentrar em dois componentes principais. Primeiro, o teste de simultaneidade deve refletir com preciso o que os usurios reais fazem no site: navegar, pesquisar, registrar, efetuar login e comprar. Segundo, as etapas nessas transaes devem ser realizadas no mesmo ritmo que os visitantes do mundo real com tempos de raciocnio adequados entre cada etapa. Esses dados podem ser reunidos atravs de uma ferramenta de log da Web que mostra a durao da sesso, as pginas visualizadas por sesso (para determinar o ritmo do usurio) e a porcentagem de acesso s pginas (para determinar as funes de negcios reais usadas). Desde que o teste tenha sido projetado com base em dados reais (ou hipteses bem informadas, no caso de uma aplicao ainda no implantada), ele deve ser executado de forma a reunir informaes importantes sobre diversos nveis de carga de usurios. Caso seja esperado que o site lide com 1.000 usurios simultneos, importante no iniciar todos esses usurios ao mesmo tempo. Em vez disso, aumente a intensidade do seu teste lentamente, adicionando um ou mais usurios em intervalos de tempo predefinidos, at atingir 1.000 usurios. Isso permitir a voc determinar o desempenho geral em cada nvel de carga de usurio e tambm tornar mais fcil identificar problemas de desempenho quando eles comearem a ocorrer.
CONCLUSO

Os cenrios adequados de testes de simultaneidade devem refletir com preciso o que os usurios reais fazem no site e replicar essas aes no mesmo ritmo dos usurios.

A metodologia RBI para o processamento de testes de carga melhora a eficincia do teste ao se concentrar primeiro onde os gargalos normalmente ocorrem, ou seja, no throughput. Uma vez que o throughput tenha sido testado por completo, possvel testar a simultaneidade do sistema e da aplicao para avaliar o desempenho sob cargas de usurio realistas. Ao seguir uma abordagem estruturada (do teste do sistema ao teste da aplicao) e adicionar complexidade lenta e sistematicamente aos testcases, voc poder rapidamente isolar os gargalos e sua causa principal associada. Embora a inteno principal deste artigo seja descrever a metodologia, importante ressaltar que boa parte desse processo pode e deve ser automatizada atravs de uma ferramenta de testes automatizada. O Oracle Application Testing Suite o componente principal do Oracle Enterprise Manager no que diz respeito a testes funcionais e de carga para aplicaes de arquitetura Web e orientada a servios.

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 11

ENTRE EM CONTATO CONOSCO


Para obter mais informaes sobre o Oracle Application Testing Suite e o Oracle Enterprise Manager acesse oracle.com/global/br/enterprise_manager ou ligue para 0800-891-4433 para falar com um representante da Oracle. Alm disso, visite a Oracle Technology Network em oracle.com/technology/products/oem/

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga

Pgina 12

Identificao rpida de gargalos Uma forma mais eficiente de realizar testes de carga Junho de 2009 Oracle do Brasil Sistemas Ltda. Sede no Brasil Av. Alfredo Egydio de Souza Aranha, 100 So Paulo, SP Brasil

CNPJ: 59.456.277/0001-76 Fone: 0-800-891-44-33 oracle.com Copyright 2007, 2009, Oracle e/ou suas afiliadas. Todos os direitos reservados. Este documento fornecido apenas para fins informativos e seu contedo est sujeito a alteraes sem aviso prvio. No h garantias de que este documento esteja isento de erros nem que esteja sujeito a outras garantias ou condies legais, expressas ou implcitas, incluindo garantias ou condies de comercializao e uso para um propsito especfico. A Oracle isenta-se de qualquer responsabilidade em relao a este documento, sendo que ele no representa qualquer obrigao contratual direta ou indireta. Este documento no pode ser reproduzido ou transmitido de qualquer forma ou atravs de qualquer meio, seja eletrnico ou mecnico, para qualquer objetivo, sem a permisso expressa, por escrito, da Oracle. Oracle uma marca comercial registrada da Oracle Corporation e/ou de suas empresas afiliadas. Outros nomes podem ser marcas comerciais de seus respectivos proprietrios. 0408