This article describes how the load balancing algorithm works, based on the number of transactions that are waiting to be processed.

For information on ICAP weights and how assigning weights can affect how much ICAP traffic is directed to each ICAP service in a service-group, see  "How to configure load balancing, weighting or failover across multiple ICAP servers."

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:

1. 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.

2.  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.

The active transaction count is again obtained by going to https://x.x.x.x:8082/OPP/statistics.

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.