La mayoría de las afirmaciones sobre rendimiento en el mercado de motores de reglas no se pueden verificar. Expresiones como “tiempos de respuesta inferiores a un segundo”, “escalabilidad masiva” o “throughput de nivel empresarial” son habituales, pero sirven de poco al elaborar un plan de capacidad.
Para obtener cifras reales, medimos el comportamiento de DecisionRules en Kubernetes utilizando tablas de decisión como caso de prueba. Todos los datos de este documento proceden de pruebas de carga reales, no de estimaciones teóricas.
Resumen rápido:
- Una regla de complejidad media se resuelve, en promedio, en menos de 3 milisegundos.
- Con la carga máxima, la misma plataforma procesa más de 100 000 decisiones por segundo, con una latencia media de 10 milisegundos.
- El throughput y la latencia no siempre son incompatibles si se aplica un escalado horizontal adecuado.
Resumen de métricas de rendimiento 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 |
Qué probamos y cómo
- Despliegue: clúster de Kubernetes sin autoescalado activado
- Región: generadores de carga y clúster en la misma región de AWS
- Validación: solo se consideraron correctas las solicitudes que devolvieron HTTP 200 y superaron la validación del contenido
Tipos de reglas probados:
- Tablas de decisión pequeñas, medianas y grandes
- Scripting Rules para la transformación de datos
- Workflows pequeños y grandes
- Decision Flows que ejecutaban entre 1 y 10 reglas por ejecución
Todas las solicitudes superaron la validación y la tasa de errores fue del 0 %.
Entorno utilizado para las pruebas
Las cifras sin especificaciones aportan poco contexto. Estas son las características del entorno:
Entorno de prueba
| Application nodes | 3 × c7g.xlarge (4 vCPU, 8 GiB RAM) |
| In-memory cache | Enabled |
| Redis | cache.t4g.micro |
| Load generator | 1 × m7i.2xlarge (K6) |
Las pruebas se ejecutaron en un entorno fijo de AWS con tres nodos de aplicación basados en instancias Graviton (ARM) y un nodo adicional para Redis. En esta prueba Redis apenas necesitó trabajar porque estaba activada la caché en memoria: las reglas se mantenían en memoria y no se actualizaban durante las pruebas, por lo que la carga de Redis permaneció baja. Todas las pruebas se lanzaron desde una instancia de k6 ubicada en el mismo entorno para no introducir ruido adicional en los resultados.
Cómo utilizar estas cifras
Para dimensionar un despliegue. El throughput máximo superó las 35 000 solicitudes por segundo y por nodo. El resultado dependerá de las reglas concretas que se ejecuten en DecisionRules y de los requisitos de rendimiento de la aplicación. Podemos ayudarle a determinar la configuración y el escalado adecuados para su caso.
Si tiene un SLA de latencia. En todas las reglas probadas, el p95 se mantuvo por debajo de 10 ms al enviar 500 solicitudes por segundo. Este valor puede ajustarse modificando la configuración según las reglas específicas o introduciendo escalado.
Si diseña lógica de decisión. Consolide las llamadas. Ejecutar 10 reglas dentro de un flujo puede costar solo unas dos veces más que evaluar una regla, porque el viaje de ida y vuelta por la red se realiza una sola vez.
Si compara motores. Compare distribuciones de percentiles, no promedios. Es fácil obtener un buen promedio siendo rápido en el caso ideal. La diferencia entre p50 y p95 revela si el sistema genera colas, y las colas son lo que rompe los sistemas en producción.
Alcance y limitaciones
Estos resultados se basan en una configuración fija y un despliegue dentro de la misma región. Conviene considerar lo siguiente:
- Tamaño del payload: al procesar más de 10 millones de solicitudes por minuto, el tamaño de los datos importa.
- La latencia de red no está incluida: las llamadas entre regiones añadirán tiempo.
- Son resultados medidos reales, no máximos teóricos.
- Se aplican al conjunto de reglas específico utilizado y al entorno probado.
Conclusión
Estas pruebas reales demuestran que DecisionRules puede escalar hasta un throughput elevado manteniendo una latencia baja y constante, cero errores y una fiabilidad sólida.
Tanto si evalúa un motor nuevo como si diseña un sistema empresarial o planifica millones de decisiones diarias, estas mediciones aportan claridad y confianza a la toma de decisiones.
Ondřej Brejla trabaja en DecisionRules, donde ayuda a las empresas a diseñar e implementar soluciones de automatización de decisiones que sacan las reglas de negocio de sistemas con lógica codificada y las transforman en un formato que los equipos de negocio pueden gestionar directamente. Se enfoca en reglas de negocio, integraciones de sistemas y en ayudar a los equipos tecnológicos a diseñar procesos en los que los usuarios de negocio puedan asumir la propiedad de partes de las aplicaciones.
