Preparando-se para a inundação: Seu GIS Server vai afundar ou nadar?

RandallWilliams

<\/HEAD>Tenho feito alguns testes de carga contra o ArcGIS Server recentemente, e me veio à mente que, embora frequentemente digamos aos usuários para usarem ferramentas de teste de carga antes de tornar pública uma aplicação GIS, não entramos em muitos detalhes sobre como configurar esses testes. Neste blog, vou descrever como configurar e executar testes usando uma ferramenta Java open source chamada JMeter para ajudar no teste de carga da sua instalação e aplicação GIS Server.Primeiro, o que é JMeter<\/A>?<\/STRONG>

Do site do JMeter:

O aplicativo desktop Apache JMeter<\/STRONG>100% puro Java, software open source projetado para testar a carga do comportamento funcional e medir desempenho. Foi originalmente criado para testar Aplicações Web, mas desde então expandiu para outras funções de teste.cO que posso fazer com ele? <\/STRONG>

cApache JMeter pode ser usado para testar desempenho tanto em recursos estáticos quanto dinâmicos (arquivos, Servlets, scripts Perl, Objetos Java, Bancos de Dados e Consultas, Servidores FTP e mais). Pode ser usado para simular uma carga pesada em um servidor, rede ou objeto para testar sua resistência ou analisar o desempenho geral sob diferentes tipos de carga. Você pode usá-lo para fazer uma análise gráfica do desempenho ou para testar o comportamento do seu servidor\/script\/objeto sob carga concorrente pesada.c

Isso é ótimo, mas aqui está o que EU<\/STRONG> faço com ele:

Eu uso o JMeter para simular a carga de um grupo de usuários trabalhando simultaneamente com o ArcGIS Server. Esses usuários simulados são SOBRENATURAIS, pois meus testes JMeter disparam requisições na taxa de centenas ou milhares por minuto. Recentemente testei a utilização de memória da versão 10.1 após enviar literalmente mais de 100 milhões de requisições de consulta de feição ao ArcGIS Server em um AMI durante cerca de uma semana. (Você ficará feliz em saber que descobri que a memória foi bem gerenciada durante esse teste).

Lembre-se que o JMeter não é um navegador. Embora o servidor complete qualquer operação que você submeta a ele, o JMeter não renderiza a resposta graficamente. Você obtém resultados na forma de uma notificação PASSAR\/FALHAR.

Legal. Vamos juntar tudo isso e executar um teste. Permita-me guiá-lo.O que eu preciso?<\/STRONG>

Ótima pergunta. Você vai precisar:Sua máquina ArcGIS Server. Você pode testar Java ou .Net, em qualquer SO suportado.<\/LI>Um lugar para instalar o JMeter. Pode ser a mesma máquina do seu ArcGIS Server, mas acho que você obterá resultados mais precisos se o JMeter estiver instalado em outro lugar. Isso porque enquanto roda, o container Java da aplicação JMeter consome uma boa quantidade de RAM, o que pode distorcer seus resultados. O JMeter é uma ferramenta pura Java, então pode rodar no Windows e Linux. Para meus testes, estou rodando o JMeter no Win08.<\/LI>Fiddler e Firebug. Acho que a ferramenta Fiddler<\/A> é útil para solucionar problemas de requisições falhadas e similares. Também é boa para ajudar a construir requisições a serem usadas no seu plano de teste. Fiddler e Firebug (add-on para o navegador Firefox) são excelentes ferramentas leves para teste e depuração.<\/LI>O Ambiente de Execução Java (JRE) instalado e uma variável de ambiente apontando para JAVA_HOME.<\/LI><\/UL>Por onde começo?<\/STRONG>

Não há realmente um instalador para o JMeter; tudo que você precisa está dentro da pasta da aplicação. A primeira coisa a fazer é abrir a pasta JMeterbin e dar uma olhada no arquivo JMeter.bat.  Na linha 71, encontre a linha que diz:set HEAP=-Xms512m \u2013Xmx512m<\/EM>

Essa variável define a quantidade de memória dedicada ao Heap Java.

Eu aumentaria isso para 1024, dedicando um gigabyte completo de memória à JVM, assim:set HEAP=-Xms1024m -Xmx1024m<\/EM>

Caso contrário, especialmente em testes maiores, você corre o risco de ultrapassar o limite do Heap Java, o que pode causar falha na JVM dedicada ao JMeter.

Depois de baixar o JMeter, instalar o JRE e definir a variável JAVA_HOME apontando para sua instalação Java, é hora de iniciar o JMeter. Para isso, abra um prompt de comando e navegue até o diretório BIN do JMeter (o mesmo local onde está o JMeter.bat). Execute o JMeter.bat pela linha de comando e a aplicação JMeter será aberta.<\/A>

Com o JMeter aberto, é hora primeiro definir alguns padrões. Para isso, clique com o botão direito no ícone Plano de Teste (parece um béquer) e adicione um Elemento Padrão de Requisição HTTP.  (Adicionar>Elemento Config>Padrões Requisição HTTP)<\/A>

Agora vamos preencher alguns desses parâmetros na página Padrões Requisição HTTP.

Nome do servidor ou IP: isso é autoexplicativo. Insira o endereço IP ou nome do host da máquina que executa o ArcGIS Server (ou o proxy que aponta para ele).  Normalmente não defino tempos limite de conexão ou resposta aqui no JMeter. O caminho será o caminho até seu endpoint SOAP ou REST – até a operação que deseja realizar (consulta, exportar mapa etc.). Os parâmetros enviados com a requisição são semelhantes aos definidos se você estiver consultando pelo Diretório REST Services.

Acho útil usar a ferramenta Fiddler para capturar as URLs das consultas enviadas pela página REST do serviço ou sua aplicação web para ajudar a preencher esses parâmetros.

Por exemplo, você pode emitir uma consulta baseada em um conjunto de coordenadas X\Y com a intenção de recuperar alguns atributos para uma feição dada. Nesse caso, você pode capturar uma URL semelhante à seguinte no Fiddler:

http:\/\/randall:6080\/arcgis\/rest\/services\/usa\/MapServer\/0\/query?where=\n&text=&objectIds=&time=&geometry=-119.78861600000%2C35.30318900030\n&geometryType=esriGeometryPoint&inSR=4269&spatialRel=esriSpatialRel\nIntersects&relationParam=&outFields=*&returnGeometry=true&maxAllowable\nOffset=&outSR=&returnIdsOnly=false&returnCountOnly=false&orderByFields\n=&groupByFieldsForStatistics=&outStatistics=&returnZ=false&returnM=false\n&f=pjson<\/PRE>
Nessa URL estou emitindo uma consulta à camada '0' em um serviço chamado 'usa' servido pela porta 6080 na máquina chamada 'randall'.

Não estou usando operadores SQL reais (a cláusula where), nem procurando por um atributo texto específico (text). Não me importo com ID do objeto ou elemento tempo. Me importo com a geometria, é onde meus valores XY estão especificados. De fato, os únicos elementos importantes nesse teste são a referência espacial (4326), a relação espacial (interseção), os campos retornados (* pois quero todos), e estou enviando a geometria como ponto. Finalmente, neste teste gostaria que o servidor respondesse às requisições enviadas no formato JSON.  Com isso em mente posso truncar um pouco a URL que vou analisar para facilitar configurar o teste no JMeter:http:\/localhost:6080\/ArcGIS\/rest\/services\/usa\/MapServer\/0\/query?&geometry\n=-149.54518800000%2C70.42196900010&geometryType=esriGeometryPoint&inSR=4269\n&spatialRel=esriSpatialRelIntersects&returnCountOnly=false&returnIdsOnly=\nfalse&returnGeometry=true&outFields=*&f=json<\/PRE>
Depois de reunir esses padrões coloco essas entradas no meu projeto JMeter:

<\/A>

Em seguida preciso configurar alguns usuários simulados. Embora tenhamos os padrões da requisição definidos, queremos testar com muitos valores diferentes – em outras palavras, não queremos que nossa aplicação apenas receba sempre a mesma requisição repetidamente, isso seria muito fácil. É melhor testarmos com muitas amostras diferentes.  No JMeter isso é feito criando 'grupos de threads'.

Clique com botão direito no plano de teste e selecione 'Adicionar', depois 'Threads (Usuários)'. No meu caso estamos simulando uma carga de 16 usuários, então cada grupo terá 2 threads. Quero ver quanta carga minha aplicação aguenta antes de falhar, então configuro esse teste para rodar indefinidamente.

Uma vez configurados os Grupos de Threads precisaremos configurar as requisições reais contendo os padrões definidos anteriormente assim como as variáveis que queremos passar nas requisições. Para isso clique com botão direito num Grupo Thread escolha 'Adicionar', 'Elemento Config' e depois 'Padrões Requisição HTTP'. Essa tela deve parecer familiar pois é exatamente igual aos padrões criados inicialmente.

Neste caso objetivo do teste é ver quanta carga servidor aguenta se forem enviadas centenas de milhares requisições query para coletar os atributos de uma feature com base nas coordenadas XY passadas pela query.

Então, para cada requisição enviada pelo JMeter, o único elemento da query que muda de requisição para requisição será a geometria do ponto de entrada. Para isso, compilei um arquivo .CSV e configurei um elemento CSV Data Set Configuration no meu projeto de teste (Add>Config element>CSV data set Config). Sua fonte de dados não precisa ser CSV, você pode usar uma tabela de banco de dados se preferir – use uma conexão JDBC para isso.<\/A>

Conforme a figura acima, meu arquivo CSV se chama xycord.csv (eu tenho o CSV armazenado na mesma pasta do meu plano de teste – se o seu estiver armazenado em outro lugar, defina o nome do arquivo para o caminho absoluto onde ele está localizado.

Certifique-se de definir os nomes das variáveis corretamente – se houver espaços e vírgulas no seu arquivo CSV; certifique-se de que este elemento reflita esses espaços. A delimitação por vírgula aqui apenas separa os nomes das variáveis no CSV – o delimitador real usado no arquivo CSV é descrito no parâmetro 'Delimiter'. Como estou permitindo que meu teste rode até que eu force a parada, estou reciclando as requisições e não paro quando o JMeter detecta que o fim do arquivo foi alcançado.

Para meu teste, repliquei cada parâmetro da requisição HTTP para cada um dos usuários que estou simulando nos grupos de threads que configurei.

Agora é hora de testar. Salve o plano de teste.

No JMeter, vá em 'Run', depois 'Start'. Clique em um dos relatórios.

Com sorte, suas requisições irão rodar. Se a porcentagem de erro que você obtiver for 100%, provavelmente você está enviando requisições inválidas.

Você pode examinar as requisições que está enviando ao servidor trabalhando com a ferramenta Fiddler:

Se o Fiddler estiver instalado na mesma máquina que o JMeter, então na página principal dos defaults da requisição HTTP, você pode forçar o tráfego a passar pelo proxy do Fiddler para que as requisições e respostas subsequentes sejam capturadas. Por padrão, o Fiddler escuta na porta 8888, então você pode configurar o JMeter da seguinte forma:<\/A>

Quando você iniciar sua execução no JMeter novamente, o Fiddler irá capturar o tráfego, o que permitirá que você veja o que o JMeter está passando para que possa fazer ajustes conforme suas necessidades.Algumas Dicas<\/STRONG>

Use o menor número possível de listeners. Para testes menores, os contadores gráficos são ótimos. No entanto, esses contadores consomem muita memória, e eu já travo minha JVM com testes maiores quando uso contadores. Eu uso apenas o Summary Report – ele tem as informações que preciso.

Considere usar o JMeter a partir da interface de linha de comando uma vez que sua configuração esteja pronta. A opção Command Line consome poucos recursos.

É isso por enquanto nesta edição. Vou continuar com fluxos adicionais de testes assim que puder.Randall W. - Server Support Analyst<\/EM>



<\/BODY><\/HTML>

AndresCastillo

This is exactly the tool (also SoapUI) that we are using now to load test and debug some datastore crashes we are experiencing.

See related article:

https://community.esri.com/groups/technical-support/blog/2017/01/11/gauging-arcgis-gis-server-performance-with-integrated-windows-authentication 

Also, another tool that we use in case of a request failure:

https://community.esri.com/groups/technical-support/blog/2018/06/07/monitoring-web-service-requests-using-fiddler 

Also, Chrome Dev Tools>Network>export Har