Quality of Service Enabled Database
Applications
S. Krompass, D. Gmach, A. Scholz, S. Seltzsam, and A. Kemper
TU M¨unchen, D-85748 Garching, Germany
{krompass,gmach,scholza,seltzsam,alfons.kemper}@in.tum.de
Abstract. In today’s enterprise service oriented software architectures,
database systems are a crucial component for the quality of service (QoS)
management between customers and service providers. The database
workload consists of requests stemming from many different service classes,
each of which has a dedicated service level agreement (SLA). We present
an adaptive QoS management that is based on an economic model which
adaptively penalizes individual requests depending on the SLA and the
current degree of SLA conformance that the particular service class
exhibits. For deriving the adaptive penalty of individual requests, our
model differentiates between opportunity costs for underachieving an
SLA threshold and marginal gains for (re-)achieving an SLA thresh-
old. Based on the penalties, we develop a database component which
schedules requests depending on their deadline and their associated pen-
alty. We report experiments of our operational system to demonstrate
the effectiveness of the adaptive QoS management.
1 Introduction
Future business software systems will be designed as service oriented architec-
tures. These services are accessed via the Internet by a variety of different users
– as exemplified by providers and vendors of Web-based business software, in-
cluding RightNow Technologies, Salesforce.com, hosted SAP, and Oracle. This
Web-based software is characterized by a multitude of services which invoke
other enterprise services and ultimately submit requests to databases. The Web-
based business software is made accessible for a multitude of customers, where
each customer may have individual quality of service (QoS) requirements. The
more customers access the services, the more they compete for system resources.
In an uncontrolled environment this may lead to unpredictable and unaccept-
able response times. To prevent the customers from suffering bad performance
in terms of response times of their invoked services, service level agreements
(SLAs) are negotiated.
An SLA is a formal agreement between the service provider and a customer. The
establishment of an SLA imposes obligations on the service provider regarding
the service level of the provided services. If the constraints formulated in the
SLA are violated after a certain time window, the evaluation period, the service
provider is fined. The penalty depends on the severity of the SLA violation and
is negotiated in the SLA. SLAs are typically only defined for services directly
invoked by customers. Thus, the goal is to establish an end-to-end control for
the quality of service, which covers all layers of the Web service architecture.
The contribution of this paper is to enable QoS for the bottom layer of a ser-
vice infrastructure, where almost all services access a shared database. This is
a very common scenario in mission-critical enterprise services that rely on an
integrated database. For this scenario, we assume that an SLA for every service
submitting requests to the database has been negotiated. Due to the multitude
of services which access the database, the workload of the database consists of
requests stemming from many different customers with different service classes,
each having a dedicated SLA.
The challenge is to schedule incoming database requests in order to meet the
performance goals specified in the SLAs. Scheduling is based on adaptive prior-
ities which are derived from the current level of conformance with the request’s
SLA, that is, the percentage of timely requests, and the economic importance of
this SLA relative to other pending requests’ SLAs.
Current solutions in database systems, e.g., the Query Patroller for DB2 [7] or
the Oracle Resource Manager [13], assign groups of customers to performance
classes with static priorities. Thus, each request is assigned its priority depending
solely on the client by whom it has been submitted. This static prioritization
is used to schedule the requests, so that high-priority clients should complete
faster on average than their low-priority counterparts.
This approach is sufficient to fulfill the requirements of particularly valuable cus-
tomers. However, it cannot adequately manage overall SLA enforcement. Con-
sider an SLA which requires 90% of all service requests to be processed within
a certain time window. With static prioritization, SLAs for high-priority cus-
tomers are likely to be overfulfilled by processing almost all requests in time.
However, during peak-load times, it is likely that they overachieve their SLAs at
the expense of lower-priority users. From a business-oriented point of view, it is
desirable to provide only the service level which has been negotiated in the SLA.
If SLAs are not overfulfilled, the additional free resources are used for satisfying
SLAs that are violated with the static prioritization.
For this purpose, we developed a QoS management concept based on an economic
model which adaptively prioritizes individual requests depending on the SLA
and the current degree of SLA conformance that the particular service class
exhibits. The core of the QoS management consists of penalty-carrying requests,
that is, database requests which carry the requirements needed to fulfill the SLA
constraints from the submitting service to the database.
The rest of the paper is organized as follows: Section 2 describes the two cost
components, marginal gains and opportunity costs, of our QoS model in de-
tail and presents the adaptive QoS management with which penalty-carrying
requests are derived. Section 3 describes the system architecture and the im-
plementation of our QoS management. The scheduling of the requests is in the
focus of Section 4, followed by the evaluation results of our prototypical imple-
mentation in Section 5. An overview of related work is presented in Section 6.
Finally, in Section 7, we summarize the conclusions of our study and outline
ongoing and future research on this subject.
2 Quality of Service Model
The central concept of our quality of service management is adaptive penaliza-
tion of individual requests according to the current degree of SLA conformance
c. The conformance is monitored per service class, that is, for each transaction
type invoked by an individual customer and the associated SLA. We define c as
c =
Number of timely transaction invocations
Total number of invocations of the transaction
In practice, so-called step-wise SLAs are commonly used to specify the QoS
requirements of a service class. The SLAs consist of one or more percentile con-
straints and an optional deadline constraint. Percentile constraints require n%
of all service requests to be processed within x seconds. If a percentile constraint
is violated after the evaluation period, a penalty p for every m percentage points
under fulfillment is due. Furthermore, p
max
defines a maximum penalty for vi-
olating a percentile constraint. The deadline constraint – which does not incur
any penalty – specifies an upper bound for the execution time of the service
request. An example for a step-wise SLA with one percentile constraint d
1
and
one deadline constraint d
2
is shown in the following:
d
1
: 90% in less than 5s; p = $900 per 10 percentage points of underful-
fillment, p
max
= $1800; evaluation period: 1 month
d
2
: Deadline 15s
The constraints above control the response time and the throughput of Web ser-
vice transactions. In general, SLAs contain additional constraints such as sizing
constraints which restrict the maximum number of transaction invocations per
time period. We concentrate on fulfilling the percentile and deadline constraints,
assuming any additional SLA constraints are obtained.
500
1000
1500
Service level conformance
2000
Penalty in $
0.65 0.7 0.75 0.8 0.85 0.9 0.950.6 1
1
0
s
3
Service level
SLA penalty
Marginal gain (mg)
Opportunity costs (oc)
s
1
Service level
s
2
Service level
c
3
c
2
c
1
mg(c’) = $441
oc(c’) = $81
2
c’=0.87 (current service
level conformance)
2
Fig. 1. Visualization of SLA constraint d
1
A percentile constraint in a fixed step-wise SLA implicitly defines an SLA penalty
function with n steps. The penalty function for d
1
of our sample SLA is shown
as the step function in Figure 1 (black solid lines). With c
i
, 1 ≤ i ≤ n + 1, we
denote the boundaries of the steps of the SLA penalty function. For the example
in Figure 1, we have c
4
= 0 (not in the figure), c
3
= 0.8, c
2
= 0.9, and c
1
= 1.
Using the SLA penalty function, we define service levels as follows: For a penalty
function with n steps, let s
i
, 1 ≤ i ≤ n, denote the ith service level. This level
is defined in the interval [c
i+1
, c
i
[, so that dropping to a lower service level
corresponds to a higher penalty. Thereby, s
i+1
denotes a lower service level than
s
i
, that is, the penalty incurred at s
i+1
is higher than at s
i
. We denote ∆
i
as
this cost difference between s
i+1
and s
i
.
As shown in Figure 1, our sample percentile constraint d
1
implicitly defines three
service levels: Service level s
3
is defined in the interval [0, 0.8[, s
2
in [0.8, 0.9[,
and s
1
in [0, 1]. The cost difference between service levels s
3
and s
2
is $900 which
is identical to the cost difference between s
2
and s
1
.
2.1 Penalty-Carrying Requests
Penalty-carrying requests are queries with attached penalty information in a
SQL-comment. For example, the penalty-carrying request for a select-Statement
looks like this:
/* penalty ...
* de ad line ... */
s e l e c t . . . f r o m . . .
We use the SLA penalty function to compute these adaptive penalties for indi-
vidual service requests. In the following section, we describe how to compute the
adaptive penalty from the percentile constraint for an individual request. Then,
we describe briefly the derivation of the deadline constraint for an individual
query.
2.2 Deriving the Penalty for Individual Requests
The penalty of an individual request is covering two different economic aspects.
On the one hand, the opportunity costs model the danger of falling into the next
lower service level. If the current SLA conformance c converges to the next lower
service level, the penalty for processing the service too late increases, because
delaying a further request increases the danger of an ultimate SLA violation.
Then, the opportunity costs oc are piece-wise defined quadratic functions which
are defined as follows:
oc(c) :=
³
c
n−1
−c
c
n−1
−c
n
´
2
· ∆
n−1
, c
n
≤ c < c
n−1
· · ·
³
c
1
−c
c
1
−c
2
´
2
· ∆
1
, c
2
≤ c < c
1
0, otherwise
The rationale for choosing squared terms is given below. For the opportunity
costs, we derive the decreasing parts of the parabolas as in Figure 1.
On the other hand, with marginal gains, we model the chance that a service class
re-achieves a higher service level, that is, reaches s
i
from s
i+1
. If this appears to
be “within reach”, individual requests are penalized more and more to eventually
achieve the higher level. The marginal gain mg is a piece-wise quadratic function:
mg(c) :=
³
c−c
n+1
c
n
−c
n+1
´
2
· ∆
n−1
, c
n+1
≤ c < c
n
· · ·
³
c−c
3
c
2
−c
3
´
2
· ∆
1
, c
3
≤ c < c
2
0, otherwise
Analogous to the opportunity costs, the rationale for choosing squared terms is
given below. The marginal gain is depicted as increasing part of the parabolas
in Figure 1.
If the SLA conformance of a request’s service class is approaching the next
lower service level, the chance for reaching the next higher service level is very
small. Thus, the penalty of a request of this transaction is dominated by the
opportunity costs. Similarly, the penalty is dominated by the marginal gain if
the next higher service level is “within reach”. Therefore, we define the penalty
as the maximum of the computed opportunity costs and the marginal gain of
this service request.
To define opportunity costs and marginal gains, we use a squared term – resulting
in the parabolas – to weight the distance from the borders of neighboring service
levels. If linear terms are used, requests stemming from SLAs with high penalties
are almost always be handled with top priority, because there is only a very
small area in the middle of a service level where the calculated penalties are
low. This leads to overfulfillment and therefore an inferior overall performance.
In contrast to that, if the order of the functions is chosen too high, the request
has high priority only for SLA conformances near the borders of the next higher
and next lower service level, respectively. So, if the opportunity costs are defined
by higher order polynomials, there are only very few requests with high priority.
If all of these requests are delayed, e.g., by waiting for database locks, the SLA
conformance falls onto the next lower service level. To justify this rationale,
we conducted extensive experimental studies, which cannot be reported here
for space limitations. These studies have shown that squared terms were better
suited to model the opportunity costs and marginal gains than linear order higher
order terms.
2.3 Deriving the Deadline Constraint for Individual Requests
The time constraint of a deadline constraint x
d
specifies an upper bound for
the processing time of a transaction. We therefore need to derive the deadlines
for individual requests of that transaction. Requests which have passed their
deadline are scheduled with maximum priority, that is, they are not delayed by
other requests and most likely have a processing time that is less or equal to
