Estratégias Recomendadas para Teste de Carga em uma Implantação do ArcGIS Server
- Comece com um plano de teste
A maioria dos softwares de teste pode produzir algum tipo de relatório após a conclusão do teste. Este relatório deve responder às perguntas que o plano de teste estava fazendo.
Por exemplo:
a) O serviço ArcGIS poderia utilizar toda a CPU (por exemplo, limitado pela CPU)?
b) O serviço ArcGIS poderia entregar uma taxa específica de transferência (por exemplo, uma certa quantidade de transações/seg)?
c) A taxa de transferência entregou um tempo médio de resposta que atendeu ao nosso requisito de desempenho?
Definir um propósito para um teste ajuda a manter o esforço de teste focado em um objetivo.
- Os testes devem ser realizados contra aplicações sem bugs ou defeitos maiores conhecidos
O teste de carga não deve ser usado para testar funcionalmente uma implantação ou aplicação.
Uma aplicação deve passar pelo teste de garantia de qualidade (QA) antes que os testes de carga sejam realizados.
Além disso, se uma aplicação contiver bugs maiores, tais deficiências podem ter um impacto mensurável no desempenho e escalabilidade dos serviços oferecidos. Isso, por sua vez, provavelmente anularia os resultados do teste e potencialmente desperdiçaria tempo, dinheiro e recursos.
- Interaja com sua aplicação (e serviços ArcGIS) antes de testá-los sob carga
Se você for o único usuário no seu sistema e os serviços ArcGIS responderem muito lentamente, não há necessidade de realizar um teste sob carga. O próximo passo deve ser ajustar e otimizar os serviços ArcGIS para desempenho.
- Coordene a execução do teste
Muitas vezes um teste de carga é realizado em um ambiente QA/Staging ou Teste, mas ocasionalmente pode ser realizado em Produção.
Qualquer que seja o ambiente, é importante lembrar que frequentemente, serviços e recursos estão sendo consumidos por outros usuários também (e não apenas pela equipe de teste de carga).
Para ajudar a evitar confusão e experiências inesperadas, é altamente recomendável coordenar a execução de quaisquer testes de carga com o pessoal apropriado.
Fazer isso pode ajudar a proporcionar uma melhor experiência para os usuários reais e pode evitar ruídos indesejados em um teste de carga (de ações que usuários reais possam estar fazendo).
- Verifique se o ambiente de Teste corresponde às expectativas
Às vezes o ambiente de Teste pode ser reduzido devido a uma variedade de razões. Então, com o tempo, Teste e Produção tornam-se ambientes muito diferentes. Nesse caso, os resultados dos testes derivados do ambiente Teste teriam pouco significado em relação a como a Produção irá performar ou escalar.
Por exemplo:
a) Se espera-se que a Produção seja implantada usando uma arquitetura Altamente Disponível então o Teste também deve ser
b) Se espera-se que a Produção utilize um geodatabase empresarial contendo 500GB de dados vetoriais então o Teste também deve
c) Se a Produção usa ArcGIS Servers com 32 núcleos e os máximos da instância do serviço estão configurados para 32, então o Teste também deve
Manter os ambientes Teste e Produção sincronizados pode ajudar a fornecer o melhor valor (e expectativa) sobre os resultados. Nos casos em que eles conscientemente não correspondem, faça uma anotação disso antes do início dos testes e em quaisquer conclusões derivadas do ambiente Teste.
- Comece um teste de carga no passo 1
Usar 1 como passo inicial de carga pode ajudar na análise pós-teste.
O Passo 1 (ou uma thread concorrente de teste) representa o melhor cenário possível para seu teste. Esta é sua linha base e é uma boa referência para entender quão bem ou mal o serviço ArcGIS escalou conforme a pressão aumentou (por exemplo, quando threads adicionais foram adicionadas).
- Colete utilização do hardware de todas as máquinas envolvidas no teste
A maioria dos frameworks de teste normalmente fornece a capacidade de coletar utilização do hardware dos servidores e do próprio cliente de teste. Isso pode ser valioso para entender o consumo de recursos e identificar gargalos (por exemplo, os recursos no cliente de teste também podem ser um fator limitante).
No entanto, apesar dessa funcionalidade estar presente no software de teste, coletar a utilização do hardware nem sempre é possível devido a permissões ou acesso à rede (por exemplo, conexão através de firewalls/roteadores).
Embora obter essa informação diretamente através do framework seja certamente conveniente, existem outras maneiras para realizar essa tarefa. Usar ferramentas gratuitas como PerfMon no Windows ou dtstat no Linux para capturar esses dados é um passo extra mas vale o esforço. Uma vez que o teste esteja completo, a análise ainda pode ser realizada nos dados manualmente criados dos gráficos da utilização do hardware.
- Teste individualmente os serviços ArcGIS primeiro
Se uma aplicação web específica usa mais de um serviço ArcGIS, teste e ajuste cada um separadamente.
Essa abordagem facilita identificar quais serviços podem ter gargalos ou limitações que impedem eles de utilizar todo o hardware disponível.
Se um serviço ArcGIS não puder utilizar todo o hardware CPU disponível do ArcGIS Server, o testador/analista deve notificar a pessoa apropriada que existe uma oportunidade de ajuste na implantação
Além disso, evite começar o esforço de teste com todo o fluxo da aplicação pois pode ser difícil identificar potenciais gargalos quando muitos serviços ArcGIS são testados ao mesmo tempo.
- Teste tão fisicamente próximo da implantação quanto possível
Tente não fazer o teste "simular" a Internet. Testar tão fisicamente próximo da implantação quanto possível pode ajudar a fornecer a melhor compreensão do que o hardware do servidor pode entregar.
Introduzir propositalmente latência na rede ou largura de banda ruim adicionará ruído ao teste e dificultará reconhecer toda a capacidade dos serviços ArcGIS e dos servidores onde eles estão rodando.
- Duração do passo e do teste
Os testes não precisam rodar por 8 horas para fornecer informações úteis sobre o serviço ArcGIS em questão. No entanto, também é recomendado evitar executar um teste muito curto. Isso se resume a escolher um tempo adequado para o teste (e para cada duração do passo) que forneça a quantidade certa de informação. Em outras palavras, trata-se de registrar amostras suficientes das requisições para obter uma média "boa".
O tempo usado geralmente está ligado ao seu tempo de resposta: um tempo rápido pode entregar muitas requisições com uma carga em passos de 5 minutos. Um tempo lento pode precisar de uma carga em passos de 15 minutos para registrar tantos valores quanto.
Como testador, você pode não acertar sempre na duração do passo e do teste na primeira estimativa e pode precisar ajustar e executar novamente o teste.
- Esteja atento ao Nível do Log do ArcGIS Server
Embora os logs do ArcGIS Server possam fornecer muita informação para análise, é importante entender que níveis mais altos como VERBOSE e DEBUG podem desacelerar o desempenho em sites muito ocupados e não são configurações recomendadas para ambientes Production. Enquanto isso, o valor WARNING (padrão) oferece o melhor desempenho possível pois registra apenas avisos e erros.
No entanto, uma configuração FINE é um bom compromisso entre informações analíticas úteis (como tempos decorrido em requisições dinâmicas) e velocidade.
- Serviços tradicionais ArcGIS podem ser ajustados dentro do Server (ArcGIS)
Antes de testar sob carga um serviço tradicional (por exemplo dedicado) ArcGIS para ajustá-lo ou entender como ele performa, tente configurar o valor máximo da instância ArcSOC para o número disponível dos núcleos CPU no servidor ArcGIS.
Após reiniciar o serviço, essa configuração permitirá múltiplas requisições simultâneas aproveitarem o hardware disponível e mostrar isso da melhor forma possível (isso assume que o serviço está limitado pela CPU).
style="padding-left : 30px;">Aumentar o valor máximo da instância ArcSOC também permitirá que o serviço utilize mais CPU, mas por sua vez, mais memória também. Por favor, certifique-se de que há memória adequada disponível na máquina ArcGIS Server para acomodar o ajuste. Se o serviço não estiver em alta demanda, as instâncias extras ficarão ociosas (o padrão é 1800 segundos) e serão desligadas para liberar memória do servidor.<\/P>
Da mesma forma, aumentar o mínimo de uma instância de serviço (para corresponder ao máximo) é uma boa estratégia para obter desempenho previsível. Isso é recomendado para os serviços mais populares, mas tenha em mente que tal configuração sempre consumirá memória (para esse serviço), pois nenhuma instância será desligada após o tempo ocioso ter decorrido.<\/P>
Serviços compartilhados têm configurações de instância que também podem ser ajustadas. No entanto, se um serviço compartilhado for popular o suficiente para ser testado com carga, ele deve ser ajustado para funcionar como um serviço tradicional e dedicado.<\/P>
- Nem todos os serviços ArcGIS são limitados por CPU<\/STRONG><\/LI><\/UL>Se um serviço ArcGIS é limitado por CPU, isso significa que a quantidade de throughput que ele pode entregar (ou capacidade que pode suportar) é limitada apenas pelo número de CPUs na(s) máquina(s) ArcGIS Server. De muitas maneiras, isso pode ser algo bom.<\/P>No entanto, nem sempre é assim. Às vezes, você pode ter gargalos em outro hardware como a rede, por exemplo. Ocasionalmente, você pode encontrar um gargalo em um componente de software que pode ser por design ou não intencional.<\/P>Portanto, a coleta de métricas de hardware durante o teste é muito importante. Observar a utilização da CPU, Memória, Rede e Disco pode ajudar a fornecer ao testador/analista informações vitais para entender se há algo limitando a escalabilidade do serviço ArcGIS Server e se é o hardware do servidor ou do cliente de teste.<\/P>Tudo é sobre throughput (não usuários)<\/STRONG><\/LI><\/UL>Throughput é medido, usuários são calculados... eles são dois artefatos diferentes de um teste.<\/P>Em um teste, throughput é tipicamente definido como transações/segundo (ou operações/segundo), e este é um valor que deve ser medido pelo software cliente de teste. Por outro lado, a definição de um "usuário" pode variar mas geralmente é algo calculado a partir do throughput.<\/P>Como o throughput é observado diretamente dos resultados de um teste de carga, ele é uma das melhores métricas para determinar a escalabilidade de uma implantação.<\/P>Em nota relacionada, uma thread de teste (por exemplo, o item que aumenta em correspondência ao aumento da pressão adicionada a um teste de carga) não é o mesmo que um usuário. O número de threads de teste utilizados e sua duração são tipicamente configurados na definição de carga gradual de um teste.<\/P>Verifique se o teste foi bem-sucedido<\/STRONG><\/LI><\/UL>A conclusão de um teste não significa necessariamente que ele foi "bom" e capaz de responder com sucesso às perguntas no plano de teste. É importante verificar e validar se o teste estava enviando as solicitações corretas onde deveria e recebendo as respostas esperadas.<\/P>Uma rápida verificação manual de controle de qualidade (QC) da composição das solicitações no teste pode ajudar com o primeiro ponto.<\/P>Enquanto monitorar o comprimento médio do conteúdo (por resposta) pode ajudar com o segundo.<\/P>A maioria dos softwares de teste fornece uma "razão" para capturar o comprimento médio do conteúdo (ou algo similar). A regra geral é que o valor médio dessa métrica deve permanecer relativamente constante durante todo o teste. Se aumentar ou diminuir drasticamente, recomenda-se investigação adicional pois a resposta esperada para as solicitações pode não estar retornando (por exemplo, erros em vez de conteúdo image ou json) ou se a resposta for válida mas altamente variável, um design diferente do teste pode ser necessário.<\/P>Além disso, é importante determinar se as próprias solicitações foram bem-sucedidas (por exemplo, HTTP 200). Alguns softwares de teste podem permitir ao analista configurar verificações de validação nas respostas dentro do próprio teste. Dito isso, o perfilamento da métrica do comprimento médio do conteúdo geralmente fornece uma visão mais precisa da resposta esperada do servidor.<\/P>Resultados do teste não garantem suporte para X número de usuários<\/STRONG><\/LI><\/UL>Os resultados do teste apenas validam o fluxo de trabalho testado. Esse fluxo testado mostrará throughput para um tipo específico de solicitação com um tempo correspondente de resposta. Não promete nem garante que a implantação suportará X número de usuários.<\/P>Lembre-se, a definição de usuário pode variar e significar coisas diferentes para implantações diferentes.<\/P>Evite testar recursos compartilhados como ArcGIS Online ou Google Maps<\/STRONG><\/LI><\/UL>Ofertas gratuitas e públicas dos serviços ArcGIS Online ou Google Maps existem para a "comunidade". Esses recursos são bastante robustos e escaláveis mas não podem ser otimizados em desempenho para cada usuário.<\/P>Como eles não fazem parte diretamente de uma implantação on-premise, devem ser considerados recursos "externos". Como resultado, solicitações para eles devem ser removidas de um teste de carga pois o teste deve focar exclusivamente nas capacidades do seu próprio hardware.<\/P>Resultados repetíveis dos testes<\/STRONG><\/LI><\/UL>Se os resultados para um teste de carga contra um serviço ArcGIS Server mostrarem linhas de tendência similares entre execuções do teste (por exemplo, o mesmo throughput alcançado aproximadamente no mesmo ponto durante o teste), o recurso geralmente é considerado "estável". Ser capaz de repetir os resultados para um teste é uma boa característica.<\/P>Quando os resultados não são imediatamente repetíveis, o testador/analista deve investigar mais profundamente e tentar entender o comportamento inconsistente. Pode ser que o hardware estivesse sendo usado para atender solicitações além do teste (por exemplo, outro usuário no sistema). Ou, se a implantação estava em infraestrutura compartilhada (por exemplo virtualização), o hardware subjacente estava sendo utilizado para outro propósito (outras máquinas virtuais executavam tarefas intensivas em recursos). Para casos assim, realizar os testes durante horários fora do pico pode gerar resultados mais reproduzíveis mostrando que o serviço tem potencial para ser estável.<\/P>O design dos testes/flujos deve ser realista e baseado no esperado pelo usuário<\/STRONG><\/LI><\/UL>Evite teorias e projeções; apenas foque em como o usuário deveria usar a aplicação...o fluxo antecipado.
Testes de carga podem ser fáceis de fazer mas também fáceis de expandir escopo incluindo cenários desnecessários ou improváveis.<\/P>Entenda o valor<\/STRONG><\/LI><\/UL>Muitas vezes, o caminho para um bom e útil teste é tão importante quanto o próprio teste. Como analista isso ajuda você:<\/P>a) Validar os procedimentos de teste<\/P>b) Ter maior capacidade para explicar os resultados que por sua vez tornam seu teste valioso<\/P> 1) Algumas pessoas não vão apenas pedir resultados mas também análise e conclusões<\/P> 2) Esteja preparado para respaldar essas conclusões com dados<\/P>Mantenha simples<\/STRONG><\/LI><\/UL>Às vezes os esforços mais informativos nos testes são simples e não excessivamente complexos.<\/P>
