[rules-users] Parallelization

Swindells, Thomas TSwindells at nds.com
Tue May 11 09:52:14 EDT 2010


I'm not a guru but I'm pretty certain all modern JVMs support multiple cores well.  You will probably make sure you are using the server VM (-server) and not the client VM (assuming you are using the standard VM).  Depending on what you current machine is and whether or not you have 2 cpu's or just two cores (and if java can tell the difference) you may or may not currently be running the server vm (see http://java.sun.com/javase/6/docs/technotes/guides/vm/server-class.html)  If you aren't then you may be very lucky and find that switching to the server class vm gives you those few extra ms to keep your boss happy.   Presumably you have also done the other standard optimization tricks to ensure you have sufficient heap memory etc?

Thomas


From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: 11 May 2010 14:32
To: Rules Users List
Subject: Re: [rules-users] Parallelization

On Tue, May 11, 2010 at 2:55 PM, djb <dbrownell83 at hotmail.com<mailto:dbrownell83 at hotmail.com>> wrote:

Hi Wolfgang,

I use one thread per StatefulKnowledgeSession... My machine has 2 cores, but
it will eventually be running on an 8 core beast, so i reckon this was a
good improvement.  I was just worried that I wouldn't be able to
simultaneously process multiple K-Sessions, but apparently, Drools doesn't
mind.  I'm pretty sure any machine with multiple cores supports parallel
java threads, no?
This is a Q for a Java guru (which I'm not), and may depend on the JVM and what not. Care
to provide details? Probably there's people on this list who might know. (Otherwise,
I have a good contact.)


-----
Regarding my Utilities method, eg.  isWithinTimePeriod("20100308",
"20090405", 1, "Y")

I can get about 5ms off by commenting out the eval, so it's not going to be
a big jump even if I fix it, but, well, I am using yyyyMMdd Strings, which
in the method, I sub-stringed, converted to ints, instantiated DateMidnight
objects, and compared using Joda-time daysBetween/monthsBetween/yearsBetween
methods.
My thought was that pre-converting to ints would help, so that each
ClaimLine has year/month/day int variables, and pass them in instead. (i.e.,
Saves 3 String.substring()'s, and 3 Integer.parseInt()).  but that actually
slowed it down a few milliseconds. (Maybe passing 6 params instead of 2?!)

You can treat 20100510 as an integer defining one date; all relations between
such numbers would hold as for the "true" dates - you just can't compute
durations (days between dates) by simple substraction.

I'm comparing two dates by an arbitrary period, like "2 days" or "1 month",
and need the framework of the Gregorian Calendar.  So, I don't think I can
do anything about this.  2 months is never guaranteed to be a set number of
milliseconds.  It all depends on the claim date, which is fact data, and
therefore variable.

I'm not sure how the other arguments in the call ("Y", 99) are related to rules
or facts, but a repeated test whether one date dx is between d1 and d2 where
d2 depends on d1 and a duration would certainly gain from computing d2
once.

-W


________________________________

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster at nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100511/6ad7feff/attachment.html 


More information about the rules-users mailing list