Por que Testar um Serviço de Camada de Feição Hospedada?
Artigos anteriores da Comunidade sobre testes de desempenho com Apache JMeter focaram em exercitar Serviços de Mapa através da função de exportação. No entanto, Hosted (feature) layers são também uma capacidade popular do ArcGIS Enterprise e são amplamente usados em implantações. Além disso, consultar essas camadas é baseado em um design de grade "repetido" que pode ajudar a fornecer um grau maior de escalabilidade em relação a outras tecnologias de visualização. Junte isso com a renderização do lado do cliente dos dados retornados e é uma situação vantajosa para ambos os lados.
Dado que os serviços de feição hospedados são uma tecnologia de serviço comprovada e favorita, faz sentido querer testar consultas de feição sob carga para observar sua escalabilidade em primeira mão.
Desafios no Teste do Serviço de Camada de Feição Hospedada
Comparado ao teste da função de exportação de mapa, testar consultas do Serviço de Camada de Feição Hospedada é desafiador, pois as requisições são mais complexas para serem realizadas programaticamente. Um "pan" navegacional ou um "zoom" no navegador web produz várias consultas diferentes, cada uma com sua própria geometria. Para repetir esse comportamento, o teste de carga construído não terá apenas uma requisição para emitir, mas muitas e em quantidade variável. Junte isso ao fato de que cada requisição de consulta na transação terá uma geometria única e maxAllowableOffset variável (dependendo da escala do mapa) e são muitas partes móveis para acompanhar.
Como Testar um Serviço de Feição Hospedado?
O Conjunto de Dados USGS Motor Vehicle Use Roads
A compreensão do processo neste Artigo é mais eficaz se os passos puderem ser reproduzidos. Mas essa repetibilidade requer acesso ao mesmo conjunto de dados. O tamanho espacial da fonte dos dados também precisa ser grande o suficiente para gerar dados decentes para teste, mas não tão grande a ponto de ser incômodo para baixar.
Apresentamos o conjunto de dados da camada de feição Motor Vehicle Use Map: Roads no hub.arcgis.com. Os 179 mil registros polilinha dos dados USGS Roads em WGS 1984 Web Mercator (Auxiliary_Sphere), equivalem a cerca de 200MB quando compactados. É fornecido sob a licença Creative Commons (CC0).
- Visualização dos dados Roads no ArcGIS Pro:
- Visualização em grande escala com rotulagem ativada:
Esses dados serão publicados do ArcGIS Pro para um serviço de feição hospedado no ArcGIS Enterprise ou carregados diretamente através do Portal for ArcGIS.
Geração de Dados para Teste
Este teste exigirá alguns bons dados para usar dentro do teste JMeter.
Para enfrentar tal tarefa, é altamente recomendado usar as excelentes Load Testing Tools.
A versão 1.2.2 adiciona novas capacidades como a ferramenta "Generate Query Extents", que será uma grande ajuda para gerar dados para teste do serviço de feição.
Esses dados utilizam o design baseado em grade, que é o que queremos. Com a abordagem baseada em grade, envelopes para a área desejada são criados nos bastidores. Então, esses envelopes são convertidos para as extensões apropriadas de consulta 512x512. O número das consultas (para cada envelope inicial) variará dependendo da posição na grade... isso imita o comportamento do serviço em um navegador web.
Disponibilizando as Ferramentas no ArcGIS Pro
Uma vez que o projeto load-testing-tools tenha sido baixado para sua máquina, coloque a pasta descompactada em um diretório acessível ou tornado acessível pelo ArcGIS Pro. Se você já tem uma versão anterior das Load Testing Tools instalada, esta versão atualizada pode ser instalada ao lado dela (embora com um nome diferente da pasta) ou substituir completamente a pasta existente.
Por exemplo:
- Coloque a pasta load-testing-tools em C:\Users\[username]\Documents\ArcGIS
- Use a Conexão Adicionar Pasta do Catálogo no ArcGIS Pro para listar o conteúdo deste diretório:
A ferramenta "Generate Query Extents" pode funcionar com o serviço de feição hospedado, uma cópia local dos dados ou os dados dentro de um geodatabase empresarial.
Atenção: a ferramenta deve gerar extensões de consulta a partir de quaisquer dados, mas requer que o Sistema de Coordenadas Projetadas seja WGS 1984 Web Mercator Auxiliary_Sphere (WKID: 3857).
Selecione uma Área de Interesse
Selecione uma área de interesse no mapa na qual gerar os dados para teste. Neste exemplo, os dados Roads estão sendo visualizados do Noroeste dos Estados Unidos (perto das fronteiras dos estados Idaho e Montana). A escala do mapa selecionada é 1:1.000.000.
Execute a Ferramenta Generate Query Extents
- A execução da ferramenta Generate Query Extents deve apresentar entradas similares às seguintes:
Ajuste as Entradas para a Ferramenta Generate Query Extents
As entradas padrão foram ajustadas para refletir o seguinte:
- Vários níveis menores e maiores foram removidos
- Os níveis restantes são 12, 13 e 14 que correspondem às escalas do mapa 144448, 72224 e 36112, respectivamente
- O Número de Registros para essas escalas foi aumentado
- Nível 14 pode ser omitido dependendo da versão das Load Testing Tools (se estiver ausente, por favor adicione este Nível manualmente)
- A Localização do Arquivo Saída que deve ser algo similar a:
- C:\Users\username\Documents\ArcGIS\Projects\Catalog2\query_extents.csv
- Clique em Executar para executar a ferramenta
Atenção: A duração do tempo para gerar os dados depende de vários fatores como o número dos diferentes Níveis Escalares, o Número de Registros (por cada Nível Escalar) e a escala atual do mapa do Projeto.
Atenção: Gerar dados usando outros conjuntos pode exigir o uso de diferentes Níveis Escalares baseados no nível de detalhe e densidade das feições.
Validando os Dados Gerados para Teste
É uma boa prática verificar visualmente os dados gerados para teste. Isso permite ao testador saber o que o teste de carga irá solicitar espacialmente ao serviço de feição.
Uma vez que a ferramenta tenha sido concluída com sucesso ela irá gerar 3 conjuntos principais de dados que são de interesse:<\/P>
- Classes de feição da caixa delimitadora
- Contém áreas de interesse geradas aleatoriamente<\/LI>
- Uma classe de feição para cada Nível de Escala solicitado<\/LI><\/UL><\/LI>
- Classes de feição da Extensão da Consulta
- Contém uma grade de blocos (512x512) na qual cada consulta de feição será baseada<\/LI>
- Uma classe de feição para cada Nível de Escala solicitado<\/LI><\/UL><\/LI>
- Arquivos CSV da Extensão da Consulta
- Contém os dados de teste gerados<\/LI>
- Cada linha é composta pelos componentes dinâmicos de uma solicitação do serviço de feição<\/LI>
- Um arquivo para cada Nível de Escala solicitado<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Do painel Catálogo, carregue a classe de feição bbox_36112 no mapa atual no ArcGIS ProEsta saída é muito semelhante aos dados da ferramenta Generate Bounding Boxes<\/LI><\/UL><\/LI>Neste exemplo, as caixas geradas aleatoriamente estão em rosaEssas áreas representam a resolução da tela do usuário que está solicitando dados do serviço de feição<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Agora, do painel Catálogo, carregue a classe de feição query_extents_36112 no mapa atual, mas atrás (abaixo) dos dados bbox_36112<\/LI>Neste exemplo, as caixas da grade dos blocos da consulta estão em verdeEsses blocos correspondem a uma área no mapa para a qual as caixas delimitadoras estão solicitando dados<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Aumentar o zoom no mapa pode proporcionar uma melhor compreensão da relação entre esses dois conjuntos de dados<\/LI>Como visto no mapa abaixo, algumas caixas delimitadoras estão ligeiramente deslocadas umas das outras, mas ainda compartilham um bloco comum da grade abaixo delas<\/LI>As coordenadas desses blocos da consulta (por exemplo, da classe de feição query_extent) são o que irá para os arquivos CSV e, finalmente, para o teste de carga JMeter<\/LI><\/UL>
<\/span><\/P>Analisar mais detalhadamente as caixas delimitadoras revela detalhes sobre sua respectiva composição da consultaPor exemplo, algumas caixas podem exigir 12 blocos "subjacentes" para serem atendidas, outras 15 ou 20<\/LI>Como visto no mapa abaixo, a caixa delimitadora destacada em preto requer 12 blocos específicos da consulta coloridos em vermelho<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P> Nota: O design da grade dos blocos do serviço de feição é uma das suas principais forças, pois permite repetibilidade. Essa repetibilidade pode ser aproveitada com cache em uma implantação para melhorar a escalabilidade. Isso não é possível com export map.<\/STRONG><\/FONT><\/P>Analisar os arquivos CSV gerados revelará os resultados finais dessa transformação<\/LI>Visualizar o arquivo query_extents_36112.csv em um editor de texto deve mostrar algo semelhante ao seguinteDependendo da versão das Load Test Tools, os arquivos CSV podem estar ordenados pela coluna operationid<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Dependendo da versão das Load Testing Tools, a linha pode ou não estar agrupada pela coluna operationid<\/SPAN>
- A compreensão do operationid, neste caso, é um conceito importante de teste, pois cada operação representa uma ação de navegação (por exemplo, um pan ou zoom)
- Do ponto de vista do JMeter, uma operação é o mesmo que uma transação
- Todas as linhas com um operationid correspondente se tornarão geometrias de solicitação de consulta do serviço de feição sob o mesmo controlador de transação
O Plano de Teste da Consulta do Hosted Feature Service
Para baixar o Plano de Teste Apache JMeter usado neste Artigo veja:
roads_hfs1.zip
- Abrir o Plano de Teste no Apache JMeter deve ser semelhante ao seguinte:
- Ajuste as Variáveis Definidas pelo Usuário para se adequar ao seu ambiente
- Os 3 arquivos CSV gerados pela ferramenta são referenciados pelas variáveis JMeter DataFile_A, DataFile_B e DataFile_C apenas pelo nome do arquivo (o caminho do sistema de arquivos não está incluído aqui)
Componentes do Plano de Teste
Lógica do Leitor de Dados
O teste roads_hfs é um pouco diferente dos outros exemplos de teste Apache JMeter usados em artigos anteriores. A principal diferença é que embora ainda seja um teste orientado por dados (por exemplo, arquivos CSV são usados como entrada para solicitações), ele não usa o típico elemento Config "CSV Data Set Config" para ler os dados. Em vez disso, essa lógica é realizada por meio dos Samplers JSR223 que executam código Groovy. A razão para utilizar Groovy é devido à natureza da interação com um serviço de feição mencionada anteriormente. Lembre-se que algumas transações terão 12 solicitações e outras podem ter 15 ou 20 (dependendo de onde a área geral de interesse cai na grade dos blocos). Essa diferença no número de solicitações exige que o teste use um mecanismo mais flexível para ler e usar os dados dos arquivos CSV, já que isso não será constante.
- Há um Sampler JSR223 para cada arquivo CSV (por exemplo, cada escala do mapa)
- Todos os Samplers JSR223 para leitura dos dados são colocados em um Controlador Once Only para minimizar a sobrecarga
- A leitura do arquivo CSV será realizada apenas uma vez, no início de cada thread do teste
- Abaixo está mostrado "JSR223 Sample A1", que estará lendo o arquivo query_extents_72224.csv
- Não é necessário experiência em codificação Groovy para executar este teste; na verdade, esses Samplers JSR223 não precisam ser editados para executar o teste, mas é útil entender qual lógica é responsável por ler os dados CSV
Lógica de Seleção do Operation ID
Uma vez que os dados CSV foram lidos, o teste precisará selecionar um operation id para cada escala a cada iteração do teste. Para isso, foi usado um segundo conjunto de Samplers JSR223 para escolher dentre cada lista de operações.
- Há um Sampler JSR223 para cada escala do mapa que seleciona aleatoriamente um operation id
- Todos os Samplers JSR223 para gerar esse operation id são colocados em um Controlador Transaction chamado Operation Generator
- Isto é executado a cada iteração do thread do teste
- Esses Samplers JSR223 não precisam ser editados para executar o teste
color="#FF0000">Nota: Os JSR223 Samplers usando Groovy geralmente são executados rapidamente e adicionam muito pouca sobrecarga ao teste
Loop de Operação e População de Parâmetros
Com um id de operação escolhido, o foco se torna a lógica do loop onde o teste irá consultar o número de consultas de serviços de feição que compõem a transação. A partir daí, ele usará um terceiro conjunto de JSR223 Samplers para popular os parâmetros das requisições associados ao id da operação selecionada anteriormente a cada iteração no loop.
- Há um JSR223 Sampler para cada escala de mapa que popula as variáveis associadas do JMeter com base no id da operação e valor da iteração
- Esses itens então se tornam pares chave/valor que são capturados pelo HTTP Request
- Os valores da iteração são rastreados por um Elemento de Configuração Counter
- Esses JSR223 Samplers não precisam ser editados para executar o teste
- Cada Loop Controller, Counter, JSR223 Sampler e objetos HTTP Request são todos colocados dentro de um Transaction Controller correspondente para separar logicamente os itens para cada escala de mapa
HTTP Request
Essencialmente, toda a lógica do teste acima existe apenas para este componente do teste. Aqui, o objeto HTTP Request do JMeter pode ler as variáveis do JMeter para parâmetros específicos chave/valor que foram populados pelo JSR223 Sampler imediatamente antes dele.
Como essa abordagem é altamente programática, há apenas um HTTP Request por escala de mapa! Tal design favorece a manutenção.
Nota: Esta abordagem de teste também funcionaria para serviços tradicionais de camada de feição não hospedados. No entanto, esses serviços de feição não possuem as mesmas otimizações de parâmetros de requisição que os serviços hospedados possuem, como maxAllowableOffset e quantizationParameters. Essas opções precisariam apenas ser removidas do HTTP Request.
A Configuração do Thread Group
O Plano de Teste do JMeter está atualmente configurado para um teste relativamente curto de 10 minutos. De modo geral, serviços hospedados de feição apresentam bom desempenho, então muito throughput ocorrerá em cada etapa (1 minuto por etapa) assim como no teste como um todo.
- Diferentes ambientes e dados podem requerer uma configuração alternativa para alcançar os resultados desejados, ajuste conforme necessário
Validando o Plano de Teste
Como boa prática, é sempre uma boa ideia validar os resultados retornados antes de executar o teste real de carga.
- Use o listener View Results Tree para ajudar na validação
- O Plano de Teste inclui um View Results Tree Listener mas ele está desabilitado por padrão
- Habilite-o para visualizar os resultados
- Pelo GUI, inicie o teste
Transações
- Selecione uma das Transações "HFS"
- Os resultados devem se assemelhar ao seguinte:
- Neste exemplo, as transações listadas acima: HFS (mapscale: 72224), HFS (mapscale: 36112), e HFS (mapscale: 144448) todas foram concluídas com sucesso
- O resultado do Sampler lista alguns detalhes adicionais
- Embora cada Transação tenha enviado uma requisição HTTP por extensão da consulta da feição, o teste JMeter está contando o Sampler como parte da operação
- Os JSR223 Samplers adicionam muito pouca sobrecarga à Transação embora dobrem o número de amostras, isso é apenas um detalhe a ser observado
- Dê uma olhada rápida no Tamanho em bytes
- Neste exemplo, o Tamanho da Transação foi quase 65KB o que sugere que alguns dados estavam sendo retornados e as respostas não estavam "vazias"
Requisições
- Expanda uma das Transações "HFS"
- Selecione uma das requisições https
- Os resultados devem se assemelhar ao seguinte:
- Neste exemplo, a requisição select foi concluída com sucesso
- Dê uma olhada rápida no Tamanho em bytes
- Neste exemplo, o Tamanho da Requisição foi cerca de 5KB o que sugere que alguns dados estavam sendo retornados e as respostas não estavam "vazias" (ex.: 1500 bytes)
- O ContentType também é importante
- De acordo com os parâmetros no Plano de Teste, o formato solicitado é pbf que retorna application/x-protobuf
- Solicitar protocol buffers é uma boa prática pois otimiza a carga útil
- O formato resultante é binário e não pode ser facilmente visualizado sem ajuda adicional que não é abordada neste Artigo
Nota: Serviços de feição (incluindo serviços hospedados) são renderizados no cliente (não no servidor como export map). Embora Apache JMeter seja um cliente (de teste), ele não renderiza as respostas do servidor via JavaScript como um navegador web.
Execução do Teste
O teste de carga deve ser executado da mesma forma que um típico Plano de Teste do JMeter.
Veja o script runMe.bat incluído no projeto roads_hfs1.zip como exemplo de como executar um teste conforme recomendado pela equipe Apache JMeter.
- O script runMe.bat contém uma variável jmeterbin que precisará ser configurada com o valor apropriado para seu ambiente
Nota: É sempre recomendado coordenar o horário e duração do início do teste de carga com as pessoas apropriadas. Isso garante impacto mínimo aos usuários e outros colegas que também possam precisar usar o ArcGIS Enterprise Site. Além disso, isso ajuda a prevenir system noise de outras atividades e usos que podem "poluir" os resultados do teste.
Relatório do JMeter
Curvas de Throughput
- O Relatório gerado automaticamente pelo JMeter pode fornecer insights sobre o throughput das transações HFS sob carga
- Transações não-HFS foram filtradas manualmente
- Neste caso, o pico máximo para as operações HFS foi cerca de 16.5 transações/segundo
- Como havia 3 transações HFS, isso equivale a quase 50 transações/segundo (ou 178.200 transações/hora)
Nota: Cada uma das Transações HFS naturalmente terá throughput similar pois sua respectiva execução no teste teve peso igual
Curvas de Performance
- O Relatório gerado automaticamente pelo JMeter pode fornecer insights sobre a performance das transações HFS sob carga
- Transações não-HFS foram filtradas manualmente
neste caso, as transações HFS para todas as escalas foram sub-segundo (menos de 1 segundo)- Mesmo no final do teste, sob a carga mais pesada, o tempo médio de resposta foi inferior a 225 ms ou 0,225 segundos
Considerações Finais
Existem outras maneiras de testar consultas de serviço de camada de recurso hospedada, como por meio do tráfego capturado de um navegador da web enquanto interage com o endpoint ou aplicativo. Isso produziria uma lista das URLs do serviço que poderiam ser traduzidas em um teste. No entanto, uma abordagem programática como a listada neste Artigo oferece uma estratégia para testar uma ampla área espacial do serviço cobrindo muito mais extensões do que pode ser feito praticamente com a abordagem de tráfego capturado.
A abordagem programática também é mais fácil de manter, pois o tamanho do Plano de Teste é muito menor. Para colocar isso em perspectiva, o teste JMeter contido neste Artigo continha apenas 3 Requisições HTTP (uma para cada escala do mapa).
Apache JMeter lançado sob a Apache License 2.0. Apache, Apache JMeter, JMeter, a pena Apache e o logotipo Apache JMeter são marcas registradas da Apache Software Foundation.
