hub - Usar Drools en un proceso por lotes pesado
jbpm (9)
No he trabajado con la última versión de Drools (la última vez que la usé fue hace aproximadamente un año), pero en aquel momento nuestros puntos de referencia de alta carga demostraron que era completamente lenta. Una gran decepción después de haber basado gran parte de nuestra arquitectura en ella.
Por lo menos, algo bueno que recuerdo sobre drools es que su equipo de desarrollo estaba disponible en IRC y es muy útil, puedes intentarlo, después de todo son expertos: irc.codehaus.org #drools
Usamos Drools como parte de una solución para actuar como una especie de filtro en una aplicación de procesamiento muy intensa, tal vez ejecutando hasta 100 reglas en 500,000 + objetos de memoria en funcionamiento. resulta que es extremadamente lento. ¿Alguien más tiene experiencia en el uso de Drools en una aplicación de procesamiento por lotes?
Drools no está diseñado para ejecutarse en una gran cantidad de objetos. Está optimizado para ejecutar reglas complejas en algunos objetos.
La inicialización de la memoria de trabajo para cada objeto adicional es demasiado lenta y las estrategias de almacenamiento en caché están diseñadas para funcionar por objeto de memoria en funcionamiento.
Estábamos mirando babas también, pero para nosotros el número de objetos es bajo, así que esto no es un problema. Recuerdo haber leído que existen versiones alternativas del mismo algoritmo que tienen más en cuenta el uso de la memoria, y están optimizadas para la velocidad mientras que aún se basan en el mismo algoritmo. Sin embargo, no estoy seguro de si alguno de ellos se ha convertido en una verdadera biblioteca utilizable.
Depende de sus reglas: 500K objetos es razonable si se tiene memoria suficiente (debe llenar una red RETE en la memoria, entonces el uso de memoria es un múltiplo de 500K objetos, es decir, espacio para objetos + espacio para estructura de red, índices, etc.) Es posible que estés buscando en el disco, lo que sería muy lento.
Por supuesto, si tienes reglas que combinan combinaciones del mismo tipo de hecho, eso puede causar una explosión de combinaciones para probar, lo que incluso si tienes 1 regla será realmente muy lento. Si tuviera más información sobre el análisis que está haciendo, probablemente lo ayude con posibles soluciones.
Estoy aprendiendo babas yo mismo, así que tal vez me falta algo, pero ¿por qué todo el lote de quinientos mil objetos se agrega a la memoria de trabajo a la vez? La única razón por la que puedo pensar es que hay reglas que se activan solo cuando dos o más elementos en el lote están relacionados.
Si ese no es el caso, entonces quizás podría usar una sesión sin estado y afirmar un objeto a la vez. Supongo que las reglas se ejecutarán 500 mil veces más rápido en ese caso.
Incluso si es el caso, ¿todas sus reglas necesitan acceso a todos los objetos 500k? ¿Podría acelerar las cosas aplicando las reglas por artículo de una en una, y luego en una segunda fase de procesamiento aplicar las reglas de nivel de lote usando una base de reglas y memoria de trabajo diferentes? Esto no cambiaría el volumen de datos, pero la red RETE sería más pequeña porque las reglas simples se habrían eliminado.
Un enfoque alternativo sería tratar de identificar los grupos de objetos relacionados y afirmar los objetos en grupos durante la segunda fase, reduciendo aún más el volumen de datos en la memoria de trabajo y dividiendo la red RETE.
Use una sesión sin estado y agregue los objetos uno a la vez?
He usado un Drools con una memoria de trabajo con estado que contiene más de 1M de datos. Con un poco de ajuste tanto de sus reglas como de la JVM subyacente, el rendimiento puede ser bastante bueno después de unos minutos para la puesta en marcha inicial. Avísame si quieres más detalles.
Tuve problemas con los errores OutOfMemory después de analizar algunos miles de objetos. Establecer un optimizador predeterminado diferente resolvió el problema.
OptimizerFactory.setDefaultOptimizer(OptimizerFactory.SAFE_REFLECTIVE);
este optimizador también se puede configurar mediante el parámetro -Dmvel2.disable.jit = true