A simulation model to implement multiple client class server-client ...

A simulation model to implement multiple client class
server-client software architecture
1. Introduction
In this chapter we introduce the simulation environment, which will be used to apply the
proposed nonlinear control methodologies in this thesis. A simulation environment is vital to
evaluate, validate and compare the various existing control methodologies with the proposed
technique in a controlled environment. This is because a multi-client class system deployed in
physical resources (in other words a case study or test bed) provides variable performance even
under same settings/inputs in the multiple runs. A known limitation of simulation environments
is it abstracts away some of the behavior from the analysis to trade off between the consistency.
Therefore, the validation of this thesis utilizes the strengths of both the simulation and case study
based evaluations. In following sections, we provide a description of characteristics and the
process of multi-client class system followed by the architecture and implementation details of
the simulation environment.
2. Characteristics and requirements of a simulation
The main purpose of the simulation design in this thesis is to represent a model of a multiclient
class system, which can be used to generate artificial measurements and draw conclusions
from those measurements. The general architecture of a multi-client class system for performance
control is illustrated in the Figure 1. The workloads from the N client classes are sent
to the shared resource environment, which is then classified according to the client class id and
queued in client class specific queue by the Classifier component. The scheduler accesses the
queues and allocates the resources depending on the availability of the shared resources. It also
takes into account the resource allocation decisions made by the management system.
Such systems face variable workloads from multiple client classes competing for the available
resources. An incoming request may invokes different functionalities in the system, therefore
the time period a resource is reserved is also a variable. In addition, due to various other
characteristics exist in software systems, such as garbage collection processes, thread scheduling,
complier (just-in-time) optimization and memory competitions between components, the
resource reservation time periods may vary for a given request. Further, the multi-client class
systems are hybrid systems, which have a mix of continuous/discrete time and discrete event
based dynamics. For instance, a request arrival and request completion are discrete events in the
system, while the average response times of the requests are continuous/discrete time variables.
The main requirements of the simulation model in the performance management prospective
are as follows:
1. Simulate multiple (1 to N) client classes accurately.
2. Same consistent behavior under same input settings.
Preprint submitted to Chapter 3 September 5, 2011

Workloads of N client class
Classifier
Performance
measurements
Queue - 1
Queue – 2
...
Scheduler
Queue – N
Resource allocation
decisions
Shared computing
resources
Shared resource environment
Figure 1: Conceptual structure of multi-client class system
3. Ability to validate the correctness of the simulation model.
4. Accurate measurements of the system outputs (e.g. response times) of each client class.
5. Valid implementation of the resource allocation decisions.
6. Accurate average statistics of the required system parameters.
7. Ability to simulate variable workload rates over the period of simulation.
8. Modifiability, extendibility and scalability.
9. Fast and efficient execution.
3. Simulation environment
One of the main tools available to us to build a simulation environments is discrete event simulation
[1]. Discrete event simulation is widely used to test and analyze new systems, policies
before they are been implemented as a production system. Discrete event simulation environments
can be implemented by general purpose programming languages (e.g., Java, C#.Net) or
commercial simulation tools. As a consequence, in this work we build a Discrete event simulation
model to simulate a multi-client class environment, while achieving the requirements
mentioned in Section 2.
3.1. Brief introduction to discrete event simulation
A discrete event simulation (DES) is defined as
”Modeling of systems in which the state variables change only at a discrete set of points in time”
in [1]. A DES model consists of entities (e.g., clients, queues, and resources), attributes, events
(e.g., client arrival and departure), and activities (operation invocations, statistic collection). For
a given time instance, DES model has a snapshot of the system, which is updated based on the
events that is scheduled to happen in that time instance. Hence, a time advance algorithm is there
to keep track of the events that suppose to take place in a given time instance chronologically.
These events trigger activities in the system that may in turn produce new events that needs to
be executed in a future time instance or update the state variables of the system. After, these
events have taken place, the clock is advanced to the next time instance and the same process
2

is continued till the simulation end condition is reached. During the simulation or at the end of
the simulation statistics are gathered to analyze the results of the simulation. Generally, DES
model can be designed in an event-oriented and a process-oriented point of view. In the eventoriented
technique the DES model designer takes the events of the system and how they affect the
system state variables of the model as major concerns. On the other hand, process oriented point
of view enables to model the entities, their processes and how the inter-process communicates
take place. The event-oriented design produces simulations that can execute faster compared
to process-oriented design, however, modularity extendibility and the understandability of the
system is a trade-off. Both of these design techniques can be used, however process-oriented
design is popular among the commercial simulation products [1]. Further, a DES simulation
can be designed with deterministic and stochastic inputs and variables. For instance, a resource
utilization time is precisely 5 seconds for any request is deterministic, where as the utilization
time is determined by a probabilistic distribution is stochastic.
3.2. DES model of a multi-client class system
In this section, we provide implementation details of the simulation environments developed
following the guidelines provided in [1]. Here, we have taken the process oriented design
technique because it provides modularity, extendibility and convenience to design using general
purpose object-orient programming languages like Java and C#.Net. Further, we use stochastic
inputs and variables in this simulation to represent the variability in multi-client class systems.
The DES simulation model constructed has following entities (components) in the architecture
corresponding to the characteristic architecture of Figure 1.
MasterClock: This component keeps track of the current time instance of the system and
advances the time after all events and activities specific to the current time instance have taken
place. It triggers events on the tick (smallest time unit) and major tick (which is 1000 ticks).
Request: This represents a client request flowing through the simulation model. It has the
properties of client class Id, start time, end time and processing time. The processing time is
determined by a probabilistic distribution specified by the designer.
ClientClassWorkloadGenerator: This component generates workloads for a specific client
class. It needs a client class id, workload script and the corresponding queue instance at the
initialization. Then the process of this component is at each tick the workload script is analyzed
and generates the required number of requests that have to be sent to the system. Then, the
requests are initialized with the class id and the start time and enqueued to the corresponding
queue. Currently it can simulate deterministic time varying and stochastic (e.g., Poisson process)
workloads.
Queue: In a multi-client class system there is a corresponding queue to each client class
(see Figure 1). The Queue component is used for this purpose. It is a container of the requests
generated by the ClientClassWorkloadGenerator and ordered in a first-come-first-out fashion.
The simulation model needs N Queue instances to represent N queues.
ResourceUnit: The ResourceUnit entity is an abstraction of a resource unit in a multi-client
class system. It simulates the time period a resource is reserved/occupied/provisioned to serve a
request of a client class. It has the currently served request, serviced client class, status (idle or
working) as attributes. The process of this entity is at each tick, it simulates the processing time
specified on the request it is serving. When the request has utilized the resource for the specified
period of time it is assumed to be sent back to the client after stamping the end time. However,
in this simulation the copy of the served request is also sent to the statistical analysis component
to compute measurements such as response times.
3

Scheduler: The scheduler implements the resource allocation decisions required. For instance,
if the decision is to maintain 15 and 5 resource units for A and B client classes respectively,
this component implements these decisions until the next decision is made. It has the
access to the Queue instances of each client class, resource units and other state variables. In
each tick it executes the following algorithm for each client class. Say S i and i util are integer
variables representing the allocated resources of i th client class and currently utilized resources
by i th client class, respectively. Calculate the number of resources that can be allocated in this
time instance, by Di f i = S i −i util . Get the Di f i amount of requests from the Queue corresponding
to A client class and then the ResourceUnit instances are initialized with these requests. Further,
the i util variable is updated at the same time. Here, we have taken the design decision of
centralized scheduler, instead of each ResourceUnit class taking the responsibility of scheduling.
This is because, it is easy to track and validate the resource utilizations compared to a distributed
algorithm.
StatisticCalulator: This is the component that computes the measurement required to implement
the control systems. In particular, it calculates average response time, throughput and
resource utilizations for each client class on specified time periods. It has a list of completed
requests for each client class, which is populated by the ResourceUnit class after servicing the
requests. The designer specifies the time interval to calculate the statistics, which we call as the
sample instance. The statistic report generated will be used by the external entities for analysis
and make runtime decisions. Afterwards, the request lists are cleared to accumulate the completed
requests till the next sample instance. Following equations summarize how some of the
statistics are calculated for client class i.
Given the completed request list for client class List i , Throughput of the system T P i =
Count(List i ), i.e, the number of items in the list. The response time of the j th request r i, j =
r i, j .endtime − r i, j .starttime.
The total response time of all requests in the list
Tot i =
Count(List ∑ i )−1
j=0
Average response time is calculated by R i = Tot i
T P i
r i, j (1)
MainProgram: The designer can use this class to implement the required simulation depending
on the requirements. Depending on the number of client classes Queue instance have to be
created, then the required workload scripts have to be specified in client class specific workload
generator objects. In addition, the number of resource units that is available in the system has to
be specified in the scheduler. Further, probability distributions to simulate resource reservation
time and sample period has to be given depending on the simulation objectives.
Assumptions
1. Typically, the resource allocation decisions made by the management system are implemented
at each sample instance. However, some of the resource units are maybe occupied
by the requests that are being processed at that time instance. This may indicate that some
classes have more than the resources they are allocated for that time instance. Hence, to
implementation of the resource allocation decisions can be done in two different ways,
including preemptive and non- preemptive. In the preemptive setting, the number of over
utilized resources are forcefully taken away in order to allocate that resource to specified
4

class. This is a complex policy, which will cause jittery behavior in system measurements,
inconsistent states in transaction and additional overhead on the shared resource
system during the implementation at runtime [2, 3]. In contrast, in the non-preemptive
setting, the resource is taken away once the request being processed is completed. The
non-preemptive setting is a desirable configuration for shared resource environments [2].
Thus, we have implemented this non-preemptive setting in the scheduler process of the
simulation model. However, the inaccuracy in decision implementation can be reduced by
selecting the processing times comparatively smaller than the sample period. For instance,
if the service time varies in ticks range, sample period can be selected in major ticks. This
means the decision made will be implemented before the next decision made. In addition,
a large amount of requests will be processed during a sample time so that the error due to
incomplete requests during a sample period becomes insignificant.
2. End-to-end response time is not a consideration.
3. Time taken to reschedule the resource is assumed to be zero.
4. Overhead from the scheduler and the statistic calculator is zero.
From the various simulations designed and executed from this implementation indicated that
it can simulate consistent behavior under same settings and N number of clients. It also provides
accurate measurements of the system outputs, correct implementations of resource allocation
decisions and fast executions. The process-oriented design approach taken in this implementation
provides modularity by delegating responsibilities among entities and extendibility. Therefore,
this DES simulation model achieves many of the requirements mentioned in Section 2. What
is left is verify and validate this DES model is capable to simulate the complex behavior of a
multi-client class system.
4. Validation of the DES model
After building a simulation, the next major step is to verify and validate the implementation.
In this section we provide three forms of validations using queuing theory. It is noteworthy
that to apply queuing theory, certain assumptions on the system structure, arrival workloads
and processing time statistical distributions should hold. In the following sections, the required
simulation systems are constructed using the DES model proposed in Section 3, adhering to the
assumptions.
4.1. Conformant to Little’s law
One of the fundamental results of queuing theory was developed by John Little in 1960’s,
which is used as a basic building box in the development of theories of large scale queuing
systems. Little’s law is defined as follows:
For a queuing system in steady state, if the mean time waiting in the system is W = E(T),
and the mean number of customers entering the system is λ, then the mean number of customers
in the system is given by E(L) = W × λ. This result applies to any queuing system and even to
systems within a system. However, system has to be in steady state, meaning that the arrival rate
should be less than the service rate of the system. Therefore, the simulation model presented in
this chapter can be validated using Little’s law.
In order to do the validation, we constructed a queuing simulation using the constructs introduced
in Section 3. We used two client class workload generators and queues with 5 resource
5

Average
waiting
time Class
1(W 1 )
Table 1: A comparison based on Littles law
Average
waiting
time Class
2(W 2 )
Total
number
of customs
class
1(N 1 )
Total
number
of customs
class
2(N 2 )
Measured
average
number of
customers
in the
Calculation
of littles
law
W 1 × N 1 +
W 2 × N 1
system
54.53763 51.49038 93 104 0.20854 0.20854
46.25325 49.35146 999 993 1.90426 1.90426
28.23506 29.22124 1238 1243 1.42554 1.42554
14.12709 14.39264 1676 1658 0.9508 0.9508
17.09113 17.26543 2030 1944 1.36518 1.36518
14.42547 14.40802 2536 2468 1.44284 1.44284
units for each client class in this validation. We used 18 combinations of stochastic arrival rate
and service rates from exponential distribution to simulate workloads and processing times of
both client classes. All these combinations were selected to maintain the system in the steady
state. The workload scripts generated from arrival rate were given to the ClientClassWorkload-
Generator instance of each client class and the processing times of ResourceUnits were generated
from service rate from exponential distribution in each experiment. A experiment was conducted
for 50,000 ticks. The StatisticCalulator instance was used to compute the final statistics of the
experiment including, the average response time, average arrival rates and average number of
customers in the system. In these calculations the system was considered as two sub systems,
each providing services to a corresponding client class. The comparison of the statics were done
as the total number of clients in these two sub systems as equal to total measured number of
clients in the systems when both sub systems considered together. These statics were an exact
match for all of these experiments. Some of the selected experimental results are summarized
in Table 1 indicates that measured number in the system is precisely equal to the calculations of
the Little’s law. The same results were observed for the experiments conducted in deterministic
arrival and service rates. Hence, the multi-client class simulations implemented from the DES
model described in Section 3, precisely conform to the Little’s law. This result also indicates that
all the request input to the system leave the system. Further, implementation of the DES model
including the statistical calculations is correct.
4.2. Conformant to single-server queuing system (M/M/1)
In this section a single-server queuing system is developed and simulated, and then the measurements
are compared to theoretic results of (M/M/1) queuing system from literature. The
simulation was implemented with a single resource unit and queue. The workload script of a
single client is generated according to Poisson arrival process. The resource reservation time
(processing time) is generated according to the exponential distribution. All the components
available from the DES model are used in this implementation as well. The 18 experiments were
conducted with the same arrival and processing time combinations utilized in Section 4.1. Due
to the measured results are compared with probabilistic theoretical values, each experiment was
run for 200,000 ticks. As the basis of validation, we compared the measured average number of
customers in the system from the simulations with the expected number of customers calculated
6

Table 2: A comparison based on single-server queuing system (M/M/1)
λ µ L theoretical L measured
0.02 0.1 0.247 0.244
0.025 0.067 0.423 0.418
0.04 0.056 2.622 2.591
0.022 0.03 2.799 2.756
0.02 0.027 2.838 2.801
0.02 0.04 0.979 0.968
0.033 0.067 0.976 0.96
from queuing theoretic results. Let us say λ and µ represents the mean arrival rate and mean
service time respectively. Theoretically the expected customers in the system is calculated as
follows:
L theoretical =
λ
µ − λ
So that, given the simulated λ and µ, the L theoretical calculated from equation (2) should approximately
equal to L measured from the simulation. In order to quantify the statistical significance of
the difference, we also conducted a Kolmogorov-Smirnov test using the data of the 18 simulations
conducted under different λ and µ. The compassion of results of some of the experiments are
summarized in Table 2.
The results of Kolmogorov-Smirnov test producedx D statistics of 0.11 and P statistic of 1.
In nutshell if the P value is less than 0.05 there is significant difference between the data sets.
However, since for this case P = 1 concludes that the data set of L measured and L theoretical has no
significant difference. As a consequence, the single-server queuing system (M/M/1) constructed
from the DES model conform to the queuing theoretic results. This confirms the M/M/1 queuing
system implemented using the DES model constructs which includes scheduling of a single
queue and resource is correct.
4.3. Conformant to multi-server queuing system (M/M/c)
In this section we construct a multi-server queuing system serving a single queue. For this
system, the same assumptions used in Section 4.2 are maintained. However, (c=) 5 resource units
are used to represent 5 servers in the system. 18 experiments were conducted under same settings
as in Section 4.2 in order to gather measurement data. The same measurement of the average
number of customers in the system was used for the comparison. The theoretical calculation is
done as follows:
r c
∑c−1
p 0 = (
c!(1 − ρ) + (c − 1) r n
n! )−1 (3)
L theoretical = r +
n=0
(2)
r c ρ
c!(1 − ρ) 2 p 0, (4)
Where r = λ µ , ρ = r c
, c = number of servers (5 for this experiment). The results are summarized
in Table 3.
7

Table 3: A comparison based on multi-server queuing system (M/M/c)
λ µ L theoretical L measured
0.02 0.1 0.2 0.198
0.025 0.067 0.375 0.367
0.04 0.056 0.72 0.728
0.022 0.03 0.734 0.722
0.02 0.027 0.74 0.739
0.02 0.04 0.5 0.492
0.033 0.067 0.5 0.495
The Kolmogorov-Smirnov test computed D statistics of 0.16 and P statistic of 0.95 similar
to the earlier the case of single-server queuing system indicating that the data set of L measured and
L theoretical has no significant difference. Thus, the (M/M/c) queuing system developed for this
case also conforms to the theoretical results.
We conclude the theoretical validation of the DES model built to be used in this thesis with
the above three validations. The results are not exactly equal to the theoretic results because of the
slight numerical inaccuracies of the implementations of probabilistic distributions. In addtion,
the multi-client class systems fall under multi-server multi-class queuing systems. Well known
exact theoretical results are not available so far for such systems, so that we limited our validation
to multi-server queuing systems. With this result we can justify that the implementation of the
constructs of DES model, including scheduling of multiple resource units and queuing is valid.
5. Simulation settings
Using the above generalized DES model, we setup a simulation system to apply and validate
the proposed nonlinear control theoretic approaches in this thesis.
5.1. Workload profiles
The workloads, a multi-client class system may face cannot be generalized. The workload
a system can manage depends on the capacity of resources, management requirements and performance
objectives. The workload profile for a system with CPU as the shared resource may
differ from a system with concurrent threads as a shared resource. In addition, the workloads are
time-varying, instead of staying constant for entire period of operations. This characteristic is
not only limited to software systems, but to other physical systems as well. As a consequence,
control engineering provides set of well-established input signals to validate the performance
of the control systems. They are as follows: Assume, W n is the nominal workload that system
receive.
Impulse input signal: Formally, W impulse (k) = 1 when k = 0 and k 0. i.e, the impulse
input signal increases the workload to some value greater than W n for a single sample period.
In a real workload this can be considered as a workload spike for a very short time period.
However, such spikes for very short periods of time may not affect the performance attributes
(e.g., average response time) drastically, consequently the impulse input signal may not be useful
for the validations of the control systems of software systems.
Step input signal: Step input signal models a sudden jump in the workload from W n to
some value W step and staying at that value for a more than a single sample period. This is one
8

of the widely used input signals to validate the performance of the control systems in control
engineering. In addition, most of the applications of feedback control in software systems, including
multi-client class systems have used step workload changes to validate the performance
and resource management capabilities. This is because, such workload changes of even a single
client class in a multi-client system for a long period of time affects the performance attributes
(e.g., response time) under control. As a consequence, the control system is forced to redistribute
the available recourses among client classes, in order to achieve the required performance objectives.
The delay in response to such workload variations may cause large transient responses and
temporal instabilities in the system. Therefore, this is a significantly difficult load variation to
handle [2, 3, 4, 5].
Ramp input signal: Ramp input linearly increases the workload from W n to W ramp during
sometime interval. This signal models a gradual increase of workload instead of instantaneous
increment of workload compared to step input signal.
The main advantage of these input signals is given a linear model of a system, there are wellknown
design and analysis techniques available from control theory to compute performance
specifications and behavior. Consequently, after constructing a linear model of a system we can
investigate/prove the load variations that the system can maintain without leading to instabilities.
However, a linear model of a system is an estimation of its behavior (not 100% accurate
representation), so that these theoretical evaluations may not be correct 100%. Further, this is
also true for systems demonstrating nonlinearities such as the system under investigation in this
thesis. As a consequence, we have to mention that the combinations of workload input signals
(in particular, step input profiles) in time varying fashion are used as heuristics to validate and
compare the performance of the control systems.
5.2. Total resource amount and resource reservation time distribution
The following settings will be used as an abstract representation of the multi-client class
system in the simulations. The settings will remain the same unless otherwise specified. The
total amount of resources simulated S total = 30. The processing time of each resource unit is
selected from a uniform distribution as follows :
1
r(x) = for r min ≤ x ≥ r max
r max − r min
(5)
= 0 for x < r min and x > r max (6)
Where, r min = 100 ticks and r max = 700 ticks. The selection of the above settings is done, in order
to achieve the tractability of resource allocations among client classes under different experiment
conditions. The r min and r max , were selected after careful investigation of system outputs under
different workload conditions. That is when the system is running close to the full capacity the
system output should remain within some bounds, according to theoretical and practical system
behavior. The Figure 2 shows a comparison when 30 resource units are allocated to two client
classes with 30 req/sec workloads for each class. When the selected bounds r min = 100 and r max =
700 ticks, maintain the system in steady state under the applied resource settings. However, under
the same settings, when the bounds are r min = 100 and r max = 900 ticks, the steady state behavior
is highly variable/unstable. This is because the variability around the average response time leads
to large transient response in the system. To avoid such behaviors the resource capacity and the
workload intensity have to be selected depending on the bounds. For the workloads rates and the
resources we selected to evaluate, r min = 100 ticks and r max = 700 are suitable bounds.
9

2
2
R 1
R 1
Response time
1.5
1
0.5
R 2
Response time
1.5
1
0.5
R 2
0
20 40 60 80 100
Sample Id
(a) 100-700
0
20 40 60 80 100
Sample Id
(b) 100-900
Figure 2: System behavior under 2a) r min = 100 and r max = 700 ticks 2b) r min = 100 and
r max = 900 ticks
Further, selection of the uniform distributed processing time means that any operations invoked
in the system is equally likely, so that we can get fair weight for each invocation. This is
done because there is neither evidence nor a generalization available to represent the invocation
patterns of the operations and their system output (e.g., response time) bounds. Such selections
are done in [3, 6].
In addition, 2000 ticks were selected as the sampling time period of the statistic calculation
process. The selection of the sample time period has to be carefully done in physical systems. For
instance, a small sample time invokes the statistic calculations frequently leading to additional
overhead on the system. In addition, short sampling intervals affects variability of the measured
average statistics. In contrast, large sampling times may cause decision delays, under sudden
changes of the workloads or other conditions, leading to instabilities. Therefore, there is a tradeoff
in the selection of the time interval. We selected 2000 ticks after analysis of the workload rates
and changes we will be applying in the system. Further, it reduces the effect of the assumption
(1), listed in Section 3.
6. Simulation vs. Physical system behavior
It is also important how the simulated multi-client server system behave corresponding to the
behavior of real physical systems. There are many existing work related to performance management
has analyzed the behavior of their case studies (based on physical systems) under different
workload conditions. For instance, such analysis can be found for the cases of web servers [7, 8],
data centers [4, 9], multi-tenant class systems [10, 11], multi-client class systems [12, 13, 14]
and so on. One of the common experiments conducted is by changing the available resource in
some order (increasing or decreasing in small steps) and measuring/plotting the system output
(commonly the response time) under a constant deterministic workload. Common characteristic
of all these example physical systems are shown in Figure 3. That is when resource share is
sufficient to handle the incoming workload the response time remains in a steady value (or with
low variations). That is the response time is insensitive for the resource share. However, when
the resource share is insufficient the response time increases in a high rate. That is response time
is highly sensitive to the resource share. However, this behavior highly depends on the workload
settings as well (see [7, 4, 8, 9] for detailed analysis).
10

Response time (seconds)
Response time is highly sensitive
due to lack of resources
Response time is
insensitive due to
excessive
resources
Resource share
Figure 3: Abstract response time behavior against the resource share observed in physical systems
Response time
5
4.5
4
3.5
3
2.5
2
30 req/sec
40 req/sec
50 req/sec
60 req/sec
70 req/sec
80 req/sec
1.5
1
0.5
0
14 16 18 20 22 24 26 28 30
Resource amount
Figure 4: A comparison of response time behavior of the simulation environment with the resource
allocation in different workload conditionss
In this section, we conduct such an experiment with a single client class system using the
same settings described in Section 5. Here, the average response time of the system is observed
while decreasing the available resource units from 30 to 14 for different workload conditions.
The Figure 4 illustrates the behavior of the system output (response time) with respect to the
resource allocation. The common observation under different workload conditions is when the
incoming workload can be handled by the available resources the response time remains at a
steady value. For instance, the response time is not affected by the 30 req/sec workload, because
of 14 resource units are adequate to handle that workload. When we increase the workload rate,
at certain resource allocation levels the response time starts to increase at a high rate moving the
system to highly sensitive region (see Figure 4). Therefore, the behavior of this simulation is
same as the behavior of real physical systems investigated in literature (see work [7, 4, 8] for
similar experimental results).
This experiment also indicates that 80 req/sec workload is the maximum capacity of the system
for 30 resource units. However, this is not a linear relationship. For instance, this relationship
indicates that with 15 resources, a 40 req/sec workload can be handled. However, graph for 40
req/sec indicates that 15 resources move the system to highly sensitive region. As a consequence,
11

when tenants are placed in on a shared resource environment the total capacity with mixed workload
of these tenants is less than that of when system is considered as single class. For instance,
if two tenants share 15 resource units each total workload capacity it can handle is approximately
60 req/sec. Such behavior also pointed out by Kwok et al in [10].
7. Summery
This chapter presented the characteristics, requirements and importance of a simulation environment
to represent a multi-client class system. Using popular discrete event simulation mechanism,
we presented an appropriate discrete event simulation model to implement multi-client
class systems with different settings. Then the model implementation was validated using queuing
theoretic principles. The simulation settings that will be used in the rest of the chapter were
also presented. Finally, the behavior of the simulation environments was compared to the behavior
of physical systems utilizing the case studies available from the literature.
References
[1] J. Banks, J. Carson, B. L. Nelson, D. Nicol, Discrete-Event System Simulation (4th Edition), 4th Edition, Prentice
Hall, 2004.
[2] C. Lu, Y. Lu, T. F. Abdelzaher, J. A. Stankovic, S. H. Son, Feedback control architecture and design methodology
for service delay guarantees in web servers, IEEE Trans. Parallel Distrib. Syst. (2006) 1014–1027.
[3] C. Lu, Feedback control real-time scheduling, Ph.D. thesis, University of Virginia (2001).
[4] P. Padala, Automated management of virtualized data centers, Ph.D. thesis, University of Michigan (2010).
[5] J. L. Hellerstein, Y. Diao, S. Parekh, D. M. Tilbury, Feedback Control of Computing Systems, John Wiley and
Sons, 2004.
[6] L. Chenyang, J. Stankovic, G. Tao, S. Son, Design and evaluation of a feedback control edf scheduling algorithm,
in: Real-Time Systems Symposium, 1999. Proceedings. The 20th IEEE, 1999, pp. 56 –67.
[7] Z. Wang, X. Zhu, S. Singhal, Z. Wang, X. Zhu, S. Singhal, Utilization vs. slo-based control for dynamic sizing of
resource partitions (2006).
[8] X. Zhu, Z. Wang, S. Singhal, Utility-driven workload management using nested control design, no. HPL-2005-
193R1, Hewlett Packard Laboratories, 2006, p. 8.
[9] P. Pradeep, H. Kai-Yuan, S. K. G., Z. Xiaoyun, U. Mustafa, W. Zhikui, S. Sharad, M. Arif, Automated control of
multiple virtualized resources (2009).
[10] T. Kwok, A. Mohindra, Resource calculations with constraints, and placement of tenants and instances for multitenant
saas applications, in: Proceedings of the 6th International Conference on Service-Oriented Computing,
ICSOC ’08, Springer-Verlag, 2008, pp. 633–648.
[11] Z. H. Wang, C. J. Guo, B. Gao, W. Sun, Z. Zhang, W. H. An, A study and performance evaluation of the multitenant
data tier design patterns for service oriented computing, in: IEEE International Conference on e-Business
Engineering, 2008. ICEBE ’08., 2008, pp. 94 –101.
[12] Y. Lu, T. Abdelzaher, C. Lu, L. Sha, X. Liu, Feedback control with queueing-theoretic prediction for relative delay
guarantees in web servers (2003).
[13] M. Karlsson, X. Zhu, C. Karamanolis, An adaptive optimal controller for non-intrusive performance differentiation
in computing services, in: In IEEE Conference on Control and Automation (ICCA), 2005.
[14] M. Litoiu, A performance analysis method for autonomic computing systems, ACM Trans. Auton. Adapt. Syst. 2.
12