Que tipo de “simplificação” ocorre quando você usa uma única máquina para gerar carga / estresse?

Question

O título desta pergunta representa minha principal preocupação, mas se você ler além da seção pergunta , você encontrará informações sobre nossa configuração ... que podem ou não ser relevantes / útil.

Pergunta

Nós estamos testando o nosso aplicativo usando Gatling , e estamos executando o cenário Gatling em uma máquina única . Estamos descobrindo que nossa aplicação é capaz de lidar com uma alta carga gerada pela ferramenta de estresse; no entanto, não é capaz de lidar com uma carga relativamente baixa de usuários reais.

A minha pergunta é: que tipo de otimização ou simplificação do sistema operacional / rede ocorre quando solicitações simultâneas são feitas de uma única máquina / sistema operacional para um aplicativo, versus solicitações simultâneas de várias máquinas (por exemplo, usuários regulares usando seus navegadores da web)?

Antecedentes

Temos um aplicativo Tomcat atrás do Apache via AJP, que está por trás de um Citrix Netscaler via porta 80 (também estamos planejando tirar o Apache da equação, mas isso é outro problema ...).

Nosso aplicativo foi paralisado sob carga relativamente baixa (conexões CLOSE_WAIT acumuladas entre o apache e o tomcat) e estamos no processo de teste de carga para resolver o problema. Deadlocks, ocorridos em nossa instância do SQLServer, estavam aparecendo com bastante frequência e então decidimos começar por lá. Para replicar o problema e testar nossas correções, usamos uma única máquina para gerar carga usando o Gatling.

Quando começamos, pudemos replicar os deadlocks de maneira confiável usando a ferramenta. Depois que fizemos algumas otimizações, os deadlocks foram embora, e também as conexões CLOSE_WAIT. Em seguida, colocamos o aplicativo em uma carga com a qual ficamos muito felizes e ele correu sem nenhum grande problema.

Infelizmente, quando as correções foram aplicadas ao sistema de produção, ainda estávamos vendo o mesmo comportamento original. O que me leva a pensar se a carga gerada pela ferramenta de estresse não é uma boa representação do que realmente está acontecendo no mundo real, devido a ela ter origem em uma única fonte, em vez de muitos clientes diferentes espalhados pela Internet. .

    

Answer 1

Um único gerador de carga provavelmente fará um trabalho melhor de pooling de conexão do que clientes díspares; melhor uso de Keepalives por exemplo. Isso gera mais solicitações por menos conexões.

Se o DNS round-robin estiver envolvido, ele tenderá a atingir apenas um dos destinos DNS, em vez de distribuir a carga por todos eles. Alguns balanceadores de carga tomam decisões de aderência com base no IP do cliente, o que seria estático nesse caso.

Seu gerador de carga pode ter um pool de execução restrito (digamos, 200 'usuários') para que a latência na resposta faça com que os usuários fiquem lentos, ao contrário do mundo real em que você tem um número muito maior de usuários espere pacientemente que outros usuários terminem.

    

Answer 2

É difícil manter qualquer coisa sem ver seu cenário de teste do Gatling. Apenas uma "foto cega": o teste de Gatling não representa com precisão o usuário real, por exemplo

• Os navegadores reais baixam recursos externos incorporados na página, ou seja, imagens, scripts e estilos, e fazem isso usando o conjunto de encadeamentos simultâneos. Se o seu teste do Gatling não tiver os métodos inferHtmlResources , poderá ser o caso a carga, vinda de Gatling, é muito menos do que conduzida por usuários reais sentados atrás dos navegadores reais

• Cache de DNS. O Gatling pode atingir apenas um endereço IP devido a endereços IP que fazem o cache de nomes DNS no nível da JVM. De acordo com a FAQ do Gatling :

  Basically, Gatling/JVM’s DNS cache has to tuned. A solution is to add -Dsun.net.inetaddr.ttl=0 to the command line.

• Solicitações de AJAX. Gatling não executa JavaScript do lado do cliente, portanto, se o seu aplicativo é construído em solicitações XMLHTTP, elas não serão disparadas quando o Gatling acessar a página. Você precisará manipulá-los manualmente caso seu aplicativo esteja usando alguma forma de AJAX

Então, eu recomendaria referir