The algorithm we actually use is based on waiting transaction count. A waiting transaction is one where the ProxySG appliance has sent the request to the ICAP server and is awaiting the response. To view the number of transactions in waiting, access the URL https://x.x.x.x:8082/OPP/statistics
If you do not have transactions in a waiting state, then you will see DNS round robin behaviour. For example, If we assign a weight of 10 to CAS1 and a weight of 5 to CAS2 then when NO waiting transactions, we shall see a DNS round robin algorithm i.e. not two reqs going to one CAS and 1 req going to the other. When you see waiting transaction in OPP/statistics then, we should notice that requests going to ICAP server will not be in a DNS round robin fashion.
The logic used by the ProxySG appliance is as follows:
When new ICAP request arrives at the service group the ProxySG calculates a transaction index. This is effectively:
transaction index = Waiting transactions / weight
For example if CAS-A has a weight of 2 and 10 waiting transactions then the transaction index would be 5.
If CAS-B has a weight of 10 and 20 waiting transactions then the transaction index would be 2.
The ProxySG appliance will use the CAS service with the lowest transaction index; and in the above example it would send it to CAS-B.
In addition to the ICAP service with the lowest transaction index, another calculation that is factored in counts whether the number of active transactions are less than the number of maximum connections.
The max connections is set on the ICAP service. The value set on the ICAP server is obtained by clicking on sense settings.
Now if CAS-A had a transaction index of 5 (from the above example) and max connections of 10 and active transactions of 7 then active transactions is less than max connections.
Now if CAS-B had a transactions index of 2 and max connections is 5 and active transactions is 5 then active transactions is not less than max connections. In this case, the ProxySG would choose CAS-A
The best way to test this on a LAN, is to put a WAN Simulator in front of one of the CAS appliances in your network and configure it for a WAN speed of your choice. This configuration will make the ICAP request going to one of the CAS appliances slower than the other one and should trigger waiting transactions.
Imported Document ID: 000011648
Subscribing will provide email updates when this Article is updated. Login is required.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
Subscribed to the Article.
Unable to subscribe
Thanks for your additional feedback !!!
Enterprise Support Virtual Agent
Rate Me :
Tell us more:
Welcome! My name is Sami, the Enterprise Support Virtual Agent answering technical support questions.