7:31 a.m.
Hello,
We are using Drools 5.3.0 Final distribution using decision tables(.pkg rule
files) in our solution. However, Drools is taking a lot of memory (@ 350 mb
on Linux-64bit).
On profiling,we realize that huge number of short lived objects are getting
created.(org.drools.impl.StatefulKnowledgeSessionImpl, IndexVariableResolver
class and org.mvel2.* classes). It leads increase in Garbage Collection
cycles there by leaving an impact on average response time.
Is there any clever way to use Drools to achieve @ 1 millisecond to 2
millisecond response time given the rules are simple? We tried to use drl
based rules but no improvement.
Any idea about how to deal with this such a big memory contributors ?
Regards,
Manohar
--
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.
8:49 a.m.
What does your notion of "response time" include? E.g., loading of a
rule base from a package, creating a session from a loaded rule base,
inserting N facts,...?
Using decision tables tends to create a large number of simple rules,
and this may not be the best way to go.
Describe the usage scenario, outline the rules resulting from the
decision table(s) (do you have one or several), etc.
-W
On 23/11/2012, manohars <manohar_satkar(a)infosys.com> wrote:
Hello,
We are using Drools 5.3.0 Final distribution using decision tables(.pkg rule
files) in our solution. However, Drools is taking a lot of memory (@ 350 mb
on Linux-64bit).
On profiling,we realize that huge number of short lived objects are getting
created.(org.drools.impl.StatefulKnowledgeSessionImpl, IndexVariableResolver
class and org.mvel2.* classes). It leads increase in Garbage Collection
cycles there by leaving an impact on average response time.
Is there any clever way to use Drools to achieve @ 1 millisecond to 2
millisecond response time given the rules are simple? We tried to use drl
based rules but no improvement.
Any idea about how to deal with this such a big memory contributors ?
Regards,
Manohar
--
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
1:19 p.m.
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.
1:31 p.m.
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
4180
days inactive
4180
days old
3 comments
2 participants
participants (2)
-
manohars -
Wolfgang Laun