A maioria das afirmações de desempenho no mercado de motores de regras não pode ser verificada. Expressões como “tempos de resposta abaixo de um segundo”, “escala massiva” e “throughput de nível empresarial” são comuns, mas ajudam pouco na elaboração de um plano de capacidade.
Para obter números reais, medimos o comportamento do DecisionRules no Kubernetes usando tabelas de decisão como caso de teste. Todos os números deste documento vêm de testes de carga reais, não de estimativas teóricas.
Resumo rápido:
- Uma regra de complexidade média é resolvida, em média, em menos de 3 milissegundos.
- Sob carga máxima, a mesma plataforma processa mais de 100.000 decisões por segundo, com latência média de 10 milissegundos.
- Throughput e latência nem sempre são excludentes quando há escalabilidade horizontal adequada.
Resumo das métricas de desempenho verificadas
| Metric | Value | Conditions | |
|---|---|---|---|
| Median latency – decision tables | 2.94 ms | 500 req/s, 3 case avg (small/middle/large) | |
| Median latency – decision trees | 2.59 ms | 500 req/s, 3 case avg | |
| Median latency – script rules | 7.84 ms | 500 req/s, data transformation use case | |
| Median latency – workflows (small) | 3.35 ms | 500 req/s, 3 case avg | |
| Median latency – workflows (medium/large) | 4.98 ms | 500 req/s, 3 case avg | |
| Blended median latency | 3.83 ms | 500 req/s, 13 test cases | |
| Blended p95 latency | 5.29 ms | 500 req/s, 13 test cases | |
| Best case – small decision tree | 1.51 ms | Package-delivery-pricing example | |
| Worst case – script rule p95 | 10.58 ms | Data transformation | |
| Worst case – non-script rule p95 | 9.87 ms | Sequential decision flow | |
| Peak throughput | ~106,000 req/s | 600 VUs, 10 min ramp, small decision table | |
| Median latency at peak throughput | 10.0 ms | 600 VUs, unlimited throughput | |
| Minimum latency at peak throughput | 1.5 ms | 600 VUs, unlimited throughput | |
| Throughput per instance per minute | 2,120,000 reqs | 600 VUs, unlimited throughput | |
| Requests served in 10 minutes | 63,600,000 reqs | 600 VUs, unlimited throughput |
O que testamos e como
- Implantação: cluster Kubernetes sem escalabilidade automática
- Região: geradores de carga e cluster na mesma região da AWS
- Validação: somente solicitações que retornaram HTTP 200 e passaram pela validação de conteúdo foram consideradas bem-sucedidas
Tipos de regras testados:
- Tabelas de decisão pequenas, médias e grandes
- Scripting Rules para transformação de dados
- Workflows pequenos e grandes
- Decision Flows executando de 1 a 10 regras por execução
Todas as solicitações passaram pela validação e a taxa de erros foi de 0%.
Ambiente usado nos testes
Números brutos significam pouco sem as especificações. Estas são as características do ambiente:
Ambiente de teste
| Application nodes | 3 × c7g.xlarge (4 vCPU, 8 GiB RAM) |
|---|---|
| In-memory cache | Enabled |
| Redis | cache.t4g.micro |
| Load generator | 1 × m7i.2xlarge (K6) |
Os testes foram executados em um ambiente fixo da AWS com três nós de aplicação baseados em instâncias Graviton (ARM) e um nó adicional para o Redis. Neste teste, o Redis teve pouco trabalho porque o cache em memória estava ativado: as regras permaneceram na memória e não foram atualizadas durante os testes, mantendo baixa a carga do Redis. Todos os testes partiram de uma instância do k6 no mesmo ambiente para evitar ruído adicional nos resultados.
Como usar estes números
Ao dimensionar uma implantação. O throughput máximo superou 35.000 solicitações por segundo por nó. O resultado dependerá das regras executadas no DecisionRules e dos requisitos de desempenho da aplicação. Podemos ajudar a definir a configuração e a escalabilidade ideais para cada caso.
Se você tiver um SLA de latência. Em todas as regras testadas, o p95 permaneceu abaixo de 10 ms com 500 solicitações por segundo. Esse valor pode ser ajustado alterando a configuração para regras específicas ou adicionando escalabilidade.
Ao projetar a lógica de decisão. Consolide as chamadas. Executar 10 regras dentro de um fluxo pode levar apenas cerca de duas vezes o tempo de uma regra, pois a viagem de ida e volta pela rede ocorre uma única vez.
Ao comparar motores. Compare distribuições de percentis, não médias. É fácil obter uma boa média sendo rápido no caminho ideal. A diferença entre p50 e p95 mostra se o sistema cria filas — e filas são o que comprometem sistemas em produção.
Escopo e limitações
Os resultados se baseiam em uma configuração fixa e em uma implantação dentro da mesma região. Considere os seguintes pontos:
- Tamanho do payload: ao processar mais de 10 milhões de solicitações por minuto, o tamanho dos dados importa.
- A latência de rede não está incluída: chamadas entre regiões acrescentam tempo.
- São resultados reais medidos, não máximos teóricos.
- Eles se aplicam ao conjunto específico de regras e ao ambiente testado.
Conclusão
Estes testes reais mostram que o DecisionRules escala para um throughput elevado mantendo latência baixa e consistente, zero erros e alta confiabilidade.
Seja para avaliar um novo motor, projetar um sistema empresarial ou planejar milhões de decisões diárias, essas medições trazem clareza e confiança à tomada de decisão.
Ondřej Brejla trabalha na DecisionRules, onde ajuda empresas a projetar e implementar soluções de automação de decisões que tiram as regras de negócio de sistemas codificados e as colocam em um formato que as equipes de negócio podem gerenciar diretamente. Ele foca em regras de negócio, integrações de sistemas e em ajudar equipes de tecnologia a projetar processos nos quais os usuários de negócio possam assumir a responsabilidade por partes das aplicações.
