Towards A Performance-Oriented Self-Adaptive System
Chung-Horng Lung and Xu Zhang and Greg Franks and Marzia Zaman
May 5, 2011
Abstract
Software architecture evaluation is critical to the suc-
cess of a system. Software architecture evaluation,
unfortunately, is difficult in practice, especially for
performance or quality-of-service at the early stage
where uncertainties usually arise. Selecting an ar-
chitecture alternative that has better performance re-
quires more detailed information and efforts. In
addition, software performance issue becomes even
more challenging with respect to increasing hard-
ware complexity and sophisticated software inter-
actions. This position paper proposes an approach
that could conduct self-management based on perfor-
mance results. Such an approach can help the archi-
tect conduct architecture evaluation more effectively
and efficiently. In addition, the architect can focus
more on the application level.
1 Introduction
Software architecture evaluation is recognized as a
vital element to the success of the software devel-
opment. A lot of research efforts have been con-
ducted and reported on software architecture evalua-
tion. Two examples are ATAM (Architecture Trade-
off Analysis Method) [?] or SASA (Software Archi-
tecture Sensitivity Analysis) based on some architec-
ture metrics [?]. Most software architecture evalu-
ation methods are based on high level architectural
descriptions. However, for software performance
evaluation or general quality-of-service (QoS), sim-
ply using those high level descriptions usually is not
enough. Many software products cannot be used as
they were initially designed due to the performance
problems. The cost of performance failures can be
huge [?].
Software performance is a challenging issue in ar-
chitecture evaluation. It often requires a lot of de-
tails, which may not be available at the architecture
level. Performance modeling can be useful in this
phase. Software Performance Engineering (SPE) [?]
has been recognized as an effective approach for ad-
dressing this issue. It is generally accepted that SPE
should be conducted early in the life cycle. Unfortu-
nately, conducting SPE, especially at the early stages
of the development, is difficult and requires a high
skill level.
In addition, there are practical issues related to
performance modeling. First, modeling itself may
take a long time. It is not uncommon that model
building alone may take a long time, which is gen-
erally not acceptable in highly competitive enter-
prises. Second, there are constraints or limitations
for the modeling techniques, e.g., modeling of lost
messages or resource failures. Furthermore, SPE is
a specialized area which people may not be famil-
iar with. Modeling is valuable to help us better un-
derstand the system and is better than “build-break-
fix” approach. Nonetheless, in some practical areas,
1

we need to consider more detailed information than
just typical high level modeling techniques to pro-
vide more useful insights.
Distributed and concurrent systems have become
common for enterprises. The performance or QoS
issue becomes even more challenging for these sys-
tems due to increasing software and hardware com-
plexity, e.g., threading and parallelism. Many design
patterns in this area have been captured and docu-
mented [?]. Design patterns demonstrate recurring,
validated solutions to similar problem. However,
some patterns, especially in distributed and concur-
rent areas, are specialized and may not be easy to
understand or implement, especially for those who
are not familiar with these areas or levels.
Moreover, there may exist more than one de-
sign pattern for a task or feature. For instance,
from the concurrency management perspective,
three architectural alternatives are common: Single
Thread (ST), Half-Sync/Half-Async (HS/HA), and
Leader/Followers (LFs) [?]. “Which architecture is
more efficient?” may become an issue that the ar-
chitect often has to face. The performance is also
often dependent on the operating systems and the
hardware. There is no clear winner among the three
alternatives that always produces the best perfor-
mance. Various factors, including system resources,
contentions, complex interactions between the appli-
cation and the kernel, and increasing hardware com-
plexity may affect the performance or QoS results.
2 Proposed Approach
To support the software architect in dealing with
the challenge, this position paper proposes a
performance-oriented self-adaptive approach. The
objective of this approach is to build tools to support
the architect to make informed and effective evalu-
ation. The approach is built on top of a generative
framework [?] that can be used to instantiate multi-
ple architecture alternatives based on different well-
known design patterns in concurrent and distributed
systems [?]. The framework concurrently consists of
three different architecture alternatives: ST, HS/HA,
and LFs, as demonstrated in Figure 1.
The framework itself is a layered architecture.
However, multiple software architectures have been
incorporated into the framework when the frame-
work was constructed. In other words, each architec-
ture alternative has been bound at design time. With
the generative framework, the architect can instanti-
ate an architecture alternative at run-time by going
through the user interface. The architect can then fo-
cus on the application level by building a prototype
that has the main features or services for validation.
2.1 Methodology
The approach is called 5M method which consists
of the following components: monitor, measurer,
manager, modeler, and modifier. The first three el-
ements: monitor, measurer, and manager are neces-
sary; while modeler and modifier are optional. These
components do not have to be carried out in se-
quence; they are iterative and incremental in nature.
Figure 2 illustrates the 5M self-adaptive model and
the relationship with the framework. Those compo-
nents are briefly described as follows:
• The monitor component provides mechanisms
or probes to collect and aggregate data obtained
from various elements pre-defined in the sys-
tem. The data could be gathered from any or
all of the design alternatives, depending on how
those alternatives are selected.
• The measurer phase is used to gauge the data
that are collected from the monitor step or
compare with existing historical data or pre-
configured watermarks or thresholds.
2

• The manager module is to automatically con-
trol the system based on the performance re-
sults. In this context, the control means auto-
matic switch from one architecture alternative
to another one based on the performance mea-
surements or modeling results for specific ap-
plications, system workloads, run-time behav-
iors, or platforms.
The user initially can select an architecture al-
ternative via the user interface. The switching
from one alternative to another is made pos-
sible and easy since they have been built into
the framework already. For instance, the fol-
lowing code segment shows the selection of
the LFs pattern when the getIndex() returns
1.
if runAsLFs.getIndex() == 1 then
{LFs is selected}
applicationLFs = {create an LFs object}
new LeaderFollowersInterfacer(this);
{start LFs}
applicationLF.startLeaderFollowers();
end if
The getIndex() value could be changed dy-
namically by the manager, which will trigger
the switch from one architecture to another.
• The modeler part is primarily targeted for fur-
ther planning or prediction. For instance, the ar-
chitect may anticipate more complex operations
or interactions, but it may be time consuming
to actually prototype those areas. Performance
modeling complements the framework by fa-
cilitating further scalability analysis or higher
workload evaluation. The collected information
will be fed into an offline performance mod-
eling tool. Currently, the performance solu-
tions and modeling is based on Layered Queu-
ing Networks (LQNs) [?, ?]. Other types of per-
formance modeling technique, e.g., Stochastic
Modifier
Domain−
specific
application
User
Framework
Interface
Monitor
ST
Application
Modeler
HS/
HA
Manager
Measurer
LFs
Figure 2: 5M Self-Adaptive Model
Process Algebras [?], can also be considered in
the future.
• The modifier is an abstract component, which
allows the architect to make changes either
to the prototype (primarily at the application
level), profiling, and/or the performance mod-
els based on generated reports. The modifier,
conceptually, can get information from all other
components, the framework, and the applica-
tion. The main point is to provide feedbacks
or necessary changes to them based on the data
gathered from other elements of the model.
2.2 Implementation and Current Status
We have conducted a preliminary experiment using
a simple mechanism for the manager for concept
demonstration. The simple control mechanism is just
a timer at this point. In other words, when the timer
expires, a switch from one architecture/design to an-
other one will occur at run time.
The main idea is to build another layer for the
manager on top of the generative framework de-
picted in Figure 1. In short, the manager is essen-
tially a higher layer that can manage the framework.
3

Components
GUI
Half−Sync/Half−Async
(A+B+C+D+E+X+Y)
Leader/Follower
(A+B+C+E+Y)
Single Thread
(A+B+C+E+Y)
Client/Server Peer−to−Peer
Service
Handler
Connection
AcceptorDispatcher
Connector DataAcceptor
Architecture
Patterns
Architecture
Model/Style
User
Interface
Design
Patterns &
Reusable
Queue
B D
Reusable Components
A C E
Utility Packages
Y
Generator
X
Figure 1: Structure and Reusable Components of the Generative Framework
Specifically, it can instantiate or terminate an archi-
tecture/design instance-ST, HS/HA, or LFs. For ex-
ample, if the getIndex() function, shown in the
code segment in Section 2.1, returns 2 which repre-
sents HS/HA, then an instance of HS/HA will be cre-
ated. Each instance actually is like an object, which
can be created or removed by the manger. When
the manager wants to switch from the LFs pattern
to the HS/HA pattern, it first dynamically creates an
HS/HA instance. After successful creation, the man-
ager will then switch to the HS/HA pattern and ter-
minate the original LFs instance.
An LQN performance model has also been built
for the ST approach [?]. The model consists of com-
ponents which can be reused or modified for other
design alternatives. The modeler is closely tied to the
monitor which keeps track of data. Different appli-
cations typically have different performance or QoS
requirements. Hence, the measurer usually needs to
be application specific. Experience data or data from
similar applications can be used to determine various
watermarks or threasholds.
3 Conclusion and Future Work
Software has become complex. Software architec-
ture evaluation, though conceptually simple, may not
be that easy in practice, especially from the perfor-
mance point of view. Software performance evalua-
tion is complicated and time consuming, and it may
be affected by many factors. In addition, the soft-
ware architect may need to focus on the application
level requirements or features as opposed to different
design alternatives at the lower layers.
The paper proposed an approach that potentially
could eliminate some of the burdens for the soft-
ware architect and provide more realistic estimation
for software performance or other QoS requirements.
4

In addition, the proposed approach could automat-
ically manage itself by conducting real-time mon-
itoring, measurement, or even performance model-
ing, and then selecting an architecture alternative to
better use the resources or meet QoS requirements.
The approach is built on a generative framework that
can be used to instantiate specific systems. More ar-
chitecture/design alternatives, e.g., newly identified
patterns or proven solutions, could be incorporated
into the framework.
The next phase is to implement the 5M model
discussed in Section 2 and integrate the modeling
techniques with the generative framework to facil-
itate resource usage estimation. Again, the main
point at this stage is for proof of concept. There are
other details that need to be taken care in order not
to disrupt the application at run-time. For instance,
socket communications and queuing management of
the HS/HA when it is switched to another design.
5