nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Usando Dados de Domínio Público para Avaliar um Serviço de Mapa ArcGIS Enterprise (Intermediário)

AaronLopez

Escolhendo uma Capacidade do ArcGIS Enterprise para Benchmarking

Como o sistema de software fundamental para GIS, o ArcGIS Enterprise realiza muitas funções como mapeamento e visualização, análises. Dentre essa ampla gama de capacidades e funções, não existe um único teste que possa representar toda a sua habilidade.

No entanto, se uma função fosse usada como benchmark para testar uma implantação do ArcGIS Enterprise, um forte argumento pode ser feito para a função de exportação do serviço de mapa. A exportação de mapa pode ser chamada facilmente e programaticamente em um Plano de Teste Apache JMeter variando as extensões espaciais das requisições a partir de arquivos CSV em várias escalas de mapa. Isso se traduz em apenas uma requisição para cada transação de escala de mapa, o que ajuda a manter o teste simples e fácil de manter. Juntamente com o fato de que a função de exportação está disponível desde a versão 9.3, torna-se uma operação comprovada e confiável para benchmarking.

O que é um Benchmark de um Serviço de Mapa?

Testadores e administradores GIS frequentemente são encarregados de entender as diferenças na taxa de transferência entre dois sistemas ou o mesmo sistema após alguma modificação no ambiente. Em tais cenários, um benchmark é o processo de realizar um teste de carga para atuar como um padrão pelo qual múltiplas coisas podem ser comparadas entre si.

Com respeito ao GIS, esse teste de carga seria um Plano de Teste Apache JMeter executando um teste de carga escalonada contra um serviço de mapa do ArcGIS Enterprise para entender a maior taxa de throughput (transações/seg ou requisições/seg) que pode ser alcançada pela implantação dado um estado ou configuração particular. Essa taxa também é conhecida como throughput máximo. No throughput máximo, entender o desempenho (tempo de resposta da transação ou requisição) também seria crítico para medir.

Conjunto de Dados Benchmark

Qualquer conjunto de dados pode ser usado para um benchmark desde que seja mantido constante onde mudanças como adições, atualizações, exclusões e versões da classe de feição não sejam feitas. Essa consistência ajuda a criar um "padrão" confiável já que é um alvo fixo. Os dados do teste podem ser privados (ex: proprietários) ou baseados em domínio público.

O que são Dados em Domínio Público?

De modo geral, dados em domínio público seriam quaisquer conjuntos raster ou vetoriais que são gratuitos para download e uso. Existem muitos conjuntos de dados em domínio público disponíveis (e potencialmente diferentes licenças que os definem). Os dados usados neste Artigo são Feitos com Natural Earth e fornecidos através da licença Creative Commons (CC0).

Por Que Usar Dados em Domínio Público?

Uma das características que fazem um bom benchmark é construir um teste para que outros possam repetir o mesmo teste que você fez. Dados em domínio público são uma boa escolha nesse aspecto pois promovem um padrão de teste e uma medida confiável para desempenho e escalabilidade.

SampleWorldCities vs Natural Earth

Enquanto a inclusão do SampleWorldCities pelo ArcGIS Server através da sua instalação ajuda a tornar o conjunto de dados ubíquo e bom para exemplos e tutoriais, seu tamanho extremamente pequeno não o torna ideal para usar no benchmarking de um serviço de mapa.

Os conjuntos Natural Earth, por outro lado, fornecem algum detalhe decente do mapa (em escalas menores) cobrindo todo o mundo. Além disso, isso pode ser alcançado com uma pegada fácil em termos de tamanho no disco, o que ajuda a torná-lo mais prático para compartilhar, baixar e usar.

O Conjunto Benchmark Natural Earth

Baixe o conjunto benchmark aqui
- Os dados são um subconjunto do Natural_Earth_quick_start.zip e incluem um MXD modificado para ArcMap 10.8.1 e projeto ArcGIS Pro 2.8.
  - Qualquer um pode ser usado para publicar um serviço de mapa no ArcGIS Enterprise.
O subconjunto Natural Earth deve parecer similar ao seguinte quando aberto no ArcGIS Pro (ou ArcMap)

Arquitetura da Implantação

A arquitetura é detalhe importante de um benchmark. Os seguintes são todos componentes importantes da arquitetura do benchmark que impactam o teste:

Existe um Web Adaptor?
A autenticação foi envolvida ou o serviço foi disponibilizado para todos
- Autenticação Portal for ArcGIS
- Autenticação token do ArcGIS Server
- Disponível para todos
Quantas máquinas participaram do Site ArcGIS?
Detalhes do processador
- Modelo e arquitetura do processador
- Número de núcleos CPU para cada servidor (incluindo a estação cliente do teste)
- Físico, virtual ou nuvem
Detalhes da Memória Física
- Total da memória do sistema
Velocidade da rede
Versão do ArcGIS Enterprise
Versão do Sistema Operacional

Nota: Recomenda-se anotar os detalhes da arquitetura da implantação. Salvar essa informação junto com os resultados dos testes pode ajudar a dar contexto adequado e significado à análise ou conclusões.

Os resultados listados neste teste benchmark foram executados contra a seguinte arquitetura ambiental:

ArcGIS Server (10.9 Final)
- Dell PowerEdge R640
  - SPECint_rate_base2006
  - HyperThreading desativado
  - 128GB RAM
- Windows Server 2019
- Rede 10G
ArcGIS Web Adaptor (10.9 Final)
- Dell PowerEdge R440

Cliente do Teste

Apache JMeter 5.4.1
Dell PowerEdge R640

6 CPUs virtuais
16GB RAM

Windows Server 2019
Rede 10G

Tipo e Localização da Fonte dos Dados

Usar tanto geodatabase arquivo quanto geodatabase empresarial para armazenar dados no teste benchmark é aceitável. R egardless of which is used, the detail of the data source is an important property of the environment which should be noted.

Nota: Recomenda-se anotar o tipo da fonte dos dados. Salvar essa informação junto com os resultados dos testes pode ajudar a dar contexto adequado e significado à análise ou conclusões.

Quanto à localização, usar uma geodatabase arquivo remota em vez de uma geodatabase arquivo local pode ser necessário se a implantação tiver vários servidores que compõem o ArcGIS Enterprise Site. Em qualquer dos casos, remoto ou local, a localização da fonte de dados também é um detalhe importante do ambiente de teste que deve ser anotado.<\/SPAN><\/P>Nota: Recomenda-se anotar a localização da fonte de dados. Salvar essa informação junto com os resultados do teste pode ajudar a dar contexto e significado adequados à análise ou conclusões.<\/STRONG><\/FONT><\/P>Tipo de Serviço e Número de Instâncias<\/FONT><\/H2>Para os serviços de mapa ArcGIS mais amplamente usados em um Site, recomenda-se publicar o recurso como uma instância Dedicated em vez de Shared. Embora ambos os tipos possam escalar para utilizar totalmente o hardware disponível, uma instância de serviço Dedicated possui recursos nos bastidores dedicados a ela, o que a torna uma escolha ideal para um teste benchmark.<\/FONT><\/P>Para desempenho previsível, recomenda-se definir o número Mínimo e Máximo de instâncias para o tipo de instância Dedicated igual ao número de núcleos de CPU da máquina ArcGIS Server.<\/FONT><\/P>Nota: Recomenda-se anotar o tipo de serviço e o número de instâncias. Salvar essa informação junto com os resultados do teste pode ajudar a dar contexto e significado adequados à análise ou conclusões.<\/STRONG><\/FONT><\/P>As Opções de Solicitação em um Teste Benchmark Importam?<\/H2>Absolutamente! Usar um conjunto de dados comum e a função export map não é suficiente para estabelecer um benchmark confiável. A operação export é extremamente versátil, mas através dessa flexibilidade uma imagem pode ser gerada por meio de várias opções diferentes de entrada.<\/P>Um teste de carga que envia solicitações ao serviço de mapa consistentemente é importante para estabelecer um benchmark confiável. O teste pode solicitar um formato de imagem BMP em vez de PNG ou pedir que os dados estejam em uma referência espacial diferente da padrão 4326? Sim, mas alterar tais opções pode impactar o desempenho e escalabilidade do teste, portanto recomenda-se deixar as configurações deste Plano de Teste como estão.<\/P>O Plano de Teste Benchmark do Serviço de Mapa <\/H1>Para baixar o Plano de Teste Apache JMeter usado neste Artigo veja: <\/SPAN>naturalearth1.zip<\/A> <\/STRONG>

Este Plano de Teste é amplamente baseado no projeto SampleWorldCities do

artigo anterior<\/A><\/LI><\/UL><\/LI><\/UL>
Baixar e 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<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P> A composição da solicitação (uma para cada uma das 5 escalas de mapa testadas) deve ser semelhante ao seguinte:<\/LI><\/UL><\/span><\/P>

Configuração do Thread Group<\/H2>O Thread Group define as características da carga incremental do teste e desempenha um papel importante. Para um export map, o Número máximo de Threads para o teste tem uma relação próxima com o número máximo de núcleos CPU do ArcGIS Server (e similarmente, o número máximo de instâncias do serviço). Configurar os threads do teste para exceder o número de núcleos ajuda a garantir que pressão suficiente seja aplicada para utilizar totalmente os recursos da CPU do servidor. A partir daí, deve-se observar o pico de throughput, que é um objetivo principal do teste benchmark.<\/P>Nota: Nem todos os conjuntos de dados testados podem mostrar o respectivo serviço utilizando totalmente a CPU da camada ArcGIS Server. Nesses casos, é necessário solucionar problemas adicionais para entender onde está o gargalo que limita a escalabilidade do fluxo de trabalho dado.<\/STRONG><\/FONT><\/P>Como regra geral, configure a carga máxima incremental para ser 25% -- 60% maior que o número dos núcleos CPU do servidorComo visto abaixo, o Plano de Teste está configurado para rodar por 1 hora e alcançar uma carga máxima incremental de 40 threads concorrentesIsso iniciaria o benchmark com 1 thread e adicionaria um thread adicional a cada 90 segundos<\/LI>Este benchmark foi projetado para testar uma implantação ArcGIS Server rodando em 24 núcleos físicos da CPU <\/LI>Ajuste conforme necessário, nem todo ArcGIS Server rodará em 24 núcleos físicos e os valores máximos incrementais podem ser muito altos para sua implantação<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>

Nota: Recomenda-se anotar os detalhes da configuração da carga incremental. Salvar essa informação junto com os resultados do teste pode ajudar a dar contexto e significado adequados à análise ou conclusões.<\strong>
Execução do Teste Benchmark
O benchmark deve ser executado da mesma forma que um Plano de Teste típico do JMeter.
Veja o script runMe.bat incluído no projeto naturalearth1.zip como exemplo sobre como executar um teste recomendado pela equipe Apache JMeter.

Nota: Sempre recomenda-se 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 ruído do sistema proveniente de outras atividades e usos que podem "poluir" os resultados do teste.<\strong>
Resultados e Análise
Uma vez que o teste de carga tenha sido concluído, o runME.bat instrui o Apache JMeter a gerar automaticamente um relatório para auxiliar na análise dos resultados.
Pode haver artigos inteiros e recursos na internet dedicados exclusivamente à análise dos componentes dos resultados de um teste de carga. Portanto, no interesse em manter as coisas simples, nosso foco será olhar as métricas throughput das solicitações (solicitações/segundo) e desempenho das solicitações (segundos) no relatório.
Os diagramas abaixo ilustram as tendências ideais desses dois itens no teste ao longo do tempo.
Curva Ideal de Throughput

Iidealmente, a curva throughput terá a forma da linha laranja acima. O ponto onde a curva atinge pico e começa a se estabilizar indica que o sistema alcançou seu nível máximo de throughput (devido a um gargalo no hardware ou software). Esta área do gráfico onde a curva dobra é chamada joelho, e o valor máximo para throughput está neste ponto.

A linha azul representa a carga incremental crescente do teste.

Curva Ideal de Desempenho

Iidealmente, a curva tempo-resposta terá a forma da linha verde acima. Ela é tomada neste mesmo ponto no teste como throughput máximo.

A linha azul representa a carga incremental crescente do teste.

Relatório JMeter

Incluído no projeto naturalearth1.zip está um relatório Apache JMeter chamado naturalearth1_run1 dentro da pasta reports.

Abrir index.html revelará múltiplos gráficos e tabelas para auxiliar na análise

Curva Real Atualizada Throughput

Do relatório:
- No menu Charts->Throughput, encontra-se o gráfico Hits Per Second onde está plotado throughput das solicitações do teste

Curva de Desempenho Real

Do relatório:
- Em Charts-->Response Times, pode-se encontrar o gráfico Time Vs Threads onde o desempenho das requests do teste é plotado
  - Todos os itens exceto "/pvtserver/rest/services/NaturalEarth/MapServer/export" são filtrados (clicando neles na legenda)
  - Como o teste foi construído com cada transaction contendo apenas uma request, a "export request" também representa o desempenho médio da transaction
  - No ponto de throughput máximo, o sistema entrega um desempenho de transaction de cerca de 314ms ou 0,3 segundos

Nota: Uma abordagem diferente para a análise precisará ser adotada para testes de carga contendo transactions com mais de uma request

Comparando os Resultados

Depois que você completar o teste do seu sistema com os dados fornecidos e o Test Plan, você pode comparar os resultados com aqueles listados neste Artigo. Isso pode fornecer uma medida aproximada para equiparar dois sistemas.

Para baixar o Apache JMeter Test Plan usado neste Artigo veja: naturalearth1.zip
Para baixar o subconjunto de dados Natural Earth usado neste Artigo veja: Natural_Earth_Test_Data

Apache JMeter lancado sob a Apache License 2.0. Apache, Apache JMeter, JMeter, a pena Apache e o logo Apache JMeter são marcas registradas da Apache Software Foundation.

Encontre mais publicações marcadas com

Configuration & Integration

Strategy & Planning

Architecture & Security

Comentários

AaronLopez

Actual Performance Curve chart adjusted to show the response time point that corresponds more accurately to the maximum throughput.

ChiefKeefSosa300

hello sir @AaronLopez

i had a problem running this test.

i published the natural earth map as service, name it as NaturalEarth_MIL1.

change the parameter accordingly in jmeter

the result tree showed me this

any help regarding this?

AaronLopez

Hi @ChiefKeefSosa300 (tq),

Would you be able to delete one of the "image/png Validation" elements and try playing the test again?

These validations items are looking to see if the content returned from ArcGIS Server looks like a png image (this is the default image format this test requests). If it does not match a png signature, it fails the request. Failing a request whose response is not expected is a common strategy when you want to know if your test encounters an error.

Aaron

ChiefKeefSosa300

hi sir @AaronLopez,

per your suggestion i disabled the image/png validation and results go green again.

i just wanna ask about this statement:

"A load test that is sending in the requests to the map service consistently is an important for establishing a reliable benchmark. Can the test request a BMP image format instead of a PNG or ask for data to be in a different spatial reference other than the default of 4326? Yes, but changing such options may impact the performance and scalability of the test so it is recommended to leave this Test Plan settings as is."

does this mean my test failed wholly? or my arcgis server doesnt meet the benchmark requirement?

please enlighten me good sir.

thanks again.

AaronLopez

Hi @ChiefKeefSosa300 (tq),

These are really thoughtful questions, thank for asking them!

The statements about changing the output format to BMP or utilizing another the spatial reference are mentioned with respect to the that specific test. But they need more context...

I favor PNGs over BMPs as the former (Portable Network Graphics) is generally much faster to generate than the latter (Bitmap Image). For example, an export map request that creates a PNG is about 87KB. Using a BMP for the same area, the resulting image is around 15MB. The drastic difference in size would impact scalability (as more network bandwidth is required per request). That said, if your application or workflow requires BMP, then that is the way to go and your benchmark should reflect that. There is nothing wrong with using BMP as an image format for a vector data benchmark, but you should get more throughput by using PNG.

As for the spatial reference, this test used bounding boxes in a geographic coordinate system of "WGS 1984" (WKID 4326) because that is what the data (and published service) was originally in. Of course, there are many different spatial references. The goal when possible, is to try to avoid projecting-on-the-fly. In other words, if the data (and service) are in "WGS 1984" and you ask for "NAD27" (using the appropriate NAD27 bounding box), ArcGIS Server should appropriately fulfil the request. However, while very convenient, this transformation between coordinate systems comes at a performance cost. If you use this test and data as a benchmark, "WGS 1984" (WKID 4326) are an optimal choice. But, if you are wanting to build a benchmark test against your data that is in another coordinate system, I would use bounding boxes in that coordinate system to ensure you can get the best performance.

So to conclude, does using BMP or another coordinate system fail the test, not at all. Performance would be impacted, but you still have a good "measuring stick". As long as the test parameters are known and kept constant between runs over time, you'll have a reliable benchmark regardless of the options used.

Hope this helps.
Aaron

ChiefKeefSosa300

Hi @AaronLopez , thanks for lengthy explanation regarding the test. However,

Im using your test plan to test my arcgis portal but using different map service, the result of the graph is like this (100 users for 5 minutes), is this acceptable result? seems weird and different from yours.

Hits per sec

time vs threads

AaronLopez

Hi @ChiefKeefSosa300,
It depends. You stated you tested a different map service. Does that mean different data than natural
earth?
If yes, each dataset will have its own profile for performance and scalability because the geometry density and complexity can vary. Your data may have more (or less) layers and each layer may have more (or less) attributes.
If no, and you also tested natural earth, then there is a greater chance of seeing a similar profile for performance/scalability, but there are still other variables which can impact response time and throughput like the system architecture (number of machines) and hardware (number of CPUs, CPU speed and memory).

Hope this helps.
Aaron

ChiefKeefSosa300

Hi sir @AaronLopez,

I think i made wrong kind of test because i use the same datasets (project folder) for natural earth but the service name and webserver name is different.

I checked the csv file for each datasets and the home column said "eistsrv05.esri.com_443__Natural_Earth_quick_start_for_ArcMap" so yeah i guess the test result is invalid. But can it be done like this? Use the same datasets for natural earth but different map service? if not how can one acquire its own datasets. Thank you

ChiefKeefSosa300

Hi @AaronLopez ,

i overlooked ur writing about benchmark datasets "Any dataset can be used for a benchmark as long as it is kept constant where changes like feature class additions, updates, deletes and versions are not being made. This consistency helps create a dependable "standard" since it is a non-moving target. The test data can be private (e.g. proprietary) or public domain based."

So I guess my results are real and ok.

Thanks btw

EduardBeneke

Hi @AaronLopez

These tutorials are great. I am looking at utilising them to produce an end-to-end full test suite (including GP, admin tasks, building caches etc).

One of the pain-points we are currently experiencing is with the publishing of a large service, rather than the consumption of the service. Is there a way to publish this dataset using JMeter, then do some performance tests on it, and then delete it? We only see the performance issues through Pro, so need to be able to reproduce that exact process.

AaronLopez

Hi @EduardBeneke,

Yes, you could probably construct a JMeter test to perform the publishing of a large service.
This effort would most likely involve an SD file (a service definition that was previously created from ArcGIS Pro) and some asynchronous JMeter test logic.

However, the publishing of a service is generally considered an administrative function.
While the functionality of publishing a service to work as intended is very important, whether it is slow or fast is not as high a priority (just as long as it still works).

That said, here are some reasons that come to mind that might cause service publishing to have slow performance:

When publishing the service, "copy all data" is selected under the Data and Layer Type section
- While there are very good reasons to do this, one of the considerations is that ArcGIS Pro will need to upload all the data listed in the Contents pane in the project to ArcGIS Enterprise...for large datasets this can take quite awhile
The network between ArcGIS Pro and ArcGIS Enterprise has measurably latency
- If you are publishing from your local machine into the cloud or into a deployment that is physically far away, then performance (of many different operations) could be impacted
  - In this case, try publishing from an ArcGIS Pro that is on the local network of ArcGIS Enterprise
  - Alternatively, if the data resides in an Enterprise Geodatabase, consider publishing with the Reference registered data (Map Image and/or Feature) option
  - As another alternative, consider using the "Save As Offline Service Definition" when attempting to share/publish the service
    - This will create an SD file (which might be large and take some time to create), but you take that hit once. Then when you want to republish, you can do it right from manager over the web.
The PublishingTools.GPServer service is busy publishing other services
- By default, up to 3 instance can run at a time
- I list this as a possibility, but it would probably be unlikely

Hope that helps

Aaron

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.