[rules-users] Jbilling Drools performance

Greg Barton greg_barton at yahoo.com
Tue May 18 17:20:20 EDT 2010


Loading the rules each time is the culprit, if that's what's happening for each CDR.  I'll try mocking up 40k generated rules that are comparable in complexity to the ones you've presented just to confirm, but I'd wager the reloading is the cause.

--- On Tue, 5/18/10, Antonio Anderson Souza <antonio at voicetechnology.com.br> wrote:

From: Antonio Anderson Souza <antonio at voicetechnology.com.br>
Subject: Re: [rules-users] Jbilling Drools performance
To: "Rules Users List" <rules-users at lists.jboss.org>
Date: Tuesday, May 18, 2010, 4:11 PM

Greg, 



CDR is a Call Detail Record, sorry I forgot to explain it, the object is
 a POJO with the following attributes:


field: name: datereference type: DATE value: 2010-04-28 00:00:00.0

field: name: billingid type: STRING value: 20100428.15544.42adf

field: name: accountid type: INTEGER value: 15544

field: name: billingperiod type: STRING value: 20100401

field: name: billingclassification type: STRING value: DUR

field: name: ipxcallguid type: STRING value: 
5k692927-guwtka-g8kj8d0u-1-g8krry54-o4n

field: name: transactiondatetime type: DATE value: 2010-04-28 
20:21:01.337

field: name: billingitemid type: INTEGER value: 0

field: name: ratesystem type: STRING value: IPXNET

field: name: originnumber type: STRING value: 
551135880520 at bitcompany.braste

field: name: destinationnumber type: STRING value: 551139012650

field: name: destinationareaid type: STRING value: 100000551

field: name: chargedduration type: DATE value: 1980-01-01 00:02:06.0

field: name: chargedamount type: FLOAT value: 0.0816

field: name: userid type: INTEGER value: 3372

field: name: username type: STRING value: bitcom51

field: name: unitamount type: FLOAT value: 0.00389

field: name: amountcurrency type: STRING value: USD

field: name: timezone type: INTEGER value: -3

field: name: registertype type: STRING value: MV

field: name: datelastupdated type: DATE value: 2010-04-29 02:57:18.54

field: name: lastupdatedby type: STRING value: IPXRateCalls rev032

field: name: lastupdateremarks type: STRING value: null

field: name: dateinserted type: DATE value: 2010-04-29 02:57:18.54

field: name: destinationdetail type: STRING value: SAO PAULO

field: name: type type: STRING value: Fixo

field: name: collectedcallflag type: INTEGER value: 0

field: name: jb_timestamp type: DATE value: null

field: name: digit0 type: INTEGER value: 5

field: name: digit1 type: INTEGER value: 5

field: name: digit2 type: INTEGER value: 1

field: name: digit3 type: INTEGER value: 1

field: name: digit4 type: INTEGER value: 3

field: name: digit5 type: INTEGER value: 9

field: name: digit6 type: INTEGER value: 0

field: name: digit7 type: INTEGER value: 1

field: name: digit8 type: INTEGER value: 2

field: name: digit9 type: INTEGER value: 6

field: name: digit10 type: INTEGER value: 5

field: name: digit11 type: INTEGER value: 0


This spreadsheet is only a sample because the whole one has 40000 rules, I'm checking the Jbilling code, but it seams to be loading the rules each time.

Best regards,

Antonio Anderson Souza


Voice Technology
http://www.antonioams.com



2010/5/18 Greg Barton <greg_barton at yahoo.com>


OK, so a few questions:

What is a CDR?  How much data does it contain?  Do you load the rules fresh each time you process one?  Are there other rules besides the ones listed in the decision table?



--- On Tue, 5/18/10, Antonio Anderson Souza <antonio at voicetechnology.com.br> wrote:



From: Antonio Anderson Souza <antonio at voicetechnology.com.br>
Subject: Re: [rules-users] Jbilling Drools performance
To: "Rules Users List" <rules-users at lists.jboss.org>


Date: Tuesday, May 18, 2010, 9:49 AM

Dear All,

I've finished the tests with the digit per digit comparison without eval, but the performance does not increased a lot, it still taking about 1 minute per CDR,
 that is so slow for a Telecom Carrier, follow a piece of the new spreadsheet below:




	
	
	
	


	
	
		
			RuleSet
			pricing
			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

		
		
			Sequencial
			true
			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

		
		
			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

		
		
			RuleTable Padrao
			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

			

		
		
			CONDITION





			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			CONDITION
			ACTION
			PRIORITY 
		
		
			PricingField





			PricingField
			PricingField
			PricingField
			PricingField
			PricingField
			PricingField
			PricingField
			PricingField
			PricingField
			PricingField
			PricingField
			PricingManager
			manager
			salience
		
		
			name
			digit0 == '$param'
			name
			digit1 == '$param'
			name
			digit2 == '$param'
			name
			digit3 == '$param'
			name
			digit4 == '$param'
			name
			digit5 == '$param'
			name
			digit6 == '$param'
			name
			digit7 == '$param'
			name
			digit8 == '$param'
			name
			digit9 == '$param'
			name
			digit10 == '$param'
			name
			digit11 == '$param'
			itemId
			setPrice($param)
			

		
		
			Campo
			Digito1
			Campo
			Digito2
			Campo
			Digito3
			Campo
			Digito4
			Campo
			Digito5
			Campo
			Digito6
			Campo
			Digito7
			Campo
			Digito8
			Campo
			Digito9
			Campo
			Digito10
			Campo
			Digito11
			Campo
			Digito12
			ID do Item
			Preço
			Ordem
		
		
			digit0
			5
			digit1
			5
			digit2
			9
			digit3
			9
			digit4
			3
			digit5
			2
			digit6
			6
			digit7
			3
			digit8
			1
			digit9
			0
			digit10
			0
			digit11
			9
			300
			0.32610
			1
		
		
			digit0
			5
			digit1
			5
			digit2
			9
			digit3
			8
			digit4
			3
			digit5
			2
			digit6
			6
			digit7
			3
			digit8
			5
			digit9
			0
			digit10
			8
			digit11
			9
			300
			0.32610
			2
		
		
			digit0
			5
			digit1
			5
			digit2
			9
			digit3
			8
			digit4
			3
			digit5
			2
			digit6
			6
			digit7
			3
			digit8
			5
			digit9
			0
			digit10
			8
			digit11
			8
			300
			0.32610
			3
		
		
			digit0
			5
			digit1
			5
			digit2
			9
			digit3
			8
			digit4
			3
			digit5
			2
			digit6
			6
			digit7
			3
			digit8
			5
			digit9
			0
			digit10
			8
			digit11
			7
			300
			0.32610
			4
		
		
			digit0
			5
			digit1
			5
			digit2
			9
			digit3
			8
			digit4
			3
			digit5
			2
			digit6
			6
			digit7
			2
			digit8
			5
			digit9
			0
			digit10
			0
			digit11
			6
			300
			0.32610
			5
		
	




Do i need to make some special treatment to get Drools indexing my rules? I'm using the guvnor to upload the spreadsheet and compile the rules.

Does anybody have some tips to increase the performance?





Thank you very much,

Antonio Anderson Souza
Voice Technology

http://www.antonioams.com



2010/5/17 Swindells, Thomas <TSwindells at nds.com>













My advice is to try just having a single column:
strValue matches “$param.*”
you could also compare the performance of that to
eval(strValue.startsWith(“$param”))
 
Also presumably you are only wanting the first matching rule in your table to fire, looking at the table below drools will fire all of the matching rules,
 this will mean than any phone number with prefix 5511 will be charged at 0.4 as that will be the last rule to fire. 

 
Thomas
 



From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org]
On Behalf Of Greg Barton

Sent: 14 May 2010 20:59

To: Rules Users List

Subject: Re: [rules-users] Jbilling Drools performance


 




No problem.  I'm not sure how you'd do this in a decision table (it's probably pretty trivial) but in DRL you'd do:



rule "makePhoneNumber" 

when

  s: String()

then

  insert(new PhoneNumber(s));

  retract(s);

end



With two caveats: 



1) you need some conditions on the String matched if there are other Strings that don't make PhoneNumbers.

2) The rule could use a salience value higher than the pricing rules, but that isn't necessary.



Actually, there's a third caveat, and it's a big one: this won't work with sequential mode. This is because the rule above would alter working memory with the expectation that the pricing rules would react to the change.  If you want to use sequential mode
 you'll have to convert to PhoneNumber objects before hand.  I understand that you're using this Jbilling package, but is there no way you can put an intermediate adapter between the two?  It'd be as simple as inserting "new PhoneNumber(someString)" instead
 of "someString".



--- On Fri, 5/14/10, Antonio Anderson Souza <antonio at voicetechnology.com.br> wrote:


From: Antonio Anderson Souza <antonio at voicetechnology.com.br>

Subject: Re: [rules-users] Jbilling Drools performance

To: "Rules Users List" <rules-users at lists.jboss.org>

Date: Friday, May 14, 2010, 2:16 PM

Dear Greg,



Thanks very much for your reply.



I'm using sequential mode = true



Is there a way to create this PhoneNumber class, and convert the String to the PhoneNumber object inside the Drools? Because I'm using a system called JBilling and it send the phoneNumber as a String.



Sorry if those are basic questions, but I'm a newbie in Drools...



Thank you very much,



Antonio Anderson Souza

Voice Technology

http://www.antonioams.com





2010/5/14 Greg Barton <greg_barton at yahoo.com>




Right off the bat I'd say try to get rid of the eval usage.  Can you put the phone number into an object like this:



class PhoneNumber {

  private char digit0;

  private char digit1;

  ///...same for the rest of the digits



  public char getDigit0() { return digit0; }

  public char getDigit1() { return digit1; }

}



Then the conditions would look like this:



digit0 == '$param'



Behind the scenes hopefully this will optimize better.  The use of eval won't optimize well.



Are you using sequential mode?  This might be a good candidate for that if setting the price does not trigger any other rules to fire.



--- On Fri, 5/14/10, Antonio Anderson Souza <antonioams at gmail.com> wrote:


From: Antonio Anderson Souza <antonioams at gmail.com>

Subject: [rules-users] Jbilling Drools performance

To: "Drools Users Mailing list" <rules-users at lists.jboss.org>

Date: Friday, May 14, 2010, 1:28 PM


 




Dear All,

I'm deploying  a JBilling using Drools in a Telecom Carrier in Brazil, and I'm using Decision tables in xls files to execute the pricing, my pricing table has about 40.000 rules, and I'm getting a terrible performance
 about 1.5 minute to execute the price of each CDR (Call Detail Record) mediated.



Follow bellow a small piece of my decision table:









RuleTable Padrao





























































































CONDITION


CONDITION


ACTION


PRIORITY 







PricingField


PricingManager


manager


salience




name


eval (strValue.charAt(0) == '$param')


eval (strValue.charAt(1) == '$param')


eval (strValue.charAt(2) == '$param')


eval (strValue.charAt(3) == '$param')


eval (strValue.charAt(4) == '$param')


eval (strValue.charAt(5) == '$param')


eval (strValue.charAt(6) == '$param')


eval (strValue.charAt(7) == '$param')


eval (strValue.charAt(8) == '$param')


eval (strValue.charAt(9) == '$param')


eval (strValue.charAt(10) == '$param')


eval (strValue.charAt(11) == '$param')


itemId


setPrice($param)







Campo


Digito1


Digito2


Digito3


Digito4


Digito5


Digito6


Digito7


Digito8


Digito9


Digito10


Digito11


Digito12


ID do Item


Preço


Ordem




destinationnumber


5


5


1


1


3


5


8


8


0


1


8


8


300


0.00000


1




destinationnumber


5


5


1


1


3


5


8


8


0


1


8


7


300


0.00000


2




destinationnumber


5


5


1


1


3


5


8


8


0


1


8


6


300


0.00000


3




destinationnumber


5


5


1


1


3


5


8


8


0


1


8


5


300


0.00000


4




destinationnumber


5


5


1


1


3


5


8


8


0


1


8


4


300


0.00000


5




destinationnumber


5


5


1


1


3


5


8


8


0


1


8


3


300


0.00000


6




destinationnumber


5


5


1


1


3


5


8


8


0


1


8


2


300


0.00000


7




destinationnumber


5


5


1


1


















300


0.40000


8








Is it normal? Are there somebody using Jbilling in a similar way? Does anybody can help me?



Best regards,



Antonio Anderson Souza

Voice Technology

http://www.antonioams.com

 



 

 


-----Inline Attachment Follows-----

_______________________________________________

rules-users mailing list

rules-users at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/rules-users









_______________________________________________

rules-users mailing list

rules-users at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/rules-users

 



-----Inline Attachment Follows-----

_______________________________________________

rules-users mailing list

rules-users at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/rules-users





 







**************************************************************************************

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

**************************************************************************************





_______________________________________________

rules-users mailing list

rules-users at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/rules-users





-----Inline Attachment Follows-----

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org


https://lists.jboss.org/mailman/listinfo/rules-users



      
_______________________________________________

rules-users mailing list

rules-users at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/rules-users





-----Inline Attachment Follows-----

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100518/4cf22284/attachment.html 


More information about the rules-users mailing list