Hi Nurlan,
This feature isn't implemented yet, but will be resolved together with
the issue for multi-threading the Solver:
https://issues.jboss.org/browse/JBRULES-681
I have a working design in my head and on paper here for the basic.
Basically, a Move will be parallelized over CPU's and JVM
Well, I just wanted to report some results...
I added the GC switch -server, just to be sure, but anyway,
I was having endless trouble with my ThreadPoolExecutor, and switched to:
ExecutorService threadPool = Executors.newFixedThreadPool(5);
And my claims now process at an unfathomable 5ms eac
collection may be an issue I'd reduce
that by two. You need one core "dedicated" to other stuff (I/O and whatnot)
and some resources for GC.
--- On Tue, 5/11/10, djb wrote:
> From: djb
> Subject: Re: [rules-users] Parallelization
> To: rules-users@lists.jboss.org
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
mailto:dbrownel...@hotmail.com>> wrote:
Hi Wolfgang,
I use one thread per StatefulKnowledgeSession... My machine has 2 cores, but
it will eventually be running on an
; 05/11/2010 08:01 AM
>
> Subject:
>
> Re: [rules-users] Parallelization
>
> Sent by:
>
> rules-users-boun...@lists.jboss.org
>
>
> Hi Wolfgang,
>
> Ok, well I implemented my "option #2", which has cut it down to 23ms,
which
> is a good start.
On 11/05/2010 13:55, djb wrote:
> Hi Wolfgang,
>
> Ok, well I implemented my "option #2", which has cut it down to 23ms, which
> is a good start. My timing is done by taking the time before, and after,
> and dividing by the number of claims processed. (and averaging over a few
> runs)
>
> I use o
They are for simple CEP type applications, you won't see a benefit else
where, possibly a slow down if you are doing more business type rules.
Mark
On 11/05/2010 09:40, djb wrote:
> Hi Drools squad,
>
> This is a follow-up to my previous speed-related post. By boss is still
> pushing to get 35ms
On Tue, May 11, 2010 at 2:55 PM, djb 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
> simultane
Hi Wolfgang,
Ok, well I implemented my "option #2", which has cut it down to 23ms, which
is a good start. My timing is done by taking the time before, and after,
and dividing by the number of claims processed. (and averaging over a few
runs)
I use one thread per StatefulKnowledgeSession... My
Does your system support parallel execution of Java threads on multiple
processors? Otherwise I don't see how parallelization will gain much
since the Rete evaluation itself is clearly compile-time bound.
How are you timing these 53ms? Does this include input time for your facts?
Frequently, much
Hi Drools squad,
This is a follow-up to my previous speed-related post. By boss is still
pushing to get 35ms down a bit, and I'm looking at parallelization options.
I've looked through the forums, but not successfully...
The options I see, are:
1. KnowledgeBase partitioning (setting Knowledge
11 matches
Mail list logo
