FICO® Blaze Advisor® Discussion

[RulBrokr]

Hi,

My project has to deal with millions of records and i have Class Library (.DLL) deployment architecture where multi-threading is implemented on .Net side.

I am not sure about how to configure No. of rule agent and recycle policy in Blaze Advisor to handle large number of request. In Blaze server file we have default value of

<NumAgents> 10 </NumAgents> and <RecyclePolicy> 0 </RecyclePolicy>

1. Do i need to increase num of rule agent when i know i am going to be hit million of records in timespan of 3 hours daily. Multi-threading and load balancing is done by .Net side?

2. What does this   RecyclePolicy> 0 </RecyclePolicy means. Please elaborate it more than given in Blaze help?

3. Do i need to take care of something else apart from above two factors to handle much load?

Thanks in Advance!!!!

[Jostein]

The rule of thumb that I learned for configuring the number of agents was [number of CPUs/Cores] * 2 + 1 (if I remember correctly).

A good rules service is one that only executes logic, i.e. there is no I/O, no latency involved. That means you want it to execute at 100% CPU for as short a time as possible, and then be done.

The #Num * 2 + 1 is meant to provide enough agents to keep the CPUs/cores busy at all times, without having so many agents as to make thrashing a problem.

Unless you need some kind of special handling of the state of the rules service (you'll know it if you do), just keep the default value of 0 for RecyclePolicy. It tells the agent to clean up in the normal way between invocations.

Regards,

Jostein

[Andrei · Accepted solution]

If multi-threading is done on the .NET side, you need to make sure "non-threaded" checkbox is selected in Blaze quick deployer, so that Blaze does not create unnecessary extra thread for each agent. As Jostein mentioned, a good starting number of agents is 2 x available active CPU threads. However, if your rules do some I/O, e.g. query for additional information from a database, you may want to increase number of agents to compensate for the idle time while waiting for the database response.

Anyway, just start with some number and monitor CPU utilization while running your batch. If it's too low, increase number of rule agents. If that does not help, there is a concurrency bottleneck somewhere else in your application.

Reset policy of "0" means that the agents state (global rule variables, etc.) get reinitialized between invocations. Reset policy of "2" means they are not reset. If your do not rely on the "initially" in global variables you might be OK to use it, but it's dangerous and the performance gain is pretty minimal (<1ms per call?) so don't bother using it.