hi Salaboy, Thank you for your reply. I read some of your blog posts and find them very helpful for my learning of Drools. But for the question I raised here, "create multiple stateless sessions with the same rules in different threads" is exactly what I was trying. But I found that the rule engine can only utilized 20% of the total CPU resources. In my test, I have 8 threads running and ideally they should use all cpu resource on my 8 core machine. Here's my test program with 8 threads: public class DroolsMultithreadTest implements Runnable { private static KnowledgeBase kbase; private static KnowledgeBuilder kbuilder; static int times = 10000; public DroolsMultithreadTest() { } public static void main(String args[]) throws Exception { kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(); kbuilder.add( ResourceFactory.newClassPathResource("change-set.xml", DroolsMultithreadTest.class), ResourceType.CHANGE_SET ); if ( kbuilder.hasErrors() ) { System.out.println( kbuilder.getErrors().toString() ); throw new RuntimeException( "Unable to compile rules." ); } KnowledgeBaseConfiguration kbConfiguration = KnowledgeBaseFactory.newKnowledgeBaseConfiguration(); kbConfiguration.setOption(SequentialOption.YES); kbase = KnowledgeBaseFactory.newKnowledgeBase(kbConfiguration); // get the compiled packages (which are serializable) kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() ); long startTime = System.currentTimeMillis(); Thread[] threads = new Thread[8]; for (int i=0; i<8; i++) { threads[i] = new Thread(new DroolsMultithreadTest()); threads[i].start(); } for (int i=0; i<8; i++) { threads[i].join(); } System.out.println("Time spent (ms): " + (System.currentTimeMillis() - startTime)); System.out.println("Time/request (ms): " + ((System.currentTimeMillis() - startTime))/times); System.exit(0); } @Override public void run() { for (int i=0; i<times; i++) { // get the declared FactType FactType transactionType = kbase.getFactType( "Demo", "Transaction"); // handle the type as necessary: // create instances: Object txn = null; try { txn = transactionType.newInstance(); } catch (InstantiationException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } // set attributes values transactionType.set( txn, "txnId", (i+1)*100L ); transactionType.set( txn, "amount", new BigDecimal(i%10) ); // insert fact into a session StatelessKnowledgeSession ksession = kbase.newStatelessKnowledgeSession(); CacheQueryService queryService = CacheQueryServiceImpl.getInstance(); ksession.setGlobal("cacheQueryService", queryService); ksession.execute(txn); } } } Thanks, -Ping -- View this message in context: http://drools.46999.n3.nabble.com/Multi-threading-inefficiency-caused-by-... Sent from the Drools: User forum mailing list archive at Nabble.com.

Looking at the code of the thread you are running in parallel I guess that almost all of its time is spent in session creation, and during this (and the dispose) the knowledge base is a resource that needs protection. Thus, the test you are running isn't well suited for demonstrating concurrency. * Run one stateful session per thread, inserting and retracting (random) facts. * Add code wasting cycles to your rule(s). Also, make sure that the global (which is shared between sessions) isn't causing another bottleneck. -W On 11/12/2012, ping <jinpingv(a)hotmail.com&gt; wrote:

On 11/12/2012, Mauricio Salatino <salaboy(a)gmail.com&gt; wrote: Except for sharing the global, -W

Thank you. You are right the locks are guarding the session creation. I will try stateful session with fact retracting. I was using stateless session because the rules I'm going to deploy are all simple rules without much inference. So another question is: to make the multi-threading efficient, I need to reuse the stateful session. In that case, will the memory be a problem if I keep the session running too long without dispose it? Or I need to create a new session once every hour or day? Or maybe retracting the facts will keep the memory footprint low? -Ping -- View this message in context: http://drools.46999.n3.nabble.com/Multi-threading-inefficiency-caused-by-... Sent from the Drools: User forum mailing list archive at Nabble.com.