A single server running Communicator Web Access (2007 R2 release) can handle approximately 5,000 simultaneous connections. If you need to support more users than that, you will need more than one Communicator Web Access server. If you need more than one Communicator Web Access server, you will probably want to deploy a hardware load balancer to help ensure that the workload is equitably distributed between those servers.

In addition to increasing the overall capacity of your Communicator Web Access infrastructure, by using an array of servers and a load balancer you can increase the reliability and availability of Communicator Web Access. Should a single server fail, the load balancer can automatically route incoming connection requests to the servers that are still functioning.

Communicator Web Access requires session affinity, a requirement that directly impacts load balancing. Session affinity simply means that a given Communicator Web Access session must take place on the same server. Communicator Web Access does not allow an instant messaging session to begin on one server and then somehow be transferred to another server. If a user is logged on to Server A at the beginning of his or her Communicator Web Access session, he or she will continue to use Server A for the duration of that session. If Server A should fail, the user will have his or her session terminated. (That user can then sign on again, and the load balancer will route them to a server that is still running.) However, users connected to Server B or Server C will not have their session disrupted in any way should Server A fail.

This explains why you must use hardware load balancing with Communicator Web Access. Software load balancing can also equally distribute connection requests among servers. However, if Server A fails, a software load balancer will redistribute all the client connections, including those clients on Server B and Server C. As a result, not only will users on Server A lose their connections, but many users on Server B and Server C will lose their connections as well.

As noted, software load balancing is not supported on Communicator Web Access. In addition, Communicator Web Access does not support any type of load balancing scenario involving multi-homed network adapters or computers equipped with more than one network adapter and more than one default gateway.

Communicator Web Access supports most hardware load balancers, provided that the load balancer:

Communicator Web Access also supports Secure Sockets Layer (SSL) acceleration on the load balancer. With SSL acceleration, the load balancer decrypts HTTPS transmissions before sending that unencrypted traffic to the Communicator Web Access server. Relieving the server of the need to perform SSL decryption can markedly improve that server’s performance.

Communicator Web Access should always have a dedicated load balancer. You should not share a load balancer between Office Communications Server and Communicator Web Access server.