Desempenho: Desafios e Estratégias
O ArcGIS Enterprise fornece uma plataforma robusta e escalável para fornecer recursos GIS aos usuários por meio de serviços e aplicações web. No entanto, às vezes, as implantações podem apresentar desempenho lento nos pontos finais dos recursos publicados.
Como o ArcGIS é muito versátil, podem existir diferentes maneiras, configurações e opções ao disponibilizar esses recursos para consumo.
Obter um bom desempenho nem sempre é tão fácil e direto quanto simplesmente ativar uma configuração "fast = true".
O que pode ser um recurso útil para alguns administradores pode ser uma configuração que, embora útil, pode interferir no desempenho para outros.
No mundo real, o desempenho é frequentemente uma função de vários itens e configurações. Ter estratégias para entender e superar os mais comuns pode ajudar a colocar a implantação no caminho para alcançar um desempenho mais rápido.
O que é Desempenho?
Desempenho é uma descrição de quão rápido (ou lento) um servidor ou serviço opera para uma função específica de interesse. Quanto tempo leva para um serviço do ArcGIS Server completar uma operação como query, applyEdit ou export e então enviar a resposta de volta ao cliente que a solicitou seria um exemplo de desempenho.
Essa duração é medida em segundos ou milissegundos e é comumente referida como o tempo de resposta.
Embora chamado de "tempo de resposta", existem várias etapas importantes que compõem o tempo total que um cliente como um navegador web ou ArcGIS Pro passa esperando por um recurso solicitado do servidor:
- Consulta DNS do nome do host do servidor
- Aperto de mão SSL entre cliente e servidor
- Conexão TCP/IP entre cliente e servidor
- Envio da solicitação ao servidor
- Processamento da solicitação pelo servidor
- Recebimento da resposta do servidor
- Para respostas grandes, o Tempo até o primeiro byte (ou TTFB) pode ser usado para medir o tempo de resposta
Tipicamente, a maior parte do tempo é gasto em 4.1. É aqui que o servidor está trabalhando na resposta.
Este Artigo da Comunidade explorará áreas que podem impactar essa parte do tempo de resposta.
Por que o Desempenho é Importante?
Simplificando: quanto mais rápido o desempenho, menor o tempo de resposta.
Quanto menor o tempo de resposta, mais solicitações o servidor pode suportar ao mesmo tempo.
Essa maior simultaneidade de solicitações se traduz em maior escalabilidade, o que significa suporte para mais usuários.
O desempenho é medido como uma unidade de tempo necessária para completar uma única operação por vez (por exemplo, 0,238 segundos para executar uma solicitação de consulta de feição).
Escalabilidade, por outro lado, é frequentemente medida como transações ou operações ao longo do tempo (por exemplo, solicitações/segundo ou operações/hora).
Quando falamos em obter melhor, mais rápido ou "mais" desempenho, isso implica alcançar tempos de resposta menores. Por outro lado, melhor escalabilidade implica atingir uma taxa maior de throughput (por exemplo, mais operações/hora).
Nota: Claro, para obter melhor desempenho ou throughput, as operações de interesse precisam ser executadas adequadamente e responder com o conteúdo esperado (por exemplo, imagem do mapa, dados json ou pbf). Mensagens de erro, por exemplo, podem ser uma resposta rápida e simples cuja entrega pode alcançar alta taxa de throughput. Como testadores e analistas, esse tipo de throughput não é o que buscamos... estamos interessados no throughput das solicitações bem-sucedidas.
O que é Desempenho Aceitável?
Depende.
Os critérios ou requisitos para classificar um item como tendo desempenho rápido (ou lento) podem variar muito dependendo da organização, dos serviços publicados e das operações esperadas que os usuários irão chamar.
Não é incomum ter diferentes metas de tempo de resposta para funções do ArcGIS Server ou fluxos de trabalho da aplicação do usuário (várias solicitações agrupadas para representar uma operação).
Qualquer número de segundos pode ser aceitável como requisito, mas tenha em mente que pode ser necessário mais hardware assim como ajustes e estratégias mais extensas (este Artigo) para alcançar metas agressivas.
Como o Desempenho é Medido?
O tempo de resposta é a métrica chave para determinar se o desempenho está atendendo ou permanecendo dentro ou abaixo de um requisito alvo.
Estratégias comuns para medir são:
- Interação com usuário único
- Através do navegador web ou ArcGIS Pro
- Este é o lugar mais fácil para começar
- Se ainda não houver entendimento sobre desempenho, comece aqui
- Análise estatística de grandes volumes de tempos de resposta
- Através de ferramentas de análise de logs, página Estatísticas do ArcGIS Server Manager ou outras utilidades de observabilidade
- Essas abordagens têm a vantagem de analisar solicitações reais que os usuários já executaram contra a implantação
- Isto será discutido com mais profundidade posteriormente no Artigo
- Teste de Carga
- Pode fornecer entendimento sobre desempenho e escalabilidade
- Mais demorado para configurar
- Existem recursos online para começar
Ao analisar logs ou executar testes, uma estratégia comum é aproveitar as estatísticas para decompor grandes quantidades de tempos de resposta. A média e os percentis 90º (ou 95º), o mínimo e máximo ajudam a fornecer uma compreensão do desempenho que o usuário pode ter experimentado.
Capturando Tempos de Resposta -- Navegador Web
A forma como os tempos de resposta são capturados através da interação com usuário único é um tópico divertido para discussão.
A abordagem mais fácil para capturar tempos de resposta das solicitações REST a partir de uma aplicação web é com a funcionalidade "ferramentas do desenvolvedor" do navegador. Todos os principais navegadores oferecem alguma visualização das solicitações, respostas e tempos enviados e recebidos. Essa duração pode dar uma ideia da rapidez com que uma solicitação ou operação (potencialmente múltiplas solicitações) foi realizada. Decisões podem então ser tomadas se isso é aceitável ou precisa ser melhorado.
Capturando Tempos de Resposta -- ArcGIS Pro
Embora o ArcGIS Pro também se comunique com o ArcGIS Enterprise via REST, ele não possui um equivalente embutido das ferramentas do desenvolvedor. Para capturar tempos de resposta, você precisará de um depurador HTTP separado. Existem muitos disponíveis; uma escolha popular é o Fiddler.
Com o Fiddler instalado na mesma máquina que o ArcGIS Pro, ele pode ser configurado para interceptar o tráfego. Parâmetros da solicitação, conteúdo da resposta e tempos podem ser capturados e examinados da mesma forma.
São Necessárias Metas para Melhorar o Desempenho?
Absolutamente não. Administradores GIS sempre podem analisar, ajustar e aplicar melhores práticas ao sistema mesmo sem requisitos oficiais de desempenho estabelecidos.
No entanto, é altamente recomendável entender qual desempenho seu sistema está entregando inicialmente (por exemplo, esses são tipicamente chamados números base do tempo de resposta) antes que ajustes sejam feitos. Dessa forma você pode determinar se as mudanças aplicadas estão tendo efeito positivo.
Desafios Comuns de Desempenho e Estratégias Potenciais
Tipos e Instâncias do Pool de Serviços
< DIV >< P >< SPAN > Uma das áreas mais frequentes onde administradores ArcGIS encontram desafios relacionados ao desempenho é definir o número apropriado de instâncias para serviços
dedi cados . Mas primeiro , vamos revisar os diferentes tipos . & nbsp ;
Existem 3 tipos d e serviço , cada u m com suas próprias forças . </ P ></ DIV >< UL >< LI >< STRONG > Dedicado </ STRONG ></ LI >< LI >< STRONG > Hospedado </ STRONG ></ LI >< LI >< STRONG > Compartilhado </ STRONG ></ LI ></ UL >< DIV >< P > Como Administrador GIS , é importante poder identificar o tipo d a instância p ara u m serviço.<\/P>Isso pode ser facilmente visualizado dentro do ArcGIS Server Manager, em Gerenciar Serviços:<\/DIV>
<\/DIV>
<\/span><\/P><\/DIV>Selecionando o Tipo Apropriado<\/SPAN><\/H3>Escolher um tipo de serviço dedicado é ideal quando se deseja obter o máximo controle de desempenho e escalabilidade<\/U>. Com este tipo, o administrador pode:<\/P><\/DIV>Definir o número máximo de instâncias para o número de núcleos de CPU para aproveitar ao máximo a capacidade de processamento disponível na máquina ArcGIS Server (via o máximo)<\/SPAN><\/LI>Conservar memória quando ocioso (via o mínimo)<\/SPAN><\/LI>Ajustar para desempenho previsível definindo o mínimo e o máximo com o mesmo valor<\/SPAN><\/LI><\/UL>Serviços dedicados são ideais para serviços muito solicitados ou serviços onde o desempenho é primordial.<\/P>Serviços hospedados não utilizam instâncias ArcSOC e escalam automaticamente conforme necessário. No entanto, as capacidades ArcGIS disponíveis para ele (Hospedado) são limitadas, pois é usado principalmente com consultas de feição.<\/P>Serviços compartilhados são ótimos para acessar itens que são solicitados com menos frequência. Normalmente, eles têm mais capacidades ArcGIS disponíveis, mas nem toda funcionalidade ArcGIS está disponível (por exemplo, versionamento ramificado). Um pool de instâncias compartilhadas é o tipo padrão ao publicar um serviço com ArcGIS Pro<\/U>.<\/P>Nota: É importante reiterar que se o tipo de serviço selecionado for dedicado, o número (mínimo e máximo) de instâncias deve ser avaliado para garantir que estejam otimizados. O padrão ao publicar no ArcGIS Pro é usar no máximo 2 (instâncias). Isso pode ser muito baixo e inadequado para serviços onde desempenho/escalabilidade são importantes.<\/STRONG><\/FONT> <\/SPAN><\/P><\/DIV>Foque no Mapa<\/H2>Otimizar o mapa não é uma estratégia nova, mas uma relativamente fácil de seguir para obter melhor desempenho da sua implantação.
Quando o mapa está focado em seu propósito principal e apresentação, o sistema não precisa fazer trabalho desnecessário. Lembre-se, a web é uma plataforma multiusuário. Tornar a exibição dos dados dinâmicos o mais simplificada possível é fundamental para um bom desempenho (e escalabilidade). Com potencialmente muitas solicitações ocorrendo ao mesmo tempo, o conteúdo compartilhado precisa ser o mais eficiente possível.<\/P>
<\/span>Estrategias do Mapa<\/SPAN><\/H3>Escolha uma Extensão Padrão Ótima<\/SPAN>Se o mapa está fornecendo dados sobre Los Angeles, a extensão padrão não<\/EM> deve mostrar toda a Califórnia<\/LI>Se muitas escalas diferentes do mapa forem necessárias, use dependências de escala e generalização para limitar os detalhes para quando você mais precisar (por exemplo, as maiores escalas)<\/LI><\/UL><\/LI>Remova camadas desnecessáriasConsidere remover camadas de dados que são agradáveis de terPelo menos, desmarque-as e permita que o usuário opte por ativá-las<\/LI><\/UL><\/LI><\/UL><\/LI>Limite propositalmente o que os usuários podem fazer com um serviço<\/LI>Evite projetar em tempo realUse o mesmo sistema de coordenadas para quadro de dados e dados<\/LI><\/UL><\/LI>Consultas de definiçãoGaranta que índices estejam presentes se lógica de comparação for aplicada às colunas de atributos <\/LI><\/UL><\/LI><\/UL>Nota: "Focar no mapa" aplica-se a mapas, apps e serviços<\/FONT><\/STRONG><\/DIV>Lançamentos de Software<\/H2>Uma versão particular do ArcGIS Enterprise (e suas soluções relacionadas) pode ter alguns patches após seu lançamento base inicial. Esses patches podem oferecer melhorias de desempenho assim como correções de funcionalidade e segurança. <\/P>É altamente recomendado verificar periodicamente o Site Esri Patches and Updates<\/A> ou executar a ferramenta "Check for ArcGIS Enterprise Updates". Então, aplique as atualizações no momento apropriado.<\/P>
Contenção e Expansão de Recursos<\/H2>Há momentos em que as melhores práticas e estratégias para desempenho são aplicadas, mas tempos de resposta mais baixos e maior escalabilidade ainda são necessários. Talvez o hardware atual executando ArcGIS Server esteja simplesmente esgotado onde a potência de processamento ou memória se tornaram gargalos para melhorar a experiência do usuário.<\/P>Para tais situações, você precisa considerar expansão e/ou atualização do hardware.<\/DIV>
Escalabilidade<\/SPAN>
Para os níveis ArcGIS Server e ArcGIS Web Adaptor da implantação, você geralmente< \/STRONG >< \/EM > tem as seguintes opções para melhorar a escalabilidade< \/EM > usando hardware: < \/SPAN >< \/DIV >Escalar verticalmente< \/STRONG >Adicionar mais recursos à máquina existente (por exemplo, núcleos adicionais de processamento)< \/SPAN >Memória adicional também pode ajudar na escalabilidade permitindo que a implantação tenha mais instâncias ArcSOC rodando simultaneamente< \/SPAN > < \/SPAN >< \/LI >< \/UL >< \/LI >Ideal para implantações como: cloud, virtualização, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >Escalar horizontalmente< \/STRONG >Adicionar mais máquinas com capacidade igual de recursos< \/SPAN >< \/LI >Ideal para implantações como: on-premise, cloud, virtualização, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >Desempenho< \/SPAN >Para melhorar o desempenho< \/EM > com hardware, normalmente há apenas uma opção:< \/SPAN >Obter núcleos de processamento mais rápidos< \/STRONG > Ideal para implantações como: cloud, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >A configuração de paginação do sistema também pode impactar a escalabilidade mesmo quando recursos amplos de memória foram adicionados ao sistema. Embora esta seja uma configuração do software do sistema operacional e não hardware, ela pode desempenhar um papel crucial na execução de muitas instâncias ArcSOC simultâneas. Certifique-se de configurá-la adequadamente para lidar com uma carga de trabalho com muitas instâncias ou instâncias com grande uso de memória.< \/FONT >Podem haver situações onde o desempenho é limitado e parece estar preso à CPU (por exemplo, um gargalo devido à potência limitada de processamento). Uma inspeção mais detalhada pode revelar que o "culpado" são uma ou mais consultas lentas que já eram subótimas ou uma operação cara chamada com muita frequência (através de tarefas administrativas periódicas). Nesse caso, pode ser mais eficaz tratar as consultas "ruins" para melhorar desempenho e escalabilidade.< \/FONT >Nota: Essas estratégias de expansão são para superar limitações gerais< \/EM >de processamento e memória. Mas recursos de disco e rede (largura de banda, latência) também podem ser gargalos. Para alguns ambientes, esses podem ser mais complicados de expandir exigindo etapas adicionais para atualização.< \/STRONG >Uma Abordagem Geral para Escalonamento< \/FONT >
<\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/> id="toc-hId-333806091">Observabilidade "Quantificar ArcGIS" é uma ótima estratégia... um favorito pessoal. Define quais recursos estavam sendo solicitados e quão rápidas foram as respostas para atender a essas solicitações. É importante para obter uma compreensão do desempenho geral do sistema. Se a utilização dos recursos do sistema também puder ser capturada, a análise pode ser ainda mais aprimorada.
Existem muitas utilidades disponíveis para examinar periodicamente seu sistema. Algumas ferramentas podem ler os logs de acesso e focar principalmente no desempenho estatístico das solicitações feitas pelos usuários. Outras podem consultar a página de estatísticas do Server e capturar a utilização da CPU (do ArcGIS Server ou do banco de dados) durante esse período de tempo. Qual abordagem é a melhor? Se a observabilidade atualmente não está ocorrendo, então provavelmente qualquer uma delas seria uma boa adição. Todas ajudam a fornecer algum tipo de insight sobre o desempenho e a saúde da implantação.
Uma vez que a análise tenha sido conduzida para uma implantação, relatórios podem ser tipicamente gerados que destacam quais serviços de mapa podem ser de interesse devido a:
- Os tempos de resposta observados serem mais lentos do que o esperado
- O número de solicitações emitidas para o recurso
- Tanto o tempo de resposta quanto o número de solicitações
Para um Site ArcGIS com muitos serviços, saber quais são estatisticamente lentos ou estão consumindo mais recursos ajuda a focar os esforços de ajuste. Com tais relatórios, o administrador GIS transformou dados em informações valiosas e agora está melhor informado para tomar decisões para melhorar a experiência do usuário. Dito isso, examinar logs e estatísticas é apenas uma fatia (importante) da análise.
Um Desafio com Ferramentas Comuns de Observabilidade
Muitas ferramentas para observabilidade e monitoramento do sistema focam a análise nas solicitações e respostas dos serviços. Esta é uma boa abordagem e definitivamente auxilia os administradores na quantificação do ArcGIS, mas pode ter uma limitação. A limitação pode aparecer com a suposição de que um serviço de mapa lento pode ser "consertado" simplesmente adicionando núcleos de processamento. Mais núcleos podem melhorar alguns aspectos da situação, mas é recomendado que o serviço seja examinado (ou até reexaminado) em mais profundidade antes que mais recursos sejam obtidos.
Isto remete à seção "Focar o Mapa", por exemplo:
- Garantir que os dados para o serviço não estejam sendo exibidos em escalas muito pequenas
- Evitar consultas subótimas
A análise detalhada das consultas pode ajudar a mostrar a ocorrência desses comportamentos que podem ficar mascarados com relatórios gerais do serviço. No entanto, enquanto a decomposição dos parâmetros da solicitação do serviço e das consultas subjacentes pode melhorar a análise, isso pode adicionar complexidade ao próprio relatório (por exemplo, mais tempo para executar, mais visualizações do que observar, o entendimento das visualizações). Além disso, nem todas as ferramentas de observabilidade realizam esse tipo de inspeção.
Alguns esforços recentes que estão ganhando força tentam enfrentar essa questão. Eles são baseados em uma abordagem ascendente de análise onde o ponto inicial são as próprias consultas do banco de dados subjacente através de um mecanismo conhecido como "query datastore". A análise do query datastore é poderosa e não impacta o desempenho do banco de dados como um trace pode, mas requer algum conhecimento das próprias consultas e seu propósito. Espere esse tipo de capacidade analítica no futuro para ajudar a obter o máximo das suas ferramentas de observabilidade.
Conclusão
Não existe um único item para ajustar facilmente para aumentar o desempenho e escalabilidade de um Site ArcGIS Enterprise. No entanto, este Artigo lista algumas estratégias comuns que podem ser aplicadas juntas para melhorá-lo. Também é importante entender que esses são itens que devem ser revisitados periodicamente e agidos conforme necessário. Os hábitos dos usuários mudam com o tempo assim como a popularidade de uma aplicação web ou serviço. Recursos que foram atribuídos a um serviço específico podem ser reavaliados ou reduzidos para abrir espaço para o próximo item em destaque no seu Site.
A análise de desempenho do ArcGIS pode ser divertida, mas também é um esforço contínuo para manter a melhor experiência do usuário.
Atribuição
Recurso: Arquivo:Grayson_running_the_4x100.jpg
Descrição: Inglês: Grayson correndo a primeira etapa do 4x100 no convite Tigered 2010
Autor: Graysonbay
Criado: 02:02, 29 de novembro de 2010
Licença: Este arquivo está licenciado sob a Creative Commons Atribuição 3.0 Unported licença
Recurso: Arquivo:Kurvimeter_1_fcm.jpg
Autor: Frank C. Mfcller, Baden-Baden
Licença: Este arquivo está licenciado sob a Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional licença.
Recurso: Arquivo:My_Opera_Server.jpg
Descrição: Um servidor usado para o My Home
Autor: William Viker, william.viker@gmail.com (c) 2006
Licença: O detentor dos direitos autorais deste arquivo permite que qualquer pessoa use-o para qualquer propósito, desde que o detentor dos direitos autorais seja devidamente atribuído. Redistribuição, trabalho derivado, uso comercial e todos os outros usos são permitidos.
Recurso: Arquivo:Samsung-1GB-DDR2-Laptop-RAM.jpg
Descrição: Um pente de 1 gigabyte DDR2 667 MHz (PC2-5300) RAM para laptop, fabricado pela Samsung e retirado de um laptop MacBook 2007.
Autor: Evan-Amos
Criado: 1º de agosto de 2018
Licença: Domínio Público
