[25] PERFORMANCE ISSUES
(Part of the CORBA FAQ, Copyright © 1996-99)

[25.1] CAN CORBA APPLICATIONS BE TUNED FOR BETTER PERFORMANCE?

Darn right. There are a number of ways to tune CORBA applications for better performance.

1. Remember that distribution should only be used if a reason to do so exists. Distribution does not make sense for the sake of distribution. If distribution does not serve a purpose then it should be avoided. Avoiding excessive distribution can result in better performance. Care should be taken when introducing distribution into an applications object model.
2. IDL interfaces can be tuned to minimize network latency. Invoking remote operations requires transmitting data across the network. Network performance is typically optimized by ensuring adequate bandwidth. Once the required bandwidth is achieved raw network performance cannot be increased. One key to tuning an IDL interface is to reduce the number of network transfers that need to occur. Calling an operation that returns 100 bytes might take 5 milliseconds. Calling an operation that returns 200 bytes of data might take around 6 milliseconds. Calling 2 operations that return 100 bytes might take a total of 10 milliseconds. One key to tuning IDL operations is to avoid implementing several get operations and to combine them into a single get operation which returns the appropriate combination of data.
3. Caching results of remote operations can avoid network overhead associated with calling the same remote methods more than once. Many applications can perform remote operations upon startup rather than during normal usage. Users are often more willing to wait at startup time rather than during application usage.
4. Many performance problems are associated with serialization and blocking conditions. For example, Let us assume that clients will be making remote operations to a single server. A single client’s request causes the server to block for a extended period of time, the entire client community might have to wait. Make sure that multiple distributed operations are not becoming serialized within a single server process. Utilize multiple server processes or threaded servers instead.

[ Top | Bottom | Previous section | Next section ]

[25.2] DO DIFFERENT CORBA IMPLEMENTATIONS PERFORM AT SIGNIFICANTLY DIFFERENT LEVELS?

Wow, you bet they can.

Different CORBA implementations can vary significantly in performance. Good implementations should be fairly similar since network performance defines the maximum achievable performance characteristics. Network latency does represent the significant portion of distributed invocation latency.

[ Top | Bottom | Previous section | Next section ]

[25.3] WHAT TYPES OF PERFORMANCE SHOULD I BE CONCERNED WITH?

There are many different performance characteristics that are important. Performance should also scale linearly as connections or objects increase. While raw throughput between one client and one server is important, it is not the only or the most critical characteristic. Many characteristics of the CORBA implementation should be considered. As always, actual application requirements to the relative importance of these different characteristics. With the high speed nature of most CORBA implementations, raw client/server throughput is often not a bottleneck. It is also important that factors such as the number of operations does not slow down individual remote invocations. Here is a list of some important performance characteristics.

1. Scalability across connected client applications.
2. Scalability across objects within a CORBA server.
3. Raw throughout between one client and one server.
4. Activation time of server processes.
5. Activation time of CORBA objects.
6. Streaming time for different IDL types.
7. Connection time associated with the first remote operation, _narrow call, _is_a call etc.
8. Minimum memory consumed by a CORBA object.
9. Number of file descriptors consumed by a complex network of distributed objects.

[ Top | Bottom | Previous section | Next section ]

 E-mail us