17. Ajuda! Meu chefe quer que eu teste a carga do nosso aplicativo! ¶

Esta é uma proposta bastante aberta. Há uma série de perguntas a serem feitas primeiro e, além disso, vários recursos que serão necessários. Você precisará de algum hardware para executar os benchmarks/testes de carga. Várias ferramentas serão úteis. Há uma série de produtos a considerar. E, finalmente, por que Java é uma boa escolha para implementar um produto de teste de carga/Benchmarking.

17.1 Perguntas a fazer ¶

Qual é o nosso número médio previsto de usuários (carga normal)?

Qual é o nosso número de pico previsto de usuários?

Quando é um bom momento para testar a carga de nosso aplicativo (ou seja, fora do expediente ou fins de semana), tendo em mente que isso pode muito bem travar um ou mais de nossos servidores?

Nosso aplicativo tem estado? Em caso afirmativo, como nosso aplicativo o gerencia (cookies, reescrita de sessão ou algum outro método)?

O que o teste pretende alcançar?

17.2 Recursos ¶

Os recursos a seguir serão muito úteis. Tenha em mente que se você não conseguir localizar esses recursos, você se tornará esses recursos. Como você já tem seu trabalho preparado, vale a pena saber quem são as seguintes pessoas, para que você possa pedir ajuda se precisar.

17.2.1 Rede ¶

Quem conhece nossa topologia de rede? Se você encontrar algum problema de firewall ou proxy, isso se tornará muito importante. Além disso, uma rede de teste privada (que terá, portanto, latência de rede muito baixa) seria uma coisa muito boa. Saber quem pode configurar um para você (se você achar que isso é necessário) será muito útil. Se o aplicativo não for dimensionado conforme o esperado, quem pode adicionar hardware adicional?

17.2.2 Aplicação ¶

Quem sabe como funciona nosso aplicativo? A sequência normal é

test (baixo volume - podemos comparar nosso aplicativo?)
benchmark (o número médio de usuários)
load-test (o número máximo de usuários)
testar destrutivamente (qual é o nosso limite rígido?)

O processo de teste pode progredir de teste de caixa preta para teste de caixa branca (a diferença é que o primeiro não requer conhecimento do aplicativo [é tratado como uma "caixa preta"] enquanto o segundo requer algum conhecimento do aplicativo). Não é incomum descobrir problemas com o aplicativo durante esse processo, portanto, esteja preparado para defender seu trabalho.

17.3 Qual plataforma devo usar para executar os benchmarks/testes de carga? ¶

Esta deve ser uma peça de hardware amplamente utilizada, com uma instalação de software padrão (ou seja, vanilla). Lembre-se, se você publicar seus resultados, a primeira coisa que seus clientes farão é contratar um estudante de pós-graduação para verificá-los. Você também pode tornar isso o mais fácil possível para essa pessoa.

Para Windows, o Windows XP Professional deve ser no mínimo (os outros não são multi-thread além de 50-60 conexões, e você provavelmente prevê mais usuários do que isso).

Boas plataformas gratuitas incluem os linuxes, os BSDs e Solaris Intel. Se você tem um pouco mais de dinheiro, existem linux comerciais. Isso pode valer a pena se você precisar de suporte.

Para plataformas não Windows, investigue " ulimit -n Unlimited " para incluí-lo nos scripts de inicialização de sua conta de usuário (scripts .bashrc ou .cshrc para a conta de teste).

Observe também que algumas edições do Linux/Unix são destinadas ao uso do servidor. Estes geralmente têm suporte de GUI mínimo ou nenhum. Esses sistemas operacionais devem funcionar bem para executar o JMeter no modo CLI, mas o modo GUI do JMeter provavelmente não funcionará a menos que você instale um ambiente GUI mínimo.

À medida que você avança para benchmarks/testes de carga em maior escala, essa plataforma se tornará o fator limitante. Então vale a pena usar o melhor hardware e software que você tem disponível. Lembre-se de incluir a configuração de hardware/software em seus benchmarks publicados.

Quando você precisa de muitas máquinas ou quer testar a latência da rede, o Cloud pode te ajudar. O JMeter pode ser facilmente instalado em instâncias de nuvem, pois é executado em praticamente qualquer arquitetura disponível na nuvem. O JMeter também é suportado no Commercial Cloud PAAS se você não quiser gerenciá-lo sozinho.

Não se esqueça do modo de lote JMeter (CLI). Este modo deve ser usado durante o teste de carga por vários motivos:

Se você tem um servidor poderoso que suporta Java, mas talvez não tenha uma implementação gráfica rápida, ou onde você precise fazer login remotamente.
O modo de lote (CLI) pode reduzir o tráfego de rede em comparação com o uso de um monitor remoto ou modo cliente-servidor.
Java AWT Thread usado para o modo GUI pode alterar o comportamento de injeção bloqueando às vezes

O arquivo de log em lote pode ser carregado no JMeter em uma estação de trabalho para análise, ou você pode usar a saída CSV e importar os dados para uma planilha.

Lembre-se de que o modo GUI é para criação e depuração de scripts, não para teste de carga

17.4 Ferramentas ¶

As ferramentas a seguir serão todas úteis. Com certeza vale a pena conhecê-los. Isso deve incluir experimentá-los e ler a documentação apropriada (páginas de manual, arquivos de informações, mensagens de ajuda do aplicativo e qualquer documentação fornecida).

17.4.1 ping ¶

Isso pode ser usado para estabelecer se você pode ou não alcançar seu site de destino. As opções podem ser especificadas para que ' ping ' forneça o mesmo tipo de relatório de rota que ' traceroute '.

17.4.2 nslookup/dig ¶

Embora o usuário normalmente use um endereço de Internet legível por humanos, convém evitar a sobrecarga de pesquisas de DNS ao realizar benchmarking/teste de carga. Eles podem ser usados para determinar o endereço exclusivo (quadrado pontilhado) do seu site de destino.

17.4.3 traceroute ¶

Se você não conseguir " pingar " seu site de destino, isso pode ser usado para determinar o problema (possivelmente um firewall ou um proxy). Ele também pode ser usado para estimar a latência geral da rede (executar localmente deve fornecer a menor latência de rede possível - lembre-se de que seus usuários estarão executando em uma Internet possivelmente ocupada). Geralmente, quanto menos saltos, melhor.

17.5 Como posso aprimorar o JMeter? ¶

Existem muitos provedores comerciais e de código aberto que fornecem plugins JMeter ou outros recursos para uso com JMeter. Alguns deles estão listados no JMeter Wiki. Eles estão listados em várias categorias:

JMeterPlugins - plugins para estender o JMeter
JMeterAddons - addons para uso com JMeter, por exemplo, plugins para navegadores, Maven e Jenkins.
JMeterServices - serviços de ^terceiros , por exemplo, JMeter baseado em nuvem

Observe que a aparição destes no Wiki não implica qualquer endosso do projeto Apache JMeter. Quaisquer solicitações de suporte devem ser direcionadas ao fornecedor relevante.

17.6 Por que Java? ¶

Por que não Perl ou C?

Bem, Perl pode ser uma escolha muito boa, exceto que o pacote Benchmark parece dar resultados bastante confusos. Além disso, simular vários usuários com Perl é uma proposta complicada (várias conexões podem ser simuladas por bifurcação de muitos processos de um script de shell, mas estes não serão threads, serão processos). No entanto, a comunidade Perl é muito grande. Se você achar que alguém já escreveu algo que parece útil, essa pode ser uma solução muito boa.

C, é claro, é uma escolha muito boa (confira a ferramenta Apache ab ). Mas esteja preparado para escrever todos os códigos personalizados de rede, encadeamento e gerenciamento de estado que você precisará para comparar seu aplicativo.

O Java fornece (gratuitamente) o código personalizado de rede, encadeamento e gerenciamento de estado que você precisará para comparar seu aplicativo. Java está ciente de HTTP, FTP e HTTPS - bem como RMI, IIOP e JDBC (sem mencionar cookies, codificação de URL e reescrita de URL). Além disso, o Java oferece coleta de lixo automática e segurança em nível de código de byte.

Go to top