Component Performance Engineering

While component architectures facilitate the development of complex applications by allowing the independent creation of generic, reusable components and by easing their composition, application-level performance engineering will require knowledge about a component's performance in different contexts and observation of the component's performance behavior during execution. We view a performance-engineered component as having four constituent parts:

• performance characterization and modeling (performance knowledge)
• integrated performance measurement and analysis ( performance observation)
• runtime access to performance information (performance query)
• mechanisms to alter component performance behavior ( performance control)

In Figure 2, we show how a component's design may be extended to support these performance engineering features. The intent is to keep the extended (performance engineered) design relatively consistent with the CCA model.

Figure 2: Performance Engineered Component Design

We represent a component's generic architecture by the middle (solid) box in the figure. As shown, we distinguish between a component's ``core'' functionality and its variant sub-parts (both functional variants and code variants) that may be selected prior to or during component execution. A component's generic design can be ``performance engineered'' with support for performance knowledge and/or performance observation. Performance knowledge extensions (left (dashed) box) provide means to describe and store what is ``known'' about the component's performance. This can take the form of empirical characterizations in a performance database, as well as performance models captured from empirical studies or analytical performance analysis. Performance observation extensions (right (dashed) box) implement performance measurement and analysis capabilities that are used during component execution. In addition, support for querying the performance information and for effecting control based on performance feedback complement the performance knowledge and observation parts.

To justify these extensions, let us first consider the use of performance knowledge in the performance engineering of component frameworks. The ability to save information about a component's performance allows that knowledge to be used for performance-guided component selection, deployment, and runtime adaptation. However, the representation of performance knowledge must be in common forms and there must be standard means to access selective performance information. In Figure 2, we identify a ``component performance repository'' where the performance knowledge could be kept and queried within the component framework, similar in concept (and likely function) to the CCA component repository. In fact, we could view the performance knowledge extension as a component in its own right, as suggested in the figure by the separation of the left (dashed) box from original component. In this way, the performance knowledge component (PKC) could provide PKC ports that give component-level access to the performance information both to other components within the framework (black arrowhead) as well as back to the original component (shaded arrowhead) whose performance it represents. These ``feedback'' port connections would allow for both static (instantiation-time) and dynamic (runtime) component control. The PKCs could also be instantiated and used, in particular, as active components to build runtime composite performance models for resource allocation and scheduling.

Similarly, let us consider justification for performance observation support in our performance engineered component model. The ability to observe a component's execution time performance is important for two reasons. By definition, any empirically derived performance knowledge requires some form of performance measurement and analysis. However, it does not mean that this support necessarily must be integrated in the component's design. The second reason is to monitor the performance of a component during execution and use that information in dynamic performance decision making. Here, integrated performance observation support (measurement and analysis) is key. As depicted in Figure 2 (block-filled double arrow), this integration requires component instrumentation (both core and variant), runtime measurement and data collection, and online and/or offline performance analysis. In this respect, we can view performance observation in the performance engineered component model as a functional extension of the original component design. To allow the component framework to query performance behavior, this extension could include new component methods and ports (black arrowhead). It is also useful for the original component to be able to access its own performance observations to make internal performance decisions. An interesting design issue here concerns how this functionality should be supported. Our view is to further generalize the model to regard observation support as encapsulated in a performance observation component (POC) that is tightly coupled and co-resident with the original component. Special POC ``provides'' ports allow the original component to use optimized interfaces (shaded arrowhead) to access ``internal'' performance observations.