Qual é o maior número de threads que é razoável para executar simultaneamente em Jmeter?

Question

Eu quero usar o maior número possível de tópicos (para usar menos computadores), mas sem fazer o gargalo estar no cliente.

Answer 1

Eu usei JMeter um pouco justo e descobriu que não é grande para a geração de muito alta carga. Em uma 2Ghz Core2 Duo com 2Gb de memória você pode razoavelmente esperar cerca de 100 threads.

Dito isto, é melhor para executá-lo em seu hardware para que a CPU do PC não faz pico em 100% -. Um estábulo 80% -90% é o melhor caso contrário, os resultados são afetados

Eu também tentei WAPT 5 - ele foi executado com êxito 1000 tópicos do mesmo PC. Não é gratuito, mas é mais útil do que o JMeter, mas não tem todos os recursos.

resposta desatualizado desde pelo menos a versão 2.6 ver https://stackoverflow.com/a/11922239/460802 para uma mais atualizado um.

Answer 2

JMeter pode simular uma carga muito alta desde que você usá-lo.

Não dê ouvidos a Urban Legends que dizem JMeter não pode lidar com a carga elevada.

Agora, como para resposta, que depende de:

• o poder da máquina

• seu JVM de 32 bits ou 64 bits

• JVM memória alocada -Xmx

• seu plano de teste (muito beanshell, pós-processador, xpath ... significa muita cpu)

• a configuração do sistema operacional (ajustável)

• modo de gui Gui / não

Assim, não há uma resposta teórica mas seguindo Melhores Práticas irá garantir JMeter tem um bom desempenho.

Note que, com jmeter você pode distribuir a carga por meio de testes remota, leia-se:

• remoto Testing> 15,4 Usando um remetente amostra diferente

E, finalmente, usar o teste baseado em nuvem, se não é o suficiente.

Leia este para dicas de ajuste:

• http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/

Leia este livro para fazer testes de carga e usar JMeter corretamente.

Answer 3

O JMeter Wiki casos relatórios onde JMeter foi utilizado com até 1000 linhas. Eu usei-o com, no máximo, 100 tópicos, mas os links no Wiki sugerem reduções de recursos Eu nunca tentei.

Answer 4

Uma das questões que tivemos com o funcionamento de JMeter no Windows XP era o limite de conexão Windows XP TCP. Limite deve ser removido para executar usar o JMeter para o pleno potencial da estação de trabalho Mais informações aqui . AFAIK, não se aplica a outros sistemas operacionais.

Answer 5

Eu usei JMeter desde 2004 e eu lançou monte de testes de carga.

Com o PC Windows 7 64 bits 4Go RAM iCore5.

Eu acho que JMeter pode suportar 300 a 400 threads simultâneos para o protocolo HTTP (Sampler) com apenas um "Aggregate Relatório Listener", que escreve nos resultados de arquivo de log e temporizadores entre as páginas de chamada.

Para um teste de carga grande você poderia configurar JMeter com escravos (geradores de carga) como este http://jmeter-plugins.org/wiki/HttpSimpleTableServer/

Eu já fizeram testes com 11 escravos PC para simular 5000 tópicos.

Answer 6

Eu não usei JMeter, mas a resposta provavelmente depende do seu hardware. Melhor aposta pode ser a criação de métricas de desempenho, acho que com o número de tópicos e, em seguida, executar uma pesquisa binária da seguinte forma.

Fonte foi Wikipedia.

Número jogo de adivinhação ...

Este jogo bastante simples começa algo como "Estou pensando em um inteiro entre quarenta e sessenta e inclusivo, e aos seus palpites eu vou responder 'High', 'Low', ou 'Sim!' como poderia ser o caso." Supondo que N é o número de possíveis valores (aqui, vinte e um como "inclusiva" foi indicado), depois para a maioria das perguntas são necessárias para determinar o número, já que cada pergunta metades do espaço de busca. Note-se que um menor questão (iteração) é necessário que para o algoritmo geral, uma vez que o número já é constrangido a estar dentro de um determinado intervalo.

Mesmo se o número que nós estamos adivinhando pode ser arbitrariamente grande, caso em que não há nenhum limite superior N, ainda podemos encontrar o número em, no máximo passos (onde k é o (desconhecido) selecionada número) pela primeira constatação um limite superior por duplicação repetido. Por exemplo, se o número eram 11, que se poderia utilizar o seguinte sequência de tentativas para encontrar: 1, 2, 4, 8, 16, 12, 10, 11

Pode-se também estender a técnica de incluir números negativos; por exemplo as seguintes suposições poderia ser usada para encontrar -13: 0, -1, -2, -4, -8, -16, -12, -14, -13

Answer 7

É mais dependente do tipo de desempenho testando você fazer (carga, ponto, resistência etc) em um servidor específico (um pouco sobre dependência de hardware)

Tenha em mente em torno destes parâmetros - a máquina cliente no qual você está direcionando o prazo de jmeter, haverá uma certa quantidade de memória heap alocado, garantir a ter uma alocação saudável para que o script não erro fora. O mais alto que eu tinha executado em jmeter era 1500 em um ambiente local (cliente - arch servidor), Em um arco Web, o mais alto que eu tinha uma corrida foi baseada em requisitos funcionais Não- foram limitados a 250 threads,

por isso ideal depende dos tipos de testes de desempenho e estilo implantação e assim por diante ..

Answer 8

Não há número padrão para isso. O número máximo de linhas que você pode gerar a partir de um computador depende completamente o hardware do computador e do sistema operacional. O sistema operacional por padrão ocupa certa quantidade de CPU ea RAM.

Para saber os tópicos máximo seu computador pode lidar com você pode preparar um teste de amostra e executá-lo com apenas alguns tópicos. Em seguida, com cada ciclo de teste aumentar o número de segmentos de forma gradual. Durante este também é preciso monitorar a CPU, RAM, disco I / O e de rede I / O do seu computador. No momento em que qualquer um destes alcance próximo ou acima de 80% (uma vez para que você possa decidir se perto é bom para você ou além), que é o número máximo de threads de seu computador pode manipular. Para estar no lado mais seguro eu iria parar com o número quando a utilização de recursos chega a 70%.

Answer 9

Isso vai depender do hardware é executado em, bem como o roteiro subjacente. Eu sempre senti que esta imprecisão é o maior problema com as ferramentas de teste de carga tradicionais. Se você tem um orçamento pequeno (US $ 200 ou assim que você recebe um monte de testes), veja serviço de testes de carga da minha empresa , BrowserMob.

Além dos nossos utilizadores navegador real (RBUS) que controle milhares em navegadores reais para fins de desempenho e testes de carga, nós também têm usuários virtuais tradicionais (UVs). Os scripts são escritos em JavaScript e pode fazer várias chamadas HTTP.

A razão de eu levá-la é que eu sempre senti que o jogo de tentar descobrir quantos VUs você pode caber em sua carga de hardware gen é perigoso. É tão fácil de obter maus resultados sem perceber.

Para resolver esse para BrowserMob, tomamos uma abordagem extremamente conservadora do número de UVs e RBUS por núcleo de CPU: não mais do que 1 navegador ou 50 threads por núcleo da CPU, e às vezes muito menos. No mundo da computação em nuvem, ciclos de CPU são tão baratos que ele simplesmente não faz sentido tentar máquinas de sobrecarga.