Requisição
Também conhecido como sampler
Uma requisição HTTP é a menor unidade de trabalho que você pode definir para um teste realizar. Geralmente, ao testar ArcGIS Enterprise, pode ser uma URL para um recurso como um serviço de mapa, serviço de feição ou resolução de rota, mas também pode ser uma chamada para um objeto estático como um arquivo *.css ou *.js.
O protocolo pode ser HTTP (texto simples) ou HTTPS (seguro) e o método pode ser um dos muitos, embora GET, POST e HEAD sejam tipicamente os mais comuns.
Uma requisição dinâmica de serviço de mapa se pareceria com o seguinte formato:
https://yourwebadaptor.domain.com/server/rest/services/NaturalEarth/MapServer/export?bbox=-130.9656801129776%2C18.608785315857112%2C-57.52504741730332%2C52.34557596043248&bboxSR=4326&imageSR=4326&size=1920%2C882&dpi=96&format=png32&transparent=true&layers=show%3A15%2C16%2C17%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%2C33%2C34%2C35&f=image
A mesma URL como uma requisição HTTP do Apache JMeter:
Como seria uma requisição estática:
https://yourwebadaptor.domain.com/portal/home/10.9.0/js/jsapi/dojo/dojo.js
Apache JMeter também faz a distinção entre uma requisição e um sampler, embora ambos definam uma ação a ser executada. Um sampler seria a execução de um processo no nível do Sistema Operacional que realiza algum tipo de ação, como executar uma ferramenta de geoprocessamento para criar um arquivo geodatabase ou criar uma nova versão SDE em um geodatabase empresarial. Todo teste deve ter pelo menos uma requisição ou sampler.
Outro tipo de sampler é um web socket. Embora seja semelhante a uma requisição HTTP no sentido de que faz uma chamada pela "web" e pode ser seguro, ele usa um protocolo diferente para se comunicar com o servidor remoto, bem como parâmetros diferentes para especificar opções de parâmetro.
Transação
Uma transação é um agrupamento lógico de uma ou mais requisições http. As requisições podem ser dinâmicas e/ou estáticas. Juntas, essas requisições normalmente compõem uma operação do usuário, por exemplo:
- O carregamento do aplicativo web
- Uma ação de navegação como pan ou zoom
- Uma função de busca
- Criação de uma nova Versão SDE dentro de um GeoDatabase Empresarial
Não é um requisito técnico usar transações em um teste, mas fazê-lo pode melhorar muito a análise, pois operações individuais (por exemplo, transações) poderiam então ser isoladas para mostrar seus respectivos comportamentos de desempenho durante a execução. Isso pode ser muito informativo.
Entender que apenas as requisições para escala de mapa 1:72.224 tiveram problemas de desempenho é muito útil do ponto de vista de ajuste, pois você saberia exatamente quais áreas do documento ou projeto do mapa precisariam ser
ajustadas... as transações podem ajudar você a conseguir isso.
Transação Apache JMeter contendo três requisições de uma operação:
Teste
Também conhecido como plano de teste ou projeto de teste
O termo "teste" é bastante genérico e é frequentemente usado tanto como substantivo (Eu criei um teste para chamar o recurso) quanto como verbo (Eu vou testar o serviço). Transações e requisições geralmente são definidas em um teste. O teste terá opções adicionais para configurar, tais como: por quanto tempo o teste será executado, para onde os resultados irão, se métricas nos servidores remotos devem ser coletadas.
Diferentes frameworks usam terminologias ligeiramente diferentes para descrever um teste. No caso do Apache JMeter, um teste ou projeto de teste é chamado Plano de Teste e é designado com a extensão *.jmx.
Carga em Etapas
Também conhecido como carga
A carga em etapas é uma característica que define por quanto tempo e quantas threads concorrentes aplicar durante o teste através de pressão incremental uniforme (por exemplo, semelhante a uma escada). Configurar o teste para uma carga em etapas é útil para entender como um serviço de mapa performa ou escala ou como os recursos da implantação se comportam
à medida que mais e mais requisições são enviadas para ele. A pressão definida também pode diminuir (no final do teste), mas não precisa.
Grupo de Threads Apache JMeter (bzm - Concurrency) especificando e visualizando uma carga em etapas específica:
Carga Constante
Uma carga constante também define por quanto tempo e quantas threads aplicar no teste, mas geralmente é configurada para uma taxa constante por longos períodos. Em vez de focar em desempenho e escalabilidade, essa configuração é tipicamente para entender durabilidade e estabilidade.
Grupo de Threads Apache JMeter (bzm - Concurrency) especificando e visualizando uma carga constante específica:
Threads do Teste
Também conhecidos como threads
Este é o mecanismo responsável por aplicar carga pegando o trabalho definido a ser feito no teste, como as transações e/ou requisições, e executando-os repetidamente.
As threads do teste normalmente se comportam de forma serial onde cada thread começa lendo a primeira requisição definida no teste, envia isso ao servidor e então aguarda sua resposta. A próxima requisição no teste não será emitida até que uma resposta volte do servidor ou que um tempo limite tenha expirado. Uma vez que uma dessas condições seja atendida, ela passa para a próxima requisição. A maioria dos testes está configurada para que cada thread repita esse processo continuamente durante toda a execução.
Diversas tecnologias frequentemente referem-se às threads do teste como usuários virtuais, mas isso pode ser enganoso. As threads do teste são apenas o meio (pressão) para um fim (throughput entregue).
Em outras palavras, a execução de um teste configurado com carga em etapas que atinge 100 threads não significa que o ambiente está suportando 100 usuários virtuais concorrentes. Nesse caso, determinar usuários seria calculado com base no throughput do teste; transações/segundo, por exemplo.
Grupo de Threads Apache JMeter (bzm - Concurrency) definindo a carga em etapas via threads (de teste):
Usuários
Também conhecidos como usuários virtuais
O número de usuários suportados é um dos itens mais solicitados para determinar a partir de um teste de carga e geralmente assume a forma:
- Quantos usuários este serviço ou aplicação específica suportará?
- Um determinado serviço ou aplicação suportará pelo menos X usuários?
O cálculo dos usuários está intimamente ligado ao tempo de reflexão assim como aos artefatos medidos no teste tais como throughput e tempo de resposta.
Usar a Little Law com essas entradas pode fornecer uma estimativa teórica do número de usuários que um ambiente pode suportar.<\/P>
Tempo de Pensamento<\/STRONG>
Também conhecido como ritmo do fluxo de trabalho<\/STRONG><\/EM><\/H5>Tempo de pensamento é uma duração (definida em segundos ou milissegundos) que é adicionada a um teste para simular os atrasos do comportamento humano que ocorreriam quando uma pessoa interage naturalmente com o serviço de mapa ou aplicação web.
Atrasos de tempo de pensamento podem ser adicionados a transações (por exemplo, uma operação) ou solicitações ou até mesmo ao próprio teste (que então é referido como ritmo do fluxo de trabalho). A forma como são adicionados pode variar dependendo da estrutura de teste envolvida.
No caso do Apache JMeter, existem vários temporizadores diferentes disponíveis que podem ser adicionados ao teste para simular vários tipos de atrasos.<\/P>Indicadores-chave de desempenho (KPIs)<\/STRONG><\/H5>KPIs são métricas de teste que auxiliam na análise de um teste de carga. Alguns dos mais populares estão associados à medição do tempo de resposta e throughput do teste. No entanto, eles também se estendem a itens que contam o número de solicitações falhadas, contam o comprimento médio do conteúdo (por solicitação) ou que coletam informações sobre a utilização de hardware (como CPU, memória, rede e disco).
Embora a capacidade de capturar a utilização de hardware frequentemente exija configuração adicional do teste e permissões dentro do ambiente, essa informação é um dos artefatos mais importantes capturados em um teste de carga.<\/P>Nota: A utilização capturada do hardware é um dos artefatos mais importantes capturados em um teste de carga.<\/FONT><\/STRONG><\/P>Tempo de Resposta<\/STRONG><\/H5>Tempo de resposta é uma métrica comum usada para medir o desempenho de uma solicitação, transação ou teste. Simplificando, fornece uma compreensão de quão rápido uma operação está se comportando.
O valor é tipicamente apresentado em segundos ou milissegundos. Desempenho mais rápido significa tempos de resposta menores, o que se traduz em uma experiência do usuário mais favorável. O tempo de resposta pode ser plotado ao longo da duração do teste para entender como o desempenho escalou ou listado junto com o throughput para um ponto particular no teste (por exemplo, onde o throughput atingiu o pico).<\/P>Nota: Tempos de resposta são um dos artefatos mais importantes capturados em um teste de carga.<\/STRONG><\/FONT><\/P>Idealmente, o desempenho do item sendo testado seguirá a seguinte curva onde os tempos de resposta subirão mais rapidamente (em torno do ponto do pico do throughput). No exemplo a seguir, o tempo médio de resposta da solicitação no pico do throughput foi cerca de 0,4 segundos.<\/P>
<\/span><\/P>Throughput<\/STRONG>:<\/H5>Throughput é uma métrica comum usada para medir a escalabilidade de um serviço de mapa, aplicação web ou infraestrutura de hardware. Essencialmente, fornece uma compreensão da taxa na qual uma operação pode ser conduzida durante um período.
O valor geralmente pode ser capturado como solicitações\/segundo, transações\/segundo (por exemplo, operações\/segundo) ou testes\/segundo, embora frequentemente seja expresso ao longo da duração de uma hora (a taxa em segundos multiplicada por 3600).
Maior escalabilidade significa mais throughput, o que se traduz em suporte para mais usuários.
Algumas análises de teste focarão no throughput médio de todas as transações para um teste, enquanto outras podem examinar o throughput médio para cada operação individual.<\/P>Nota: Throughput é um dos artefatos mais importantes capturados em um teste de carga.<\/STRONG><\/FONT><\/P>Idealmente, o throughput do item sendo testado se assemelhará à seguinte curva onde atinge um pico e depois se estabiliza. <\/SPAN>Quando o throughput atinge pico e/ou se estabiliza, sugere que o teste encontrou algum tipo de gargalo. No exemplo a seguir, o throughput médio das solicitações no pico foi cerca de 24 solicitações por segundo (ou 86.400 solicitações por hora).<\/P>
<\/span><\/P>Gargalo<\/STRONG><\/H5>Um gargalo é uma condição em uma implantação onde um dos seus componentes ou camadas está limitando a taxa na qual pode responder às solicitações recebidas. Um gargalo pode assumir a forma de:<\/P>Exemplos de HardwareTodos os núcleos da CPU do ArcGIS Server estão totalmente utilizados<\/LI>A memória disponível está esgotada<\/LI>A entrada/saída do disco de armazenamento do servidor Database está totalmente utilizada<\/LI>A placa de rede está saturadaDevido ao tráfego enviado ou recebido <\/LI><\/UL><\/LI><\/UL><\/LI>Exemplos de SoftwareO banco foi configurado para permitir apenas 25 conexões simultâneas apesar dos recursos amplos disponíveis no hardware<\/LI>O throughput para consumir um serviço de mapa se estabiliza mas a utilização da CPU do ArcGIS Server não aumenta acima de 25%<\/LI><\/UL><\/LI><\/UL>Um gargalo sempre existirá em uma implantação e determinar qual componente restringirá primeiro faz parte da análise. Frequentemente será necessário um teste de carga para expor onde ocorrerá o primeiro gargalo, pois ele pode ser observado apenas sob grande pressão. Embora os recursos e configurações do servidor sejam tipicamente o foco da análise do gargalo, os recursos do cliente do teste (CPU, memória, rede, disco e em alguns casos a licença do teste) também podem ser fatores. Alcançar um gargalo não é necessariamente um problema, apenas indica onde está a primeira fraqueza ou limitação dentro do sistema. Às vezes um gargalo é considerado algo "bom", por exemplo ao executar um grande processo ArcGIS caching, deseja-se que a CPU seja o primeiro gargalo porque ela está fazendo o trabalho para criar as tiles do mapa. Se a CPU só puder alcançar 50% devido a outro gargalo (por exemplo, entrada/saída no disco), levará o dobro do tempo para concluir o trabalho em relação à utilização da CPU em 100%.<\/P>Nota: Um gargalo sempre existe em uma implantação<\/STRONG><\/FONT><\/P>Tipo de Teste<\/STRONG>
Também conhecido como performance test, load test, stress test, endurance test, benchmark test<\/STRONG><\/EM><\/H5>Muitas organizações frequentemente usam categorias diferentes para classificar os testes realizados.<\/P>Um performance test é tipicamente utilizado para solucionar problemas com um serviço ou aplicação quando ele está lento ou produz tempos maiores que o esperado para respostas. Eles não precisam envolver uma carga gradual e podem ser convenientemente executados como um único usuário interagindo diretamente através do navegador web com o endpoint em questão.<\/P>Um load test pode frequentemente ser usado para descrever um step load test com objetivo de atingir uma meta particular de throughput e tempo de resposta. Por exemplo, X transactions/sec<\/EM> com tempo de resposta abaixo de Y seconds<\/EM> e sem falhas. Isso pode resultar no esgotamento dos recursos físicos do servidor mas geralmente esse não é o objetivo. Um load test também pode ser referido como scalability test.<\/P>Um stress test é similar mas frequentemente focado em alcançar uma pressão que seja múltiplo da meta do load test. Em outras palavras, se o load test estava tentando alcançar X transactions/sec<\/EM>, o stress test poderia tentar alcançar X * 5 transactions/sec<\/EM> sem encontrar uma quantidade significativa de falhas.<\/P>Um endurance test tem a distinção de tentar<\/EM> quebrar<\/EM> componentes do sistema. Sua carga aplicada pode ser múltiplo da carga aplicada no stress test onde o objetivo é<\/EM> encontrar erros significativos e observar throughput e tempo resposta quando eles ocorrem. Um endurance test também pode ser referido como durability test onde a carga aplicada é constante por muito tempo e padrões da utilização e recuperação dos recursos físicos são observados.<\/P>Plano De Teste<\/STRONG><\/H5>No sentido geral, um plano de teste é documento, tabela ou lista que define os testes específicos que serão executados, bem como seus respectivos objetivos. Esses objetivos são a razão e o propósito de cada teste. A análise dos resultados (manual ou a partir de relatórios de teste gerados) deve ajudá-lo a determinar se os objetivos de cada teste foram alcançados.<\/P>Testing Framework <\/STRONG><\/H5>O testing framework é a ferramenta ou tecnologia usada na forma de bibliotecas, APIs, bem como uma interface gráfica do usuário (GUI) para montar requisições, e o teste, além de definir a carga a ser aplicada.
Existem muitos ótimos testing frameworks por aí e Apache JMeter é apenas um<\/EM> deles. Embora todos tenham propósitos semelhantes, muitos adotam abordagens diferentes para o vocabulário de certos componentes e como criam um teste e aplicam carga. Alguns colocam a definição das requisições e transações em seus próprios arquivos com a configuração da carga em etapas em outro.
Com Apache JMeter, todos os objetos do teste são definidos no Plano de Teste e são logicamente separados dentro da árvore.<\/P>Alguns exemplos de testing frameworks para load testing:<\/P>Apache JMeter<\/A> <\/LI>LoadRunner<\/A> <\/LI>Silk Performer<\/A> <\/LI><\/UL>Alguns exemplos de testing frameworks para performance testing:<\/P>
wget<\/A>- Uma ferramenta de linha de comando para recuperar uma ou mais URLs<\/LI>
- Pode fornecer um alto nível de detalhe em cada requisição e resposta<\/LI><\/UL><\/LI>
curl<\/A>
- Uma ferramenta de linha de comando para recuperar uma ou mais URLs<\/LI>
- Pode fornecer um alto nível de detalhe em cada requisição e resposta<\/LI><\/UL><\/LI>
Fiddler<\/A>- Depurador HTTP baseado em GUI que pode ser usado sozinho ou com um navegador web<\/LI>
- Pode fornecer um alto nível de detalhe em cada requisição e resposta<\/LI><\/UL><\/LI><\/UL>
Testing Framework Architecture<\/STRONG><\/H5>Ao testar ArcGIS Enterprise, grande parte da atenção arquitetônica se concentra na escalabilidade dos níveis de implantação: Load Balancer, Web Adaptor, Portal for ArcGIS, ArcGIS DataStore, ArcGIS Server, Enterprise Geodatabase e Network Storage. Embora uma máquina de teste com 8 núcleos geralmente possa enviar uma quantidade razoável de requisições que satisfaçam o teste típico, às vezes múltiplas máquinas são necessárias se a carga a ser aplicada exigir potência séria.<\/P>Dependendo do testing framework envolvido, vários dos componentes de teste podem ser separados em máquinas diferentes para melhorar a escalabilidade do test client<\/EM>.<\/P>Componentes comuns para escalar são:<\/P>Test ControllerComo o nome indica, o foco principal do controller é parar e iniciar o teste, bem como coordenar a coleta das métricas do teste de um ou mais Test Agents<\/LI>No caso do Apache JMeter, o controller está integrado diretamente na GUI mas também está rodando quando o teste é executado pela linha de comandoOutros testing frameworks podem ter um frontend Test Controller baseado na web<\/LI><\/UL><\/LI>Normalmente, apenas um Test Controller é necessário para qualquer ambiente de teste dado, mas ele pode rodar em hardware dedicado separado dos Test Agents<\/LI><\/UL><\/LI>Test AgentA principal função do Test Agent é enviar requisições e receber respostas do servidorEste componente realiza a maior parte do trabalho e requereria mais recursos de CPU<\/LI><\/UL><\/LI>Para trabalhos grandes, várias máquinas Test Agents podem ser necessárias<\/LI>No caso do Apache JMeter, por padrão, o Test Agent roda na mesma máquina que o Test Controller <\/LI><\/UL><\/LI>Test RepositoryUma máquina dedicada ao armazenamento dos resultados do load test Isto pode incluir métricas do teste como tempo de resposta, throughput e utilização de hardware<\/LI><\/UL><\/LI>No caso do Apache JMeter, os resultados são armazenados no controller em arquivos texto (*.JTL)É possível enviar os resultados para um banco de dados, mas este não é o padrão<\/LI><\/UL><\/LI><\/UL><\/LI>Test VisualizationUma máquina usada para visualizar as métricas do teste e utilização do hardware em tempo real<\/LI>No caso do Apache JMeter, a GUI não é recomendada para visualização dos dados durante uma execução de teste em produção, mas a linha de comando simSe os resultados forem enviados para um banco de dados, softwares adicionais podem conectar-se ao Test Repository para visualizar as informações<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Interactive Response Time Law<\/STRONG><\/H5>A Interactive Response Time Law é uma fórmula que define a relação entre fatores chave de desempenho, nomeadamente usuários, throughput, tempo de resposta e tempo de reflexão do usuário. O cálculo pode ser organizado para determinar o parâmetro de interesse desde que você conheça os outros três. Por exemplo, se o número de usuários utilizando o sistema for conhecido, qual é o tempo médio de resposta das requisições e o tempo médio de reflexão do usuário, podemos então derivar a demanda estimada de throughput no sistema. Esta lei é muito útil ao tentar converter usuários em throughput e throughput em usuários e outros casos de uso também e é fundamental para áreas relacionadas a testes como planejamento de capacidade.<\/P>Dada a seguinte fórmula:
N = X * (R + Z)<\/P>N = Número de jobs ou usuários concorrentes
X = Throughput por segundo no sistema
R = Tempo de resposta, ou tempo médio que um job passa no sistema
Z = Tempo de reflexão (Think time)<\/P>Para mais informações sobre a Interactive Response Time Law veja:<\/P>http:\/downloads.esri.com\Support\downloads\other_\ArcGIS%20Enterprise%20deployment%20guide_Scene%20layer%20benchmark%20testing.pdf<\/A><\/LI>https:\/homepages.inf.ed.ac.uk\jeh\biss2013\Note2.pdf<\/A><\/LI><\/UL> <\/P>
<\/P>
Apache JMeter<\/A> lançado sob a <\/SPAN>Apache<\/A> <\/SPAN>License 2.0.<\/A> Apache, Apache JMeter, JMeter, a pena Apache (Apache feather), e o logo Apache JMeter são marcas registradas da Apache Software Foundation.<\/SPAN><\
