Server Scaling Behaviour

Second generation CORBA implementations are designed with scalability in mind. In earlier investigations it has been found that a major limitation of ORB performance and thus scalability, is the time to associate an incoming request with the actual method that shall be invoked[GS97b,GS98b]. After applying optimisations to this process, called demultiplexing, scalability to some thousands of different objects registered with a server can be achieved[GS98c,POS$^$99]. However, in DAQ systems the number of objects that are addressed by clients is not so big at all, although the client set might grow to a considerably large quantity. In our case there will be in the range of 500 to 1000 clients per server (readout units or filter units). For future distributed applications in the commercial world, such as information or database centers, this number is comparable.

How does a CORBA server behave confronted by many requests from many different origins? ORBs like TAO are dynamically configurable with concurrency mechanisms. So, the ORB can be tuned to specific needs. We distinguish two different architectures from which special architectures are derived:

• Reactive. On server side instantiation of a CORBA object it registers with the local ORB. It is responsible for all incoming network connections. Upon receipt of a request, the reactor pattern can be used to demultiplex the incoming byte stream to the right connection handler[Sch95a]. After parsing the request, the target object is identified and will be called back synchronously. This does not yet specify if the invoked method will run in a separate thread or is executed synchronously.

• Multithreaded. There exist many architectures on how to effectively process and demultiplex the requests exploiting parallelism with multiple threads[Sch98]. This is especially useful if the target machine provides several processors and the servants perform processing that can be interleaved with network transfers. The most popular of these approaches is to have one thread per accepted connection. All work for the requested servant is done in a separate thread.

TAO offers configurations for both server types. However for the reactive server, no unshared server implementation is provided. This means that the servant is always invoked synchronously in a single thread when using the reactive model. The clients have to share the same server execution thread, thus scalability of the server is bound to the computation time of the servants. For tests we use null invocations, i.e. the invoked method does not contain any further application code. As we are measure the upcall rate at the receiver side, the maximal rate at which a single client is served is obtained by dividing the server side measurement result by the total number of clients.

For the multithreaded approach, existence of multiple CPUs in a computer can increase the number of calls per second. However, a price has to be paid for that: the server spends more time in kernel mode as it is busy with context switching and synchronisation. Thus less time is free for performing the servant´s application code. Measurements obtained from a four processor UltraSparc server show that with 50 clients only 20 percent of the time is spent in the application itself (see figure 32). In addition we see that the ORB itself spends 45 percent of its time in kernel mode when handling one client. This time consists mainly of reading from the network. From this we can deduct that the difference between the 45 percent with one client and the 80 percent at 50 clients is used for thread handling. Figure 32 also shows the memory footprint of a multithreaded architecture in the right plot. With every connection some more management data structures have to be allocated. Although the growth is strictly linear it might cause problems when going to thousands of clients and more complex servant objects. More detailed information about concurrent server architectures is given in section 5.6.