Dispatcher order for effective load balancing

[raj_aries81]

Our environment has 3 dispatchers, one of them acts as both dispatcher and backup Content Manager.When this machine is listed on top in my Dispatcher URIs for gateways list, we noticed that this machine gets whacked with all the report requests and load is not fairly distributed.

However, after reordering the Dispatcher URIs for gateways by pushing this machine down the list we could see that load being distributed evenly.

Appreciate your inputs on why is this order so important for achieving optimal load balancing.

Thanks & Regards
raj

[MFGF]

Our environment has 3 dispatchers, one of them acts as both dispatcher and backup Content Manager.When this machine is listed on top in my Dispatcher URIs for gateways list, we noticed that this machine gets whacked with all the report requests and load is not fairly distributed.

However, after reordering the Dispatcher URIs for gateways by pushing this machine down the list we could see that load being distributed evenly.

Appreciate your inputs on why is this order so important for achieving optimal load balancing.

Thanks & Regards
raj

Hi,

Have you checked the settings on the dispatcher behaving strangely to make sure it does not have the Load Balancing Mode set to "Cluster compatible" or that it does not have a Processing Capacity set disproportionately higher than the other dispatchers in the architecture?

MF.

[raj_aries81]

Hi,

Have you checked the settings on the dispatcher behaving strangely to make sure it does not have the Load Balancing Mode set to "Cluster compatible" or that it does not have a Processing Capacity set disproportionately higher than the other dispatchers in the architecture?

MF.

Thanks MF,

Everything is set to Weighted RoundRobin and Processing Capacity is 1.0 with Acquired set to 'No' for Dispatcher+Backup Content Manager Machine, while dedicated Dispatcher has the same Processing Capacity but Acquired set to 'Yes'.  Not really sure if that could be the reason for this strange behaviour.

Regards
Raj

[MFGF]

Thanks MF,

Everything is set to Weighted RoundRobin and Processing Capacity is 1.0 with Acquired set to 'No' for Dispatcher+Backup Content Manager Machine, while dedicated Dispatcher has the same Processing Capacity but Acquired set to 'Yes'.  Not really sure if that could be the reason for this strange behaviour.

Regards
Raj

"Acquired" set to Yes means it is inheriting all its settings from a level above in the configuration, whereas "No" means they are explicitly defined for that level. That probably means something specific has been set at that level? Can you identify what it is?

MF.

[smiley]

Dispatcher URI for gateway is a redundancy list only.
If the gateway cannot contact the 1st dispatcher in the list, it will try the next one in the list.
If the 1st dispatcher responds, it will get all requests.

The Cognos (passive) load balancing mechanism to handle report calculation requests uses the following logic for CQM:
The first report request get´s send to the first bibus process, running on the first dispatcher as listed alphabetically in Cognos administration.
All other requests will go to that same bibus on that same dispatcher, until it reaches 50% of it´s low affinity request.
After that, the next report request will go to the first bibus on the next dispatcher listed alphabetically. (again until it reaches 50%)
Once all first bibusses on all dispatchers have reached at least 50%, a new bibus is spawned on the first dispatcher.
That will repeat on all dispatchers, until all configured bibusses on all dispatchers have reached 50%.
From then on the Load balancing logic will assign a new request to every bibus on each dispatcher until 100% is reached.

So what will this show you in real life:
- If the gateway(s) all point to the same initial dispatcher, it will more request. (that does not mean it will actually execute those)
- On a low load, you will see most of the work being done by the first dispatcher listed alphabetically.

Best practice is:
- When you have multiple gateways, always point them to another dispatcher on top of the list for even traffic distribution.
- If you have a very large environment, setup a "routing dispatcher" on the gateway to load balance it even more fair. (make sure report calculation is disabled on this)
- If you feel the Cognos load balancing is not up to you expectations, use a hardware load balancer that will actually look at the resources used on a dispatcher, and send a new request to the least busy server. (The "cluster compatible" option)
(Where cognos does not see actual resource usage, and is happy to send a new request to a server that is already using 100% cpu, if it has a free slot according to it´s passive load balancing logic)

[raj_aries81]

"Acquired" set to Yes means it is inheriting all its settings from a level above in the configuration, whereas "No" means they are explicitly defined for that level. That probably means something specific has been set at that level? Can you identify what it is?

MF.

Thanks MF. I haven't had a chance to look at all the properties, I will flick through them once to check if the Parent property has been overridden.

As always, that was really helpful ..thanks again !!

Regards
Raj

[raj_aries81]

Dispatcher URI for gateway is a redundancy list only.
If the gateway cannot contact the 1st dispatcher in the list, it will try the next one in the list.
If the 1st dispatcher responds, it will get all requests.

The Cognos (passive) load balancing mechanism to handle report calculation requests uses the following logic for CQM:
The first report request get´s send to the first bibus process, running on the first dispatcher as listed alphabetically in Cognos administration.
All other requests will go to that same bibus on that same dispatcher, until it reaches 50% of it´s low affinity request.
After that, the next report request will go to the first bibus on the next dispatcher listed alphabetically. (again until it reaches 50%)
Once all first bibusses on all dispatchers have reached at least 50%, a new bibus is spawned on the first dispatcher.
That will repeat on all dispatchers, until all configured bibusses on all dispatchers have reached 50%.
From then on the Load balancing logic will assign a new request to every bibus on each dispatcher until 100% is reached.

So what will this show you in real life:
- If the gateway(s) all point to the same initial dispatcher, it will more request. (that does not mean it will actually execute those)
- On a low load, you will see most of the work being done by the first dispatcher listed alphabetically.

Best practice is:
- When you have multiple gateways, always point them to another dispatcher on top of the list for even traffic distribution.
- If you have a very large environment, setup a "routing dispatcher" on the gateway to load balance it even more fair. (make sure report calculation is disabled on this)
- If you feel the Cognos load balancing is not up to you expectations, use a hardware load balancer that will actually look at the resources used on a dispatcher, and send a new request to the least busy server. (The "cluster compatible" option)
(Where cognos does not see actual resource usage, and is happy to send a new request to a server that is already using 100% cpu, if it has a free slot according to it´s passive load balancing logic)

Hi Smiley,

Thank you very much for your detailed reply, it was quite informative. I'm trying to get my head around the admin stuff esp dispatchers and other mundane admin tasks.

I believe we are using passive load balancing mechanism as we don't have hardware load balancer. I will monitor the routing during peak hours and will see how it behaves.

Thanks again for summarizing the load balancing mechanism.

Regards
Raj