Scalability Frequently Asked Questions

Is there any limit to the amount of concurrent connections when using the RemObjects SDK?

No, the Remoting SDK itself does not impose any limit on the connections. However, other factors might influence scalability, such as the network stack, hardware capabilities, etc.

See What do I need to do handle 100+ users?

What do I need to do handle 100+ users?

First, some general comments. The Remoting SDK was designed with HIGH load systems in mind and its intrinsic stateless nature provides exceptional scalability. The SDK works perfectly with systems using hardware load balancers and clusters of servers. Its objects can access COM+ objects and automatically get all the advantages of Windows built-in application server.

As the connection is not permanent, you can use a router or load balancer to distribute load between different servers. Microsoft Network Load Balancing is an example, Cisco hardware solutions are another. One simple technique is to code a list of servers in the client and have the clients decide where to send messages dynamically according to your business rules.

Now to the actual question: this is really asking how to scale out the server, so that there can be several hosts in a server farm (or at different locations across the internet) providing the same service, thus sharing the load of the 100+ users.

First, 100+ users should not generally be a problem for a single RO server, but this does depend on the workloads submitted by the users.

Although the Remoting SDK has been designed from the beginning to scale out, there are some things you need to do to make this happen:

First, you must ensure that your services are stateless. If you're using the standard or the pooled (recommended) class factory, chances are that they already are.

Statelessness means that your service objects do not store local data between calls (say, the client calls one method to send some data, that's stored in a field and used when the same client calls another method). If you need to store client-specific data, use sessions, in particular the database session manager or the MasterServer session manager, which can be shared by several servers in a server farm. The new online help we shipped with 4.0.9 has extensive info about this under Statelessness and Session Management.

Secondly, you have two options for actually distributing the load. If all your servers are on the same net, you could either use a smart router to do the load balancing (your clients only ever talk to one IP and the router distributes it to different servers, internally). Your client wouldn't even know that there are multiple servers. Alternatively, you can use the client-side load-balancing features on the channels, to have the clients distribute their calls to different servers - check the TROTransportChannel.ServerLocators property, which also has fairly extensive coverage in the new online help, with links to all relevant options and properties.