Compartilhado<\/LI><\/UL>Nota: Tempo de espera é a duração que a solicitação passa em uma "fila" no servidor até que uma instância ArcSOC esteja disponível para começar a trabalhar nela.<\/FONT><\/STRONG><\/P>Serviços de Pool de Instâncias DedicadasServiços dedicados (por exemplo, serviços não hospedados e não compartilhados) são um recurso fundamental do ArcGIS em implantações, pois muitas aplicações dependem das capacidades como geoprocessamento, edição Branch Version e fluxos de trabalho Utility Network (todos os quais requerem serviços dedicados).<\/P>Embora tais serviços sejam muito versáteis e sejam um pilar importante no ArcGIS devido à funcionalidade que fornecem, como administrador GIS você precisa examinar, ajustar e configurar periodicamente o número de instâncias ArcSOC (mínimo e máximo) para aproveitar ao máximo seus recursos disponíveis conforme seu Site e usuários crescem.<\/P>
<\/span><\/P>Para saber mais sobre instâncias ArcSOC veja: <\/SPAN>Entenda as instâncias de serviço<\/P>Limitações dos Serviços de Pool de Instâncias CompartilhadasInstâncias de serviço compartilhadas são ótimas! Elas realmente mudam o jogo para ajudar os administradores a gerenciar a demanda por muitos serviços com recursos finitos. No entanto, suas restrições e requisitos limitam quais capacidades do serviço podem ser usadas com elas. Geoprocessamento, edição Branch Version e Utility Network, por exemplo, atualmente não são suportados através de serviços compartilhados (ou através de serviços hospedados). Isso deixa os serviços dedicados como a única escolha para tal funcionalidade.<\/P>Disponibilidade Configurada da Instância ArcSOC vs Demanda da InstânciaPara serviços que são muito populares, críticos e/ou têm o requisito de rodar sob o tipo de serviço dedicado, entender a configuração ótima da instância é importante por várias razões. Se o número máximo de instâncias ativas for muito alto, memória será desperdiçada (assim como custo). A alocação excessiva de instâncias ArcSOC é um caso importante mas único pois seu impacto não apareceria na análise apenas dos tempos de resposta.<\/P>Alternativamente, ter o máximo muito baixo pode impactar o desempenho (na forma de tempos de resposta mais altos e tempos de espera mais longos) pois os usuários podem frequentemente esperar por uma instância ArcSOC já ocupada ficar livre.<\/P>Claro, definir o mínimo e máximo da instância para valores diferentes também tem um trade-off. Para serviços críticos onde o desempenho é primordial, fazer o usuário esperar enquanto uma instância precisa ser iniciada pode consumir tempo e afetar o desempenho. Portanto, para desempenho previsível em serviços essenciais, recomenda-se definir o número mínimo e máximo de instâncias com o mesmo valor.<\/P>Como listado em Introdução às instâncias de serviço:<\/P>Portanto, é importante para os administradores do ArcGIS Server monitorar o número de instâncias que seu site está executando e limitar as instâncias em execução quando o desempenho for prejudicado pelo uso da memória.<\/STRONG><\/FONT><\/P>Configurar a disponibilidade do serviço (através dos mínimos e máximos das instâncias) e o impacto dessas configurações na demanda do usuário pelo serviço é fundamental para um Site funcionando otimamente. Existe uma relação mútua entre configurar a disponibilidade do serviço (através dos mínimos e máximos das instâncias) e o efeito direto que isso tem nas solicitações recebidas por um serviço dedicado. Embora encontrar a configuração ótima seja uma tarefa contínua, existem algumas ferramentas e recursos para ajudar os administradores a enfrentar esse desafio.<\/P>Relatório de Serviço do ArcGIS Server
<\/STRONG><\/H1>O Relatório de Serviço do ArcGIS Server (introduzido na versão 10.1) é uma daquelas joias menos conhecidas da REST Admin API. Esse recurso pode ajudar a monitorar um Site fornecendo um resumo configurável de todos os serviços em uma pasta. Geralmente é uma solicitação rápida (dependendo do número de serviços na pasta solicitada).<\/P>A seção estatísticas do serviço da instância da resposta retornada é extremamente valiosa pois lista detalhes sobre as instâncias ArcSOC (mínimo, máximo, ocupado) em toda a implantação (por exemplo, o Site do ArcGIS Server).<\/P>Pelo monitoramento periódico desse endpoint, pode-se obter insights atualizados segundo a segundo da configuração da instância do serviço versus a demanda... conforme acontece. Com tais informações, decisões melhores podem ser tomadas sobre otimização dos recursos da máquina e do serviço. Por sua vez, isso pode ajudar a melhorar os tempos de resposta e reduzir os tempos de espera.<\/P>Nota: No ArcGIS Server, estatísticas do serviço da instância e a página Estatísticas no Manager são na verdade recursos diferentes embora forneçam visões similares dos mesmos dados. As estatísticas do serviço fornecem acesso bruto aos valores das instâncias (em todo o Site e por máquina), bem como mais detalhes. A página Estatísticas é uma interface para criar relatórios a partir dessas informações.<\/FONT>
Automatizando a Coleta do Relatório de Serviço com Soccer
Qualquer script, programa ou ferramenta que observe regularmente o endpoint Relatório de Serviço da pasta de interesse seria suficiente. No entanto, se você está procurando uma ferramenta gratuita existente então Soccer é recomendada.<\/P>
(Arc)SOC ScannER ou Soccer é uma utilidade para escanear e ler as estatísticas dos serviços em uma pasta específica do ArcGIS Server. Ela analisa os dados coletados e grava-os em um arquivo CSV para análise pós-captura adicional (por exemplo, criando gráficos em uma planilha para visualizar o uso). Aproveita o recurso Relatório de Serviço da REST Admin no ArcGIS Server para reunir essas informações. O objetivo original do soccer era capturar a saída do endpoint relatório de uma pasta específica no ArcGIS Server e salvar as estatísticas das instâncias ArcSOC (por exemplo, Executando, Ocupado, Máximo etc.) para cada serviço.<\/P>
No momento, soccer é uma utilidade somente linha-de-comando. Está disponível no runtime portátil .NET 6.0 para Windows (win-x64), Linux (linux-x64) e macOS (osx-x64).<\/P>
Para simplicidade, executar soccer requer apenas 3 entradas (outros parâmetros podem ser passados para estender funcionalidades):<\/P>
soccer.exe -s "[https:\/\ArcGISServer\ServerWebAdaptor<\/]" -f [FolderToScan] -t "[PreGeneratedArcGISToken]"<\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/> target="_blank" rel="noopener nofollow noreferrer">https://gisserver.domain.com/server" -f "Gas" -t "APLeyWOcKZp9stZ_C01DQ.."
Nota: Um token pré-gerado do ArcGIS Server pode ser obtido no Portal. Normalmente, a URL generateToken é: https://gisserver.domain.com/portal/sharing/rest/generateToken e a URL do Webapp seria então: https://gisserver.domain.com/server/admin. Defina o valor de Expiração para algo apropriado para a duração esperada do monitoramento.
Saída padrão ao executar a partir de uma janela de comando:
Conectado a: "https://gisserver.domain.com/server " (Gas)
Pressione Ctrl-C duas vezes para parar...
Dormindo por 5 segundos...
Quando em execução, o soccer conecta-se ao endpoint Service Report da pasta ArcGIS Server especificada, coleta os dados, grava-os em um arquivo CSV local e depois entra em modo de espera. Após o tempo de espera ter decorrido, ele repete o processo. O Soccer continuará coletando até que o processo seja interrompido manualmente (Ctrl-C).
Nota: Para coletar na pasta raiz do ArcGIS Server, use: -f "/" ou -f ""
Analisando o Arquivo CSV
Conteúdo de exemplo visto em um visualizador de texto simples:
DateTime,Epoch,IntervalSeconds,Host,Folder,ServiceName,Type,Provider,Running,Busy,Maximum,Free,NotCreated,Initializing,Transactions,TotalBusyTime,ServicesCollected,ResponseTimeMilliseconds,ContentLength,ConfiguredState,RealTimeState,Message
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,sucesso
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,sucesso
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,117.901,6065,STARTED,STARTED,sucesso
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,...
Nota: Por design , colunas como IntervalSeconds e ResponseTimeMilliseconds mostrarão valores duplicados se mais de um serviço existir na pasta observada.
Os dados coletados são um CSV típico , mas há alguns campos importantes que serão úteis para analisar rapidamente a atividade do ArcSOC dos nossos serviços de interesse:
- IntervalSeconds
- ServiceName
- Running
- Busy
- Maximum
Abrindo o arquivo CSV em uma planilha , outros serviços que residem na mesma pasta podem ser facilmente filtrados pela coluna ServiceName. Os valores IntervalSeconds , Running , Busy , Maximum podem então ser plotados para visualizar (por exemplo , através do gráfico Dispersão com Linha Suave ) e mostrar a configuração da instância versus a demanda recebida. Neste caso , o serviço Gas_Utility_Network foi configurado com instâncias mínimas/máximas de 32/32.
O gráfico "polido" abaixo:
Nota: Maximum e Running representam respectivamente a configuração máxima e mínima da instância do serviço ArcSOC. Neste caso , Running tem os mesmos valores e está plotado “atrás” de Maximum. Busy representa o número de instâncias que estavam ativas (devido a solicitações dos usuários) em todas as máquinas no Site.
O “objetivo” da sintonia e otimização neste caso seria evitar que os valores Busy alcancem constantemente o Maximum. Se isso acontecer , significa que não havia ArcSOCs suficientes disponíveis para o serviço atender à demanda dos usuários pois as instâncias estavam sempre ocupadas. As solicitações dos usuários provavelmente encontrariam tempos de resposta e espera aumentados no processo. Se as solicitações aguardarem muito tempo no sistema , elas expiram (normalmente após 60 segundos). Ter muitos timeouts nas solicitações do serviço impactaria negativamente a experiência do usuário.
Com base nas observações deste período monitorado , a subida e descida dos valores da coluna Busy não chegou nem perto do número máximo de instâncias disponíveis ... o que sob um aspecto foi bom. No entanto , isso também indicou que havia um número mensurável de instâncias em execução consumindo memória mas não sendo usadas ... o que não era ideal.
Para otimizar os recursos do sistema daqui para frente , a configuração das instâncias deste serviço poderia ter sido definida para um valor menor mais próximo do uso máximo esperado (por exemplo , entre 18 – 24).
- Use 18 para conservar memória com potencial de encontrar várias instâncias onde os usuários esperam mais tempo para suas solicitações serem atendidas
- Use 24 para favorecer desempenho em vez do uso de memória
Considerações Finais
Ter uma configuração “otimizada” para o número mínimo e máximo de instâncias não garante que os usuários nunca encontrarão desempenho lento. As necessidades e hábitos dos usuários mudam com o tempo , portanto monitorar essas informações é algo que precisará ser feito periodicamente.
No mundo real , existem condições onde tempos de espera pelo serviço ainda podem ocorrer em uma implantação ... mesmo com muitas instâncias disponíveis e muitos recursos do sistema. Não é realista eliminar completamente o tempo de espera pelo serviço mas é mais prático reduzi-lo. Otimizar as instâncias do serviço é algo que os administradores podem controlar diretamente e que impacta nos tempos de espera.
Entender e avaliar periodicamente a configuração das instâncias ArcSOC (para serviços dedicados) e sua relação com a demanda dos usuários é fundamental para ajudar os administradores GIS a planejar melhor e gerenciar seu Site otimizando desempenho e utilizando recursos eficientemente.
