Relatório de testes de desempenho do EMS Builder no AFE-E620
Versão do relatório: v1.0
Período dos testes: 2026-07-30 a 2026-07-31
Data do relatório: 2026-07-31
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. Com apenas 982 MB de memória física, o AFE-E620 tem margem muito menor que o AFE-E630, e a memória deve ser a prioridade no planejamento de capacidade.
1.1 Conclusão principal
Seção intitulada “1.1 Conclusão principal”Recomenda-se operar o AFE-E620 no cenário S2.5: 2,000 pontos/segundo, 20 operações de agregação, 40 execuções de Trigger/segundo, 10 operações MQTT/segundo e 2 tarefas de colaboração/segundo, com armazenamento por alteração a cada 10 segundos.
No S2.5, foram medidos 39,96 Trigger/segundo e 9,98 operações MQTT/segundo, com taxas de atendimento de 99,91% e 99,82%, respectivamente; as latências P95 de Trigger / MQTT foram 25 ms e 56 ms. O P95 da CPU do sistema completo foi 45,54%, e o P95 de uso real de memória foi 86,10%. Houve 8 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 S2.5, planejando inicialmente até aproximadamente 1,600 pontos/segundo, 32 Trigger/segundo, 8 operações MQTT/segundo e 2 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 atendimento de 100%; porém, o uso médio de memória do sistema completo já atingiu 74,02%, indicando uma base elevada. |
| 🟡 | S2 | Com armazenamento em tempo real, as taxas de atendimento de Trigger / MQTT foram 98,65% / 98,76%, ligeiramente abaixo da referência de 99%, com 34 timeouts de amostragem. |
| 🟢 | S2.5 | Maior carga que atingiu a referência de 99%; cenário atualmente recomendado para o AFE-E620. |
| 🔴 | S3 | Reprovado: atendimento de Trigger / MQTT de apenas 43,08% / 44,65%, piora acentuada da latência e 617 timeouts de amostragem. |
| 🔴 | S3.5 | Reprovado: o armazenamento por alteração melhorou significativamente o S3, mas as taxas de 87,30% / 86,69% ainda ficaram abaixo da referência de 99%. |
| 🔴 | S6 | Sobrecarga severa: atendimento de Trigger / MQTT de apenas 19,15% / 19,18%, com 886 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 S2.5, com carga configurada de 2,000 pontos/segundo, as taxas de atendimento foram 99,91% para Trigger e 99,82% para MQTT; as latências P95 de Trigger / MQTT foram 25 ms e 56 ms.
- S2 e S2.5 têm a mesma carga de negócio. Com armazenamento por alteração, a CPU média do sistema completo caiu de 29,41% para 26,24%, o P95 caiu de 52,01% para 45,54%, e a taxa de atendimento de Trigger subiu de 98,65% para 99,91%.
- S3 e S3.5 têm a mesma carga de negócio. Com armazenamento por alteração, o atendimento de Trigger subiu de 43,08% para 87,30%, o de MQTT subiu de 44,65% para 86,69%, e o P95 de CPU caiu de 82,71% para 66,05%. Ainda assim, o cenário foi reprovado: 5,000 pontos/segundo excedem a capacidade sustentada do AFE-E620.
- Comparação com o AFE-E630: o E630 suporta S3.5 (5,000 pontos/segundo, 90 Trigger/segundo), enquanto o limite validado do E620 é S2.5 (2,000 pontos/segundo, 40 Trigger/segundo). A diferença de memória — 3,81 GB contra 982 MB — é o principal fator.
- Todos os cenários apresentaram execuções isoladas de Trigger na cauda da distribuição, com cerca de 10 a 11 segundos. Sob sobrecarga, esses extremos aumentaram: no S3.5, o máximo individual foi 53,472 ms para Trigger e 53,373 ms para MQTT.
- O uso médio de memória do sistema completo ultrapassou 74% em todos os cenários, e o P95 excedeu 91% a partir de S3. A memória é um gargalo comum a todos os cenários do E620 e exige monitoramento contínuo.
- 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-E620 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. Os percentuais deste relatório usam MemTotal = 982 MB. - 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-E620 |
| CPU | Arm Cortex-A55, 4 núcleos |
| Memória | 982 MB DDR3 |
| Sistema operacional | JelinaOS, baseado em Ubuntu 20,04 |
| Armazenamento | eMMC |
| Versões de software | A complementar; as planilhas desta rodada não registraram as versões de CommBridge / EMS Builder / PostgreSQL, que devem ser incluídas antes do arquivamento |
| 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_20260730_101351.xlsx, perf_S2_20260730_105126.xlsx, perf_S2.5_20260730_113029.xlsx, perf_S3_20260730_152548.xlsx, perf_S3.5_20260731_122356.xlsx, perf_S6_20260731_173626.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, definida conforme o manual de testes. As planilhas não fornecem contagens de sucesso por ponto nem detalhes de configuração por cenário. Portanto, os valores configurados não podem ser descritos como vazão de gravação bem-sucedida no banco validada independentemente. As metas de Trigger / MQTT correspondem às usadas na verificação das taxas de atendimento das planilhas.
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-30 10:13:55 a 10:47:13 | 2,000 segundos |
| S2 | 2026-07-30 10:51:30 a 11:24:48 | 2,000 segundos |
| S2.5 | 2026-07-30 11:30:33 a 12:03:51 | 2,000 segundos |
| S3 | 2026-07-30 15:25:51 a 15:59:09 | 2,000 segundos |
| S3.5 | 2026-07-31 12:23:59 a 12:57:17 | 2,000 segundos |
| S6 | 2026-07-31 17:36:29 a 18:09:47 | 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 | 9,87% | 19,19% | 27,73% | 32,42% |
| 🟡 | S2 | 22,39% | 41,93% | 51,69% | 110,22% |
| 🟢 | S2.5 | 19,86% | 36,67% | 47,88% | 75,63% |
| 🔴 | S3 | 32,80% | 57,33% | 71,41% | 115,84% |
| 🔴 | S3.5 | 32,25% | 52,81% | 64,87% | 130,65% |
| 🔴 | S6 | 30,90% | 63,74% | 77,34% | 99,06% |
Os picos do Edge-EMS Builder em S2, S3 e S3.5 foram 110,22%, 115,84% e 130,65%, respectivamente. São valores instantâneos de uma janela de amostragem, nos quais o tempo total de CPU dos cinco serviços excede a capacidade convencional de 4 núcleos; por exemplo, no S2, ems_backend atingiu 402% em uma única amostra. Considerando os timeouts de amostragem, pode haver janelas abrangendo mais de um período ou picos de escalonamento. Esses valores não são tratados 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 | 15,27% | 26,83% | 34,00% | 50,88% |
| 🟡 | S2 | 29,41% | 52,01% | 70,29% | 100,00% |
| 🟢 | S2.5 | 26,24% | 45,54% | 58,41% | 97,05% |
| 🔴 | S3 | 48,29% | 82,71% | 97,18% | 100,00% |
| 🔴 | S3.5 | 41,32% | 66,05% | 90,63% | 100,00% |
| 🔴 | S6 | 49,35% | 88,33% | 98,30% | 100,00% |
A CPU do sistema completo é o principal critério deste relatório para avaliar a capacidade de CPU. O P95 de S2.5 é 6,47 pontos percentuais menor que o de S2; a partir de S3, todos os P95 excedem 66% e os picos atingem 100%, indicando saturação da CPU.
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 | 484,14 MB | 529,22 MB | 726,92 MB（74,02%） | 810,83 MB（82,57%） | 825,71 MB（84,08%） |
| 🟡 | S2 | 567,86 MB | 589,11 MB | 788,52 MB（80,30%） | 878,61 MB（89,47%） | 900,03 MB（91,65%） |
| 🟢 | S2.5 | 562,11 MB | 580,93 MB | 785,65 MB（80,01%） | 845,52 MB（86,10%） | 918,53 MB（93,54%） |
| 🔴 | S3 | 573,27 MB | 603,92 MB | 843,22 MB（85,87%） | 930,97 MB（94,80%） | 938,00 MB（95,52%） |
| 🔴 | S3.5 | 560,39 MB | 590,84 MB | 838,25 MB（85,36%） | 902,91 MB（91,95%） | 937,29 MB（95,45%） |
| 🔴 | S6 | 549,24 MB | 608,00 MB | 827,91 MB（84,31%） | 932,14 MB（94,92%） | 939,57 MB（95,68%） |
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 AFE-E620 tem apenas 982 MB de memória física: no cenário de referência S1, a média já chega a 74,02%, indicando que o sistema operacional e o Edge-EMS Builder ocupam permanentemente quase três quartos da capacidade. A partir de S3, o P95 ultrapassa 91%, restando menos de 90 MB disponíveis, em uma região de pressão de memória. 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 | 78.917 | 39,46 / 40 | 98,65% | 19.752 | 9,88 / 10 | 98,76% |
| 🟢 | S2.5 | 79.924 | 39,96 / 40 | 99,91% | 19.964 | 9,98 / 10 | 99,82% |
| 🔴 | S3 | 77.536 | 38,77 / 90 | 43,08% | 17.860 | 8,93 / 20 | 44,65% |
| 🔴 | S3.5 | 157.134 | 78,57 / 90 | 87,30% | 34.676 | 17,34 / 20 | 86,69% |
| 🔴 | S6 | 57.442 | 28,72 / 150 | 19,15% | 11.508 | 5,75 / 30 | 19,18% |
Este relatório usa 99% como referência de vazão para recomendar um cenário operacional. S2 fica ligeiramente abaixo dela; S3, S3.5 e S6 já apresentam capacidade de processamento claramente insuficiente. Sob sobrecarga, as filas se acumulam continuamente e o volume concluído fica muito abaixo da meta.
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 | 15,57 | 12 | 18 | 30 | 10.237 |
| 🟡 | S2 | 22,98 | 9 | 28 | 61 | 11.012 |
| 🟢 | S2.5 | 17,28 | 9 | 25 | 40 | 10.999 |
| 🔴 | S3 | 70,61 | 17 | 120 | 713,65 | 27.281 |
| 🔴 | S3.5 | 76,65 | 13 | 58 | 170 | 53.472 |
| 🔴 | S6 | 71,90 | 17 | 127 | 610,59 | 24.421 |
Os percentis usuais de S2.5 e dos cenários inferiores são baixos, mas todos apresentam eventos extremos isolados de cerca de 10 a 11 segundos na cauda. Sob sobrecarga, esses extremos elevam significativamente a média; por exemplo, no S3.5, a média de 76,65 ms supera o P95 de 58 ms, enquanto o P50 é apenas 13 ms. Para avaliar a experiência usual, priorize P50 / P95. Esses extremos 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 | 49,65 | 49 | 52 | 56 | 440 |
| 🟡 | S2 | 54,77 | 51 | 64 | 90 | 1.182 |
| 🟢 | S2.5 | 51,80 | 52 | 56 | 64 | 402 |
| 🔴 | S3 | 93,56 | 56 | 249,05 | 944,41 | 2.471 |
| 🔴 | S3.5 | 109,53 | 55 | 95 | 242 | 53.373 |
| 🔴 | S6 | 95,33 | 59 | 201 | 782 | 19.969 |
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, Trigger / MQTT atingiram 100% de atendimento, com P95 de CPU de 26,83%; observe que a memória média do sistema completo já atingiu 74,02%. |
| S2 | Aprovado com condições | A margem de recursos é aceitável, com P95 de CPU de 52,01%, mas o atendimento de Trigger / MQTT de 98,65% / 98,76% fica ligeiramente abaixo de 99%, com 34 timeouts de amostragem. |
| S2.5 | Recomendado | Com 2,000 pontos/segundo, Trigger / MQTT atingiram 99,91% / 99,82%, com P95 de 25 ms e 56 ms e P95 de CPU de 45,54%. É a maior carga que atingiu a referência. |
| S3 | Reprovado | Atendimento de Trigger / MQTT de apenas 43,08% / 44,65%, P99 de MQTT de 944,41 ms, P95 de CPU de 82,71%, P95 de memória de 94,80% e 617 timeouts de amostragem. |
| S3.5 | Reprovado | O armazenamento por alteração melhora significativamente o S3, reduzindo o P95 de CPU para 66,05% e o de Trigger para 58 ms, mas o atendimento de 87,30% / 86,69% continua abaixo da referência, com 96 timeouts de amostragem. |
| S6 | Não recomendado para qualquer uso em produção | Atendimento de apenas 19,15% / 19,18%, P95 de CPU de 88,33%, P95 de memória de 94,92% e 886 timeouts de amostragem; o dispositivo está severamente sobrecarregado. |
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: 2,000 pontos/segundo;
- Operações de agregação: 20;
- Trigger normal: 20/segundo;
- Trigger de 100 ms: 2, equivalentes a 20/segundo;
- Total de Trigger: 40/segundo;
- MQTT: 10/segundo;
- Tarefas de colaboração: 2/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.
- O AFE-E620 tem uma base elevada de memória, acima de 74% em média no cenário de referência S1. Recomenda-se aviso de CPU em 80%, aviso de memória em 85% e alarme crítico em 90%, com acompanhamento contínuo do cache PostgreSQL e do crescimento do banco. Se necessário, avalie reduzir a cota de memória do PostgreSQL ou migrar para um modelo de maior capacidade.
- Se o armazenamento em tempo real for necessário, use S2 como referência, considerando que seu atendimento ficou ligeiramente abaixo de 99%. Se não houver exigência de negócio, prefira o armazenamento por alteração de S2.5.
- Cargas a partir de S3, com 5,000 pontos/segundo, excedem a capacidade sustentada do AFE-E620, mesmo com armazenamento por alteração em S3.5. Para essa demanda, use o AFE-E630.
- S6 causa sobrecarga severa no E620 e não serve como referência útil para uma verificação preliminar de estresse. Para validar proteção contra sobrecarga, recomenda-se executar brevemente uma carga da ordem de S3.
XIV. Alertas de qualidade e testes pendentes
Seção intitulada “XIV. Alertas de qualidade e testes pendentes”- Timeouts de amostragem: 3 em S1, 34 em S2, 8 em S2.5, 617 em S3, 96 em S3.5 e 886 em S6. Sob sobrecarga, o próprio monitoramento não consegue concluir as amostras no prazo, reduzindo a confiabilidade dos dados de recursos. Nesses cenários, a avaliação prioriza vazão e latência.
- Complementar as versões de CommBridge / Edge-EMS Builder / PostgreSQL usadas nesta rodada para completar as informações do ambiente.
- Executar 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. Como o E620 já parte de uma base alta, observar especialmente aumentos lentos de memória.
- Adicionar contadores de sucesso, falha, timeout e descarte para pontos de aquisição, Trigger, MQTT e tarefas de colaboração.
- Complementar medições de vazão de disco, I/O wait, WAL / checkpoint do PostgreSQL, pools de conexão e profundidade de filas.
- Investigar a cauda de 10 a 11 segundos de Trigger e os extremos simultâneos de cerca de 53 segundos de Trigger e MQTT no S3.5, correlacionando IDs de tarefas, scripts Lua, SQL, GC, I/O e logs do sistema.
- Registrar 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 configurações de negócio dos cenários — quantidade de agregações, composição de Trigger e tarefas de colaboração — seguem o manual de testes; as planilhas não registram os detalhes de cada cenário.
- 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.
- As versões de software não foram registradas nas planilhas; sua associação com os resultados precisa ser confirmada após a complementação.
- S2.5 é a maior carga testada desta rodada que atingiu a referência de 99% de vazão. 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-E630.