Since commercial component models are targeted mostly to serial computing environments, the design of performance methods and metrics for these software systems are not likely to account for critical requirements important to high-performance scientific computing such as memory hierarchy performance, data locality, or floating point operation. Likewise, the distributed frameworks/component models (e.g., DCOM and CORBA) use commodity networking to connect components together, and lack consideration for high-performance network communication required for HPC. In a distributed environment, metrics like round trip time and network latency are often considered useful, while quantities like bisection bandwidth, message passing latencies and synchronization cost, which form the basis of much of the research in scientific performance evaluation, are left unaddressed.
However, despite the different semantics, several research efforts in these standards offer viable strategies in measuring performance. A performance monitoring system for the Enterprise Java Beans standard is described in . For each component to be monitored, a proxy is created using the same interface as the component. The proxy intercepts all method invocations and notifies a monitor component before forwarding the invocation to the component. The monitor handles the notifications and selects the data to present, either to a user or to another component (e.g., a visualizer component). The goal of this monitoring system is to identify hot spots or components that do not scale well.
The Wabash tool [17,18] is designed for pre-deployment testing and monitoring of distributed CORBA systems. Because of the distributed nature, Wabash groups components into regions based on the geographical location. An interceptor is created in the same address space of each server object (i.e., a component that provides services) and manages all incoming and outgoing requests to the server. A manager component is responsible for querying the interceptor for data retrieval and event management.
In the work done by the Parallel Software Group at the Imperial College of Science in London [19,20], the research is focused on grid-based component computing. However, the performance is also measured through the use of proxies. Their performance system is designed to automatically select the optimal implementation of the application based on performance models and available resources. With components, each having implementations, there is a total of implementations to choose from. The performance characteristics and a performance model for each component is constructed by the component developer and stored in the component repository. Their approach is to use the proxies to simulate an application in order to determine the call-path. This simulation skips the implementation of the components by using the proxies. Once the call-path is determined, a recursive composite performance model is created by examining the behavior of each method call in the call-path. In order to ensure that the composite model is implementation-independent, a variable is used in the model whenever there is a reference to an implementation. To evaluate the model, a specific implementation's performance model replaces the variables and the composite model returns an estimated execution time or estimated cost (based on some hardware resources model). The implementation with the lowest execution time or lowest cost is then selected and a execution plan is created for the application.