Manual de testes de desempenho do EMS Builder

Versão do manual: v1.1
Regra estatística atual: na amostragem por contagem, colete 2 amostras extras, uma no início e outra no fim; os resultados oficiais consideram apenas as amostras intermediárias.

Nota sobre o teste: não são conectados instrumentos reais, CLPs ou gateways seriais. Todos os dispositivos são simulados por Modbus TCP. Os resultados representam a capacidade de processamento do Edge-EMS Builder em condições ideais de comunicação, não o desempenho de ponta a ponta em campo.

I. Conteúdo dos testes

Área	Pergunta a responder
Aquisição de dados	Quantos pontos por segundo o EMS Builder consegue processar de forma estável?
Trigger	As tarefas Lua executam conforme o agendamento? O tempo de execução é estável?
MQTT / tarefas de colaboração	A quantidade de tarefas atinge a meta? Há atrasos ou falhas?
Armazenamento de dados	Como o armazenamento em tempo real e por alteração afeta o desempenho?
Recursos do sistema	CPU, memória e disco estão próximos dos limites?
Estabilidade	A execução prolongada causa falhas, reinicializações ou acúmulo contínuo de tarefas?

II. Carga de teste

2.1 Trabalho executado simultaneamente pelo EMS Builder

Carga	Conteúdo do teste
Aquisição de dados	Leitura de pontos de 20 dispositivos Slave simulados
Agregações	Cálculos Lua sobre os dados adquiridos
Trigger	Execução periódica de scripts Lua com ações de gravação, alarme e MQTT
Tarefas MQTT	Geração e publicação periódica de mensagens MQTT
Tarefas de colaboração	Compartilhamento e processamento colaborativo entre dispositivos
Armazenamento de dados	Persistência dos dados adquiridos, resultados calculados e registros de tarefas

2.2 O que cada script Lua de Trigger executa?

Conteúdo	Quantidade por execução	Função
Laço de cálculos básicos	100	Cálculos matemáticos, condições, laços, operações com strings e tabelas
Gravação em pontos originais	2	Grava nos pontos de teste `小数据0` e `小数据1`, respectivamente
Gravação em ponto agregado	1	Grava no ponto agregado de teste `Agg`
Alarme local	2	Gera dois alarmes de nível 1
Alarme MQTT	1	Gera um alarme MQTT de nível 2

2.3 Carga efetiva gerada por segundo

Indicador	Cálculo	Por segundo
Execuções de scripts Lua	Tarefas Trigger: `50 tarefas de 1s + 5 tarefas de 100ms = 100/s`; tarefas Mqtt: `50/s`; agregações: `50/s`; tarefas de compartilhamento: `10/s`	210
Laços de cálculos básicos de Trigger	`100 × 100`	10.000
Gravações de Trigger em pontos originais	`100 × 2`	200
Gravações de Trigger em pontos agregados	`100 × 1`	100
Alarmes locais de Trigger	`100 × 2`	200
Alarmes MQTT de Trigger	`100 × 1`	100
Todas as ações de gravação de Trigger	`100 × 6`	600
Publicações de mensagens MQTT	`50 × 1`	50
Agregações acionadas por alteração de dados	`50 × 1`	50
Tarefas de compartilhamento de dados	`10 × 1`	10

III. Cenários padrão

Método de cálculo:

Trigger/segundo = quantidade de Trigger de 1s + quantidade de Trigger de 100ms × 10

Cenário	Pontos adquiridos/s	Agregações	Trigger de 1s	Trigger de 100ms	Trigger/s	MQTT/s	Colaboração/s	Armazenamento	Duração
S1	500	10	10	0	10	5	0	Tempo real	30 minutos
S2	2.000	20	20	2	40	10	2	Tempo real	30 minutos
S2.5	2.000	20	20	2	40	10	2	Por alteração	30 minutos
S3	5.000	30	50	4	90	20	10	Tempo real	30 minutos
S3.5	5.000	30	50	4	90	20	10	Por alteração	30 minutos
S4	10.000	30	100	10	200	40	20	Por alteração	30 minutos
S5	20.000	40	200	10	300	60	40	Por alteração	30 minutos
S6	5.000	20	50	10	150	30	15	Tempo real	72 horas

Método de armazenamento	Descrição
Tempo real	Salva cada resultado de aquisição conforme a configuração
Por alteração	Salva imediatamente quando o valor muda; se não mudar, salva pelo menos uma vez a cada 10 segundos

S5 serve para identificar o limite de desempenho; S6 deve realmente ser executado por 72 horas.

IV. Regras de amostragem e estatística

4.1 Amostragem por contagem

Os novos testes de desempenho de curta duração usam uma contagem fixa de amostras, conforme o relatório da rodada correspondente. O exemplo abaixo usa 1.002 coletas por cenário, em intervalos de 1 segundo. O relatório v1.3 do AFE-E630 usa 2.002 coletas e 2.000 amostras válidas:

Amostra 1: limite da janela, não contabilizada
Amostras 2～1001: amostras oficiais, total de 1.000
Amostra 1002: limite da janela, não contabilizada

O relatório oficial deve filtrar raw_data por sample_no. Não use diretamente os valores consolidados completos da planilha summary, que incluem a primeira e a última amostras.

Para um teste completo de 30 minutos com intervalo de 1 segundo, colete 1.802 amostras e contabilize as 1.800 intermediárias. O teste de estabilidade de 72 horas de S6 não pode ser substituído por dados curtos de 1.002 amostras.

4.2 Recursos totais do EMS Builder

Os cinco serviços abaixo devem ser somados primeiro para o mesmo sample_no e só depois usados no cálculo dos indicadores estatísticos:

cb_core
cb_nginx
cb_backend
ems_backend
ems_postgresql

AEMS_CPU_raw(n) = soma da CPU dos 5 serviços no mesmo sample_no
CPU_total_4_núcleos(n) = AEMS_CPU_raw(n) ÷ 4
Memória_Edge-EMS_Builder(n) = soma da memória dos 5 serviços no mesmo sample_no

O relatório deve apresentar, no mínimo, média, P95, P99 e pico. Não some diretamente os picos independentes dos cinco serviços ocorridos em momentos diferentes.

4.3 Trigger e MQTT

Após ordenar trigger_per_sec e mqtt_per_sec cronologicamente, exclua também o primeiro e o último intervalos de um segundo, evitando períodos incompletos nas extremidades da consulta ao banco.

Os intervalos de tarefas por segundo não necessariamente correspondem um a um às amostras de recursos: um segundo pode não ter registros, ou tarefas acumuladas podem terminar juntas no segundo seguinte. O relatório deve informar a quantidade de intervalos válidos e apresentar também:

Vazão média por segundo e taxa de atendimento em relação à meta;
Média, P50, P95 e P99 das médias por segundo de SpendTime;
Maior valor individual de SpendTime entre todos os intervalos;
Quantidade e proporção de segundos cuja média de SpendTime excede 200 ms.

Se um segundo completo não tiver registros de tarefas, sua vazão deve ser contabilizada como 0; como não há latência calculável nesse segundo, não a invente como 0 ms. As versões futuras do script de monitoramento devem informar explicitamente o início e o fim da janela estatística para permitir completar segundos vazios.

V. Indicadores observados

Categoria	Estatísticas necessárias
Aquisição de dados	Pontos configurados, pontos bem-sucedidos, falhas e descartes
Trigger	Quantidade prevista e real, tempo médio, P50, P95, P99 e máximo
MQTT / colaboração	Quantidade prevista e real, tempo de execução e erros
CPU	Média, P95 e pico do EMS Builder completo
Memória	Média, pico e tendência do EMS Builder completo
Disco	Taxas de leitura/gravação, espera de I/O e estado das gravações no banco
Modbus	Leituras/gravações, falhas, timeouts e novas tentativas de cada Slave
Estabilidade	Falhas, OOM, reinicializações anormais e acúmulo contínuo de tarefas

Cálculos principais:

Exatidão = sucessos ÷ (sucessos + falhas + timeouts + descartes)

Taxa de atendimento = vazão média real por segundo ÷ meta do cenário

SpendTime representa o tempo real de execução da tarefa. Além da média, o relatório deve mostrar P95, P99 e máximo para identificar atrasos longos ocasionais.

VI. Avaliação dos resultados

O contrato ou os critérios de aceitação do projeto têm prioridade. Na ausência de critérios específicos, use as referências abaixo.

Item	Critério recomendado
Vazão	Taxa média de atendimento ≥ 99%
Tempo de Trigger / MQTT	P95 < 200 ms
CPU	Uso médio < 80% em dispositivo de 4 núcleos, sem saturação contínua
Memória	Uso médio do sistema completo < 70%, sem crescimento contínuo
Exatidão	≥ 99,99%, sem descartes não explicados
Estabilidade	72 horas contínuas sem falhas, OOM ou reinicializações anormais
Recuperação	Retorno à estabilidade em até 5 minutos após a redução da carga

6.1 Condições que invalidam o teste

Situação	Tratamento
Tempo de teste insuficiente	Marcar como “Não concluído”
Nem todos os 20 Slaves participaram	Repetir o teste
Gravações concentradas em poucos Slaves	Ajustar a distribuição e repetir
Gerador de carga ou rede torna-se o gargalo	Corrigir o problema e repetir
Ausência de dados de sucesso, falha ou timeout	Marcar como “Dados incompletos”
S6 não executado por 72 horas	Não declarar “Estabilidade aprovada”

S4 e S5 são testes de estresse. Ao atingir o limite do sistema, registre “Limite de estresse atingido” ou “Não recomendado para operação contínua”, sem apresentá-lo como aprovação da capacidade normal.

Relatórios por modelo:

Informações relacionadas: