Relatório de testes de desempenho do EMS Builder no AFE-E630
Versão do relatório: v1.3
Data dos testes: 2026-07-29
Data do relatório: 2026-07-30
Critério estatístico: 2,002 coletas por cenário; a primeira e a última amostras são descartadas, e apenas as 2,000 amostras válidas de recursos comsample_no=2～2001são contabilizadas
Manual relacionado: Manual de testes de desempenho do Edge-EMS Builder
I. Visão geral dos resultados de desempenho
Seção intitulada “I. Visão geral dos resultados de desempenho”Carga configurada de aquisição
Operações de agregação
Meta de Trigger
Meta de tarefas MQTT
Tarefas de colaboração
Salvamento no máximo a cada 10 segundos
CPU do sistema completo — média / P95
Memória do sistema completo — média / P95
Trigger P95
MQTT P95
Cada execução de Trigger representa 1 controle de dispositivo, 1 alarme local e por MQTT e 1 gravação de dados agregados. O Edge-EMS Builder aloca recursos para o PostgreSQL conforme a memória do dispositivo; por isso, o uso pode variar significativamente entre dispositivos, volumes de banco de dados e estados de cache.
1.1 Conclusão principal
Seção intitulada “1.1 Conclusão principal”Recomenda-se operar o AFE-E630 no cenário S3.5: 5,000 pontos/segundo, 30 operações de agregação, 90 Trigger/segundo, 20 operações MQTT/segundo e 10 tarefas de colaboração/segundo, com armazenamento por alteração a cada 10 segundos.
No S3.5, foram medidos 89,97 Trigger/segundo e 19,98 operações MQTT/segundo; as latências P95 de Trigger / MQTT foram 56 ms e 77 ms. O P95 de CPU do sistema completo foi 71,09%, e o P95 de uso real de memória foi 41,41%, sem timeouts de amostragem nesse cenário.
Para produção de longo prazo, recomenda-se reservar cerca de 20% de margem de engenharia sobre a carga medida em S3.5, planejando inicialmente até aproximadamente 4,000 pontos/segundo, 72 Trigger/segundo, 16 operações MQTT/segundo e 8 tarefas de colaboração/segundo. Essa recomendação é uma estimativa de engenharia derivada da configuração medida, não um cenário testado separadamente. Antes da entrada em operação, repita os testes com os scripts, tamanhos de mensagem e volume histórico do banco de dados do projeto.
1.2 Estado de cada cenário
Seção intitulada “1.2 Estado de cada cenário”| Ícone | Cenário | Conclusão |
|---|---|---|
| 🟢 | S1 | Cenário de referência aprovado, com ampla margem de recursos e latência das tarefas. |
| 🟢 | S2 | Aprovado: operação estável a 2,000 pontos/segundo com armazenamento em tempo real; houve 1 timeout de amostragem. |
| 🟢 | S2.5 | Aprovado: o armazenamento por alteração reduz significativamente a pressão sobre a CPU em relação a S2, sem timeouts de amostragem. |
| 🟡 | S3 | Indicadores das tarefas aprovados, mas o P95 de CPU de 81,06% se aproxima do limite de operação contínua; houve 2 timeouts de amostragem. |
| 🟢 | S3.5 | Melhor desempenho geral; cenário atualmente recomendado para o AFE-E630. |
| 🔴 | S6 | Adequado apenas à verificação preliminar de estresse de curta duração; P95 de CPU de 94,02%, vazão MQTT abaixo da referência de 99% e 11 timeouts de amostragem. |
II. Resumo das conclusões
Seção intitulada “II. Resumo das conclusões”- Esta rodada testou seis cenários: S1, S2, S2.5, S3, S3.5 e S6. Os demais não são incluídos nas tabelas, comparações ou conclusões.
- No S3.5, com carga configurada de 5,000 pontos/segundo, as taxas de atendimento foram 99,97% para Trigger e 99,90% para MQTT; as latências P95 de Trigger / MQTT foram 56 ms e 77 ms.
- S3 e S3.5 têm a mesma carga de negócio. Com armazenamento por alteração, a CPU média do sistema completo caiu de 57,95% para 50,16%, e o P95 caiu de 81,06% para 71,09%, tornando S3.5 mais adequado à operação contínua.
- S6 atingiu 99,49% de atendimento de Trigger, mas apenas 98,73% de MQTT. O P95 de CPU foi 94,02%, com pico de 100%; não é recomendado como configuração de produção contínua.
- O P99 geral de Trigger ficou abaixo de 200 ms em todos os cenários, mas houve execuções isoladas de cerca de 10 a 12 segundos na cauda da distribuição. No S6, o P99 de MQTT foi 236,62 ms, acima de 200 ms.
- Cada cenário reteve apenas 2,000 segundos de amostras válidas, cerca de 33 minutos e 20 segundos. Isso permite comparar desempenho, mas não substitui um teste de estabilidade de 72 horas.
III. Critérios estatísticos
Seção intitulada “III. Critérios estatísticos”3.1 Seleção das amostras
Seção intitulada “3.1 Seleção das amostras”O monitoramento usa contagem de amostras. Os dados brutos de recursos de cada cenário contêm sample_no=1～2002:
Ignorar: sample_no = 1Contabilizar: sample_no = 2～2001, total de 2.000 amostrasIgnorar: sample_no = 2002Excluir a primeira e a última amostras evita incluir intervalos incompletos de um segundo no início e no fim. Os resultados gerais de Trigger e MQTT usam 2,000 segundos como denominador; segundos sem registros de tarefas também entram no cálculo da vazão média, evitando superestimá-la ao considerar apenas segundos com dados.
3.2 Escopo completo do EMS Builder
Seção intitulada “3.2 Escopo completo do EMS Builder”Os cinco serviços abaixo são considerados em conjunto como um Edge-EMS Builder completo:
| Serviço | Função |
|---|---|
cb_core |
Aquisição de dados e comunicação principal |
cb_nginx |
Web / proxy reverso do CommBridge |
cb_backend |
Backend do CommBridge |
ems_backend |
Cálculo, estratégias e lógica de negócio do EMS Builder |
ems_postgresql |
Armazenamento de dados do EMS Builder |
Para cada sample_no, os cinco serviços são somados primeiro; depois, os 2,000 totais são usados para calcular média, P95, P99 e pico. Não se somam diretamente picos individuais ocorridos em momentos diferentes.
3.3 CPU, memória e latência das tarefas
Seção intitulada “3.3 CPU, memória e latência das tarefas”- Os valores brutos de CPU dos cinco serviços são percentuais equivalentes a um núcleo. Como o AFE-E630 tem 4 núcleos, a “CPU equivalente a 4 núcleos do Edge-EMS Builder” = soma da CPU dos cinco serviços ÷ 4.
- A “CPU do sistema completo” usa
_system_totalda planilha, representando uso de 0 a 100% normalizado pela capacidade total de CPU. É o principal indicador para avaliar a capacidade do dispositivo. - A “memória atribuída ao Edge-EMS Builder” soma a memória atribuída aos cgroups dos cinco serviços. Páginas compartilhadas e cache podem ser atribuídos repetidamente, fazendo esse valor exceder a memória realmente usada pelo sistema; não se deve dividi-lo diretamente pela memória física para obter a ocupação da capacidade.
- A “memória real do sistema completo” é calculada por
MemTotal - MemAvailablee é o principal indicador da margem de memória física. - As médias e os percentis P50, P95 e P99 de Trigger / MQTT usam todos os registros de tarefas do intervalo válido, e não os percentis das médias por segundo.
- Todas as planilhas passaram pela verificação de “carga de teste desligada antes da consolidação”: Trigger, MQTT e CommBridge foram desligados e houve espera de 30 segundos antes da consolidação.
IV. Objeto e ambiente de teste
Seção intitulada “IV. Objeto e ambiente de teste”| Item | Configuração |
|---|---|
| Modelo do dispositivo | AFE-E630 |
| CPU | Arm Cortex-A55, 4 núcleos |
| Memória | 3,81 GB DDR4 |
| Sistema operacional | JelinaOS, baseado em Debian 11 |
| Armazenamento | eMMC |
| Versões de software | CommBridge-rc-2026-07-08T17-52-07; EMS Builder v1.2; PostgreSQL v18.3 |
| Rede | Rede local; MQTT / TCP |
| Amostragem de monitoramento | 1 coleta por segundo; 2,002 por cenário, com estatísticas das 2,000 centrais |
| Fontes dos dados de teste | perf_S1_20260729_171807.xlsx, perf_S2_20260729_175426.xlsx, perf_S2.5_20260729_183152.xlsx, perf_S3_20260729_190918.xlsx, perf_S3.5_20260729_194703.xlsx, perf_S6_20260729_202445.xlsx |
V. Cenários e cargas
Seção intitulada “V. Cenários e cargas”| Cenário | Aquisição de dados | Agregações | Trigger normal | Trigger de 100 ms | Meta de Trigger | Meta de MQTT | Tarefas de colaboração | Política de armazenamento |
|---|---|---|---|---|---|---|---|---|
| S1 | 500 pontos/segundo | 10 | 10/segundo | 0 | 10/segundo | 5/segundo | 0/segundo | Tempo real |
| S2 | 2,000 pontos/segundo | 20 | 20/segundo | 2 | 40/segundo | 10/segundo | 2/segundo | Tempo real |
| S2.5 | 2,000 pontos/segundo | 20 | 20/segundo | 2 | 40/segundo | 10/segundo | 2/segundo | Por alteração (10 segundos) |
| S3 | 5,000 pontos/segundo | 30 | 50/segundo | 4 | 90/segundo | 20/segundo | 10/segundo | Tempo real |
| S3.5 | 5,000 pontos/segundo | 30 | 50/segundo | 4 | 90/segundo | 20/segundo | 10/segundo | Por alteração (10 segundos) |
| S6 | 5,000 pontos/segundo | 20 | 50/segundo | 10 | 150/segundo | 30/segundo | 15/segundo | Tempo real |
“Aquisição de dados” é a carga configurada do cenário. A planilha atual não fornece contagens de sucesso por ponto; portanto, os valores configurados não podem ser descritos como vazão de gravação bem-sucedida no banco validada independentemente.
VI. Horários dos testes
Seção intitulada “VI. Horários dos testes”| Cenário | Intervalo estatístico válido | Duração válida |
|---|---|---|
| S1 | 2026-07-29 17:18:09 a 17:51:29 | 2,000 segundos |
| S2 | 2026-07-29 17:54:29 a 18:27:49 | 2,000 segundos |
| S2.5 | 2026-07-29 18:31:54 a 19:05:14 | 2,000 segundos |
| S3 | 2026-07-29 19:09:20 a 19:42:40 | 2,000 segundos |
| S3.5 | 2026-07-29 19:47:06 a 20:20:26 | 2,000 segundos |
| S6 | 2026-07-29 20:24:47 a 20:58:07 | 2,000 segundos |
Todos os horários acima estão em UTC+8.
VII. Resultados de CPU
Seção intitulada “VII. Resultados de CPU”7.1 Soma dos cinco serviços do EMS Builder (equivalente a 4 núcleos)
Seção intitulada “7.1 Soma dos cinco serviços do EMS Builder (equivalente a 4 núcleos)”| Estado | Cenário | Média | P95 | P99 | Pico |
|---|---|---|---|---|---|
| 🟢 | S1 | 13,48% | 23,97% | 41,50% | 62,53% |
| 🟢 | S2 | 28,47% | 48,33% | 56,36% | 67,17% |
| 🟢 | S2.5 | 26,11% | 38,36% | 49,96% | 65,76% |
| 🟡 | S3 | 50,58% | 72,31% | 78,55% | 95,43% |
| 🟢 | S3.5 | 43,50% | 61,27% | 70,93% | 86,75% |
| 🔴 | S6 | 65,95% | 85,87% | 91,61% | 208,59% |
O pico de 208,59% do Edge-EMS Builder no S6 é um valor anômalo de uma única janela de amostragem, em que o tempo total de CPU dos cinco serviços excede a capacidade convencional de 4 núcleos. Considerando os 11 timeouts de amostragem desse cenário, pode haver janelas abrangendo mais de um período ou picos de escalonamento. Esse valor não é tratado como uso sustentado de recursos.
7.2 CPU do sistema completo (normalizada pela capacidade total)
Seção intitulada “7.2 CPU do sistema completo (normalizada pela capacidade total)”| Estado | Cenário | Média | P95 | P99 | Pico |
|---|---|---|---|---|---|
| 🟢 | S1 | 20,22% | 38,67% | 48,57% | 67,70% |
| 🟢 | S2 | 35,88% | 57,58% | 66,41% | 82,42% |
| 🟢 | S2.5 | 32,72% | 45,28% | 57,03% | 75,06% |
| 🟡 | S3 | 57,95% | 81,06% | 89,16% | 98,64% |
| 🟢 | S3.5 | 50,16% | 71,09% | 79,84% | 96,98% |
| 🔴 | S6 | 73,86% | 94,02% | 97,95% | 100,00% |
A CPU do sistema completo é o principal critério deste relatório para avaliar a capacidade de CPU. O P95 de S3.5 é 9,97 pontos percentuais menor que o de S3; o P95 de S6 excede 90%, sem margem suficiente para operação contínua.
VIII. Resultados de memória
Seção intitulada “VIII. Resultados de memória”| Estado | Cenário | Memória atribuída ao EMS Builder — média | Memória atribuída ao EMS Builder — P95 | Memória real do sistema completo — média | Memória real do sistema completo — P95 | Memória real do sistema completo — pico |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 2.666,77 MB | 2.704,44 MB | 1.550,46 MB（39,74%） | 1.637,29 MB（41,97%） | 1.694,09 MB（43,42%） |
| 🟢 | S2 | 2.805,86 MB | 2.895,39 MB | 1.579,23 MB（40,48%） | 1.675,40 MB（42,94%） | 1.736,57 MB（44,51%） |
| 🟢 | S2.5 | 2.881,41 MB | 2.933,45 MB | 1.507,67 MB（38,64%） | 1.596,94 MB（40,93%） | 1.667,61 MB（42,74%） |
| 🟡 | S3 | 3.067,36 MB | 3.119,55 MB | 1.591,41 MB（40,79%） | 1.684,10 MB（43,17%） | 1.759,92 MB（45,11%） |
| 🟢 | S3.5 | 3.059,29 MB | 3.106,37 MB | 1.579,83 MB（40,49%） | 1.615,76 MB（41,41%） | 1.702,34 MB（43,63%） |
| 🔴 | S6 | 3.071,13 MB | 3.123,09 MB | 1.636,22 MB（41,94%） | 1.721,25 MB（44,12%） | 1.791,94 MB（45,93%） |
A memória atribuída aos cinco serviços inclui páginas compartilhadas e cache atribuídos por cgroup, não equivalendo ao consumo líquido de memória física. A memória real do sistema completo representa melhor a capacidade restante e é usada na avaliação dos cenários. O estado inicial do banco de dados e o aquecimento do cache afetam os resultados; não se deve inferir a variação da memória apenas pelo número de pontos.
IX. Resultados de vazão
Seção intitulada “IX. Resultados de vazão”A vazão média usa o intervalo válido completo de 2,000 segundos como denominador. A taxa de atendimento é calculada pelo total de tarefas dividido pelo total previsto, evitando desvios por arredondamento dos valores exibidos nas planilhas.
| Estado | Cenário | Total de Trigger | Trigger — média / meta | Atendimento de Trigger | Total de MQTT | MQTT — média / meta | Atendimento de MQTT |
|---|---|---|---|---|---|---|---|
| 🟢 | S1 | 20.000 | 10,00 / 10 | 100,00% | 10.000 | 5,00 / 5 | 100,00% |
| 🟢 | S2 | 79.990 | 40,00 / 40 | 99,99% | 19.995 | 10,00 / 10 | 99,98% |
| 🟢 | S2.5 | 79.990 | 40,00 / 40 | 99,99% | 20.000 | 10,00 / 10 | 100,00% |
| 🟡 | S3 | 179.788 | 89,89 / 90 | 99,88% | 39.800 | 19,90 / 20 | 99,50% |
| 🟢 | S3.5 | 179.943 | 89,97 / 90 | 99,97% | 39.960 | 19,98 / 20 | 99,90% |
| 🔴 | S6 | 298.469 | 149,23 / 150 | 99,49% | 59.239 | 29,62 / 30 | 98,73% |
Este relatório usa 99% como referência de vazão para recomendar um cenário operacional. O MQTT de S6 ficou abaixo dela, com CPU elevada, aumento da latência e timeouts de amostragem simultâneos, indicando que essa carga já está na região de estresse.
X. Latência de Trigger
Seção intitulada “X. Latência de Trigger”Os percentis abaixo usam todos os registros de tarefas Trigger do intervalo válido, em milissegundos.
| Estado | Cenário | Média | P50 | P95 | P99 | Máximo individual |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 47,86 | 19 | 32 | 47 | 10.160 |
| 🟢 | S2 | 23,65 | 11 | 30 | 53 | 10.938 |
| 🟢 | S2.5 | 26,06 | 17 | 46 | 69 | 10.938 |
| 🟡 | S3 | 37,69 | 14 | 55 | 99 | 10.993 |
| 🟢 | S3.5 | 29,88 | 15 | 56 | 88 | 10.994 |
| 🔴 | S6 | 44,06 | 17 | 87 | 162 | 11.985 |
Os percentis usuais são baixos, mas todos os cenários apresentam execuções extremas isoladas de cerca de 10 a 12 segundos na cauda. Elas pouco alteram o P99, mas podem afetar tarefas individuais de controle ou alarme e exigem investigação específica.
XI. Latência de MQTT
Seção intitulada “XI. Latência de MQTT”Os percentis abaixo usam todos os registros de tarefas MQTT do intervalo válido, em milissegundos.
| Estado | Cenário | Média | P50 | P95 | P99 | Máximo individual |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 57,90 | 57 | 65 | 73 | 122 |
| 🟢 | S2 | 57,83 | 57 | 67 | 76 | 115 |
| 🟢 | S2.5 | 57,13 | 56 | 65 | 74 | 330 |
| 🟡 | S3 | 62,31 | 58 | 89 | 146 | 340 |
| 🟢 | S3.5 | 58,60 | 57 | 77 | 98 | 220 |
| 🔴 | S6 | 74,79 | 64 | 134 | 236,62 | 920 |
XII. Avaliação dos cenários
Seção intitulada “XII. Avaliação dos cenários”| Cenário | Avaliação | Fundamentação principal |
|---|---|---|
| S1 | Aprovado | Na carga de referência, o P95 de CPU foi 38,67%, o P95 de memória foi 41,97%, e a vazão das tarefas atingiu a meta. |
| S2 | Aprovado | Trigger e MQTT ficaram próximos de 100% de atendimento, com ampla margem de recursos; deve-se observar o único timeout de amostragem. |
| S2.5 | Aprovado | A vazão atingiu a meta; com armazenamento por alteração, a média e o P95 de CPU ficaram significativamente abaixo de S2. |
| S3 | Aprovado com condições | Vazão e latência das tarefas atendem às metas, mas o P95 de CPU foi 81,06%, com 2 timeouts de amostragem e pouca margem para operação contínua. |
| S3.5 | Recomendado | Com 5,000 pontos/segundo, os P95 de Trigger / MQTT ficaram abaixo de 100 ms; P95 de CPU de 71,09%, P95 de memória real de 41,41% e nenhum timeout de amostragem. |
| S6 | Não recomendado para operação contínua | Atendimento de MQTT de 98,73%, P99 de 236,62 ms, P95 de CPU de 94,02% e 11 timeouts de amostragem. |
XIII. Recomendações de capacidade e implantação
Seção intitulada “XIII. Recomendações de capacidade e implantação”13.1 Configuração recomendada validada
Seção intitulada “13.1 Configuração recomendada validada”- Carga configurada de aquisição de dados: 5,000 pontos/segundo;
- Operações de agregação: 30;
- Trigger normal: 50/segundo;
- Trigger de 100 ms: 4, equivalentes a 40/segundo;
- Total de Trigger: 90/segundo;
- MQTT: 20/segundo;
- Tarefas de colaboração: 10/segundo;
- Registros de tarefas Trigger: habilitados;
- Armazenamento por alteração, com salvamento no máximo a cada 10 segundos quando o valor não muda.
13.2 Recomendações para produção
Seção intitulada “13.2 Recomendações para produção”- Para operação de longo prazo, reserve cerca de 20% de margem de engenharia sobre a configuração medida e repita os testes antes da entrada em operação com scripts Lua, tamanhos de mensagem e volume histórico do banco reais.
- Recomenda-se aviso de CPU do sistema completo em 80%, aviso de memória em 70% e alarme crítico em 80%, com acompanhamento contínuo do cache PostgreSQL e do crescimento do banco.
- Se o armazenamento em tempo real for necessário, use S3 como referência, considerando que seu P95 de CPU já ultrapassou 80%. Se não houver exigência de negócio, prefira o armazenamento por alteração de S3.5.
- Use S6 apenas para testes curtos de estresse, limitação de taxa ou proteção contra sobrecarga; não é recomendado como carga contínua de produção no E630.
XIV. Alertas de qualidade e testes pendentes
Seção intitulada “XIV. Alertas de qualidade e testes pendentes”- Houve 1 timeout de amostragem em S2, 2 em S3 e 11 em S6. Nenhum foi identificado em S1, S2.5 ou S3.5.
- Execute integralmente um teste de estabilidade de 72 horas, registrando reinicializações de processos, OOM, erros, tendência de crescimento da memória e crescimento do banco.
- Adicione contadores de sucesso, falha, timeout e descarte para pontos de aquisição, Trigger, MQTT e tarefas de colaboração.
- Complemente medições de vazão de disco, I/O wait, WAL / checkpoint do PostgreSQL, pools de conexão e profundidade de filas.
- Correlacione os eventos isolados de 10 a 12 segundos de Trigger com IDs de tarefas, scripts Lua, SQL, GC, I/O e logs do sistema.
- Registre tamanho do banco, configurações do PostgreSQL e aquecimento do cache antes de cada cenário para tornar os resultados de memória mais comparáveis.
XV. Limitações dos dados
Seção intitulada “XV. Limitações dos dados”- A quantidade de pontos é a carga configurada do teste, não uma contagem de sucesso por ponto; os dados disponíveis não comprovam independentemente a gravação bem-sucedida de cada ponto.
- As planilhas não têm campos de taxa de erro de negócio, estado de resultado das tarefas ou exatidão. Atingir a vazão não significa 100% de correção de negócio.
- Todos os cenários desta rodada são testes curtos, de cerca de 33 minutos e 20 segundos, adequados à comparação de desempenho e não substitutos de testes de estabilidade de longo prazo.
- S3.5 é a configuração testada com os melhores indicadores gerais desta rodada. A margem de engenharia de 20% é uma recomendação de planejamento, não um resultado medido separadamente.
Para outros modelos, consulte o Relatório de testes do AFE-E620.