Its difficult to guess from under blindfolds, but I think that your rules result
from decision table lines where there are several properties compared
to literals, i.e., a multi-dimensional classification problem.
A few weeks ago there was a thread where one such DT resulted in ~50K
rules, each testing 4 or 5 properties, resulting in excessive memory
consumption. For that situation, replacing the rules by static facts
containing the set of literals and matching them against the actual
transaction fact was the answer.
-W
On 23/11/2012, manohars <manohar_satkar(a)infosys.com> wrote:
By response time we mean - rule execution time - insert input->
Fire rule
->get the result.
We are okay with loading KnowledgeBase.
While using Decision tables, we observed a lot many short lived objects
getting created. Java Profiler pointed out the area in drools.mvel and
VariableIndexResolver packages.
We have standalone Java engine that uses RuleEngineService built on Drools.
Excel files are per-compiled into .pkg before running Java Engine.
We are using several decision tables in multiple excel rule files so there
are many more rules to be executed before reaching the result.
For many requests , response time is okay however due to too many short
lived objects, GC cycles are increased and hence it is impacting response
time for some of the requests,.. increasing overall average response time.
Any suggestions/ideas/options would be appreciated.
Thanks,
M
--
View this message in context:
http://drools.46999.n3.nabble.com/Drools-consuming-a-lot-of-memory-for-sh...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users