Application-level performance heuristics

applica-tion dependent and, therefore, some form of control is needed for appli-cation developers. Some ORB implementations allow connections to be controlled with configuration parameters (e.g. [Inp99]).

Contention at software servers is a well-known performance issue. In the CORBA platform, this may be avoided by using a multi-threaded object implementation instead of a single-threaded one. The correct choice depends on several factors, such as the implementation cost, ap-plication workload and performance requirements. However, there is an additional concern related to the CORBA platform: contention may occur at internal servers that are not visible for application developers. Even if application-level servers were designed to withstand high workloads, the system may fail to reach its performance goals due to excessive conten-tion at internal servers.

The activation and deactivation of CORBA servers may also cause performance problems. To allow applications to optimize their use of hardware and software resources, the CORBA specification supports various activation and deactivation mechanisms and policies. However, it may be difficult to make correct decisions as to when and where a par-ticular server should be activated. Some CORBA implementations make these decisions transparently from applications (e.g. [BEA99]), but it may be difficult to configure such mechanisms so that they correctly pre-dict the behavior of the applications.

Finally, it should be noted that the high-level abstractions provided by CORBA platform might sometimes mislead application developers to ig-nore the physical reality. Distribution transparencies together with object-orientation can make the implementation of remote interactions and dis-tributed systems straightforward and easy. However, the cost of remote interactions and other potential performance problems do not vanish with the improved programmer productivity.

2.4 Application-level performance heuristics

A number of application-level guidelines have been proposed for im-proving the performance of CORBA based systems. They are often pre-sented with design patterns, a popular technique for documenting soft-ware design expertise in a structured way [Gam94, Cop96]. We briefly discuss the following heuristics:

ΠIncreasing the amount of parallel execution,

ΠReducing the number system elements,

ΠReducing the amount of communication,

ΠImproving the architecture of CORBA based systems.

When discussing the guidelines, we also point out the underlying techni-cal motivations in the CORBA architecture. A more generic set of appli-cation-level heuristics is given in [Smi90].

Increasing parallelism

Synchronous calls are the primary method of invoking operations on CORBA objects. In many cases, however, the waiting time at the client side could be used for other purposes. A number of application-level techniques have been proposed to increase parallelism during operation invocations. A common technique is to replace synchronous operation invocations with fully or partially asynchronous communication [Mow97]. For example, the server can invoke a callback routine on the client when the requested operation has been completed. The CORBA Messaging specification provides advanced tools for implementing such techniques.

Another technique for increasing parallelism is to use threads with synchronous communication. At the server side, the object adapter can launch a new thread for each incoming request. This technique is trans-parent to the application code apart from the need to synchronize the si-multaneous access to the object’s internal state. At the client side, a spe-cial thread can be spawned for waiting for the reply while other threads continue as usual. A special technique has been proposed for hiding the use of threads in CORBA clients [Hel96]. When the client application in-vokes an operation, a new thread is launched transparently for waiting for the server’s reply. The client’s main thread continues executing the appli-cation code until it attempts to use the results of the pending invoappli-cation.

If the server has already delivered the results, the client application code simply accesses them. However, if the server is still executing the re-quest, the client blocks until the results become available.

Reducing the number of system elements

A large number of generated IDL stubs and skeletons increase the over-head of routing invocations to object implementations. Compiler optimi-zation techniques can alleviate the problem [Eid97] but they cannot

2.4 Application-level performance heuristics 23 eliminate it completely. Several possibilities exist for reducing the num-ber of interfaces, operations, and attributes in CORBA based applica-tions. For example, an interface can offer two generic operations, get and set, for supporting access to any number of attributes [Mow97]. Simi-larly, it is possible to reduce the number of operations and interfaces by abstracting away differences that exist between them. The Any data type can be used as a placeholder for generic parameters that can change their type from one invocation to another. However, the Any data type entails the use of meta-information at run-time and this may incur a serious deg-radation of performance in some cases [Zie96, MLC98].

Reducing the amount of communication

The amount of remote communication is a typical target for optimiza-tions due to the limitaoptimiza-tions imposed by network bandwidth and latency.

There are several techniques for reducing remote communication in CORBA based systems. We briefly discuss three of them. First, the client stubs can be modified to maintain a local cache of remote objects [Mow97, Inp99]. This way, access to the remote object is minimized but the client can still maintain the abstract view provided by the IDL inter-face. Second, an application-level object can be divided into two half-objects that use an optimized protocol for maintaining the necessary state information in both halves [Mes94]. This way, both half-objects can lo-cally support non-optimized CORBA interfaces, but the overall design can avoid most of the related overhead.

The third technique for reducing the communication overhead is to replicate CORBA objects in the network. This way, clients can invoke operations locally while the replicated servers synchronize in the back-ground. Some ORB implementations provide ready-made solutions for creating multiple implementations for a single object reference [DEC96], but standard CORBA facilities can also be used for implementing object replication [Mow97]. An important use of replication is the implementa-tion of high availability through virtual synchrony [Maf97]. This tech-nique uses a group abstraction mechanism for ensuring that the request of a client succeeds if there is at least one operational replica in the group.

In process-oriented applications with very little persistent data, virtual synchrony can implement reliable system behavior with much less over-head compared to traditional ACID type transaction processing.

Improving the software architecture

Correct IDL design may strongly influence the performance of the sys-tem. In particular, it is usually more efficient to use a single invocation for carrying large amounts of data instead of having multiple invocations with less data [MLC98]. Accordingly, if a long sequence of calls to primitive operations is replaced by a single and more complex invoca-tion, the responsiveness of the system may increase significantly [Sla99].

The CORBAservices have been designed to support general-purpose needs in various application domains and, hence, they may be inefficient for some applications. An application-specific layer can be introduced between the client and a general-purpose CORBAservice for reducing the number of calls and the amount of data to be transferred. For example, the context-relative CORBA naming service can be hidden under a sim-plified interface that uses a single naming context [Mow97].