Executando o Teste de Estresse
Executar um teste de estresse reproduzindo uma sessão previamente gravada simula um ambiente multiusuário em tempo real. Depois de ter uma ou mais sessões gravadas, você pode prosseguir com o procedimento do teste de estresse.
A Stress Test Tool reproduz uma sessão enviando sequências de requisições Ajax gravadas para o servidor. Essas requisições Ajax simulam muitos usuários interagindo com a aplicação web. Observação: a reprodução não executa sua aplicação web em uma janela de navegador real — a simulação consiste em enviar pacotes Ajax gravados ao servidor na mesma ordem em que foram registrados.
Preparar o ambiente
Não execute a Stress Test Tool no IDE ou em modo de depuração. Executar em modo de depuração reduzirá muito a velocidade e o desempenho da ferramenta. Compile e execute o executável diretamente.
Para gravar e reproduzir uma sessão móvel, adicione explicitamente '/m' ao final da URL da aplicação.
Carregue um projeto salvo ou grave uma nova sessão se não houver sessões gravadas disponíveis.
Ajustar parâmetros do teste
Ajuste estas configurações antes de iniciar o teste:
Total de sessões por execução: número de sessões criadas em cada execução. Comece com pouco e aumente gradualmente. Deve ser menor ou igual a ServerModule->ServerLimits->MaxSessions.
Max Worker Threads: número de threads de trabalho usadas para comunicar-se com o servidor. Deve ser menor ou igual a ServerModule->ServerLimits->MaxRequests.
Número total de execuções: quantas vezes reproduzir a sessão gravada.
Atraso entre execuções: segundos a aguardar antes de iniciar uma nova execução.
Velocidade de reprodução: ajuste a velocidade da sessão simulada. "Max Speed" não insere atraso entre chamadas Ajax; "Real Time" tenta corresponder ao tempo original gravado.
Métricas do monitor do servidor
Sessions: número de sessões atualmente em execução. O valor de pico mostra o máximo de sessões simultâneas durante o tempo de vida do servidor.
Requests: número de requisições Ajax pendentes atualmente sendo processadas pelo servidor.
Purged Files/Folders: arquivos/pastas que não pertencem mais às sessões mas ainda não foram apagados. O framework exclui arquivos/pastas purgados em uma thread de segundo plano; em condições normais esse valor deve eventualmente se tornar zero.
Bytes: número de bytes enviados/recebidos durante o tempo de vida do servidor.
Uptime: tempo decorrido desde que o servidor foi iniciado.
Memory: quantidade total de memória que a aplicação servidor está consumindo. Isto é crítico de ser monitorado:
32-bit apps: embora o limite teórico seja 2 GB, na prática valores acima de ~1,0–1,1 GB são perigosos devido à fragmentação e limitações do gerenciador de memória. Mensagens de "Out of Memory" podem ser registradas e usuários podem ver avisos ao iniciar novas sessões — isso pode levar a resultados imprevisíveis e travamentos.
64-bit servers are much less likely to hit Out of Memory; Windows can use virtual memory (swap) when physical RAM is exhausted, though performance will degrade.
Memory (Internal/Process): "Internal" é a memória usada pela aplicação uniGUI em si. "Process" é a memória total do processo Windows (que pode incluir memória usada por DLLs externas ou, se executando como uma ISAPI DLL, o processo worker ISAPI).
CPU Load: mostra o uso total de CPU através dos núcleos. Um servidor uniGUI ocioso mais o SO tipicamente não deve exceder ~1% de uso de CPU.
GDI Handles: recurso de sistema limitado rastreado pelo SO. uniGUI é otimizado para manter o uso de handles GDI baixo; uma aplicação uniGUI ociosa típica não deve consumir mais de ~100 handles GDI mesmo com muitas sessões ativas. Um aumento constante em handles GDI indica vazamentos ou uso excessivo. Ficar sem handles GDI irá registrar EOutOfResources exceções e pode levar ao travamento do servidor.
Arquivos de log
Monitore os arquivos de log da aplicação web durante o teste de estresse. O teste de estresse roda em segundo plano sem saída GUI; o arquivo de log é a principal forma de verificar o comportamento da aplicação e detectar erros. Os logs estão localizados na pasta .\logs ao lado dos binários da sua aplicação; há um arquivo de log separado por dia do calendário. Abra o log em um visualizador/editar de texto para verificar entradas inesperadas como Access Violations ou outras exceções. Para depuração mais detalhada, considere ferramentas como EurekaLog.
Onde procurar os logs
Pasta de logs: .\logs (ao lado dos binários da aplicação)
Um arquivo de log por dia — inspecione por Access Violations, Exceptions ou outros erros registrados durante as execuções.
Importante: Cada teste de estresse executa a mesma sessão gravada simultaneamente múltiplas vezes para a mesma URL. Durante os testes, defina ServerModule->SessionRestrict para srNone.