Using Stochastic Petri Nets for Performance Modelling of
JBoss Application Server
Fábio N. Souza
1
, Roberto D. Arteiro
1
, Nelson S. Rosa
1
, Paulo R. M. Maciel
1
1
Centro
de Informática
–
Universidade Federal
de Pernambuco (UFPE)
Caixa Postal 15.064
–
91.501
-
970
–
Recife
–
PE
–
Brazil
{
fns
,
rda,nsr,prmm
}@
cin.ufpe
.br
Abstract.
Application servers have been widely adopted as distributed
infrastructure (or middleware) for developing distributed systems. Current
approaches for performance evaluation of application se
rvers have mainly
concentrated on the adoption of measurement techniques. This paper,
however, focuses on the use of simulation techniques and presents an
approach for performance modelling and evaluation of application servers
using Petri nets. In order t
o illustrate how the proposed approach may be
applied, we present Petri net models of JBoss application server and compare
its performance results against ones that have been measured.
1.
Introduction
The number of middleware products available for building d
istributed applications is rapidly
increasing. Those products are usually implemented according to open standards such as RM
-
ODP (Reference Model
–
Open Distributed Processing) [06], CORBA (Common Object
Request Broker Architecture) [16] and EJB (Enterpris
e JavaBeans) [17]. Additionally,
proprietary middleware such as MQSeries (IBM) and .NET (Microsoft) have also been
widely used by distributed application developers. Such variety of standards and products
leads to
a difficulty regarding the comparison of
t
heir performances. In general, it is necessary
a careful analysis of the system’s architecture in order to achieve high performance. System
administrators and researchers should rely on the use of modelling techniques, since it is
laborious to accurately p
redict the performance behaviour of these technologies. The use of
simulation techniques to model middleware behaviour assume an important role in its
performance analysis once we can obtain valuable performance information without having
extra costs assoc
iated with the replication of the real environment.
The modelling and performance analysis of middleware systems is a recent research
area. Cecchet [02] presents an analysis of the impact of application and container
architectures in the overall performan
ce of an Enterprise JavaBeans (EJB) system using
measurement techniques. To do that, Cecchet implements five versions of a benchmark
application varying its design. These applications are installed in JBoss and JOnaS and
performance metrics are annotated.
Commonwealth Scientific and Industrial Research
Organisation (CSIRO) [03] provides a detailed evaluation and comparison of different
application servers presentin
g a qualitative analysis of their
features and a quantitative analysis
based on performance a
nd stress tests realized using a stockbroking benchmark application.
Koenev [10] examine the effect of different configuration parameters in performance of the
JBoss Application Server. Khorasani [08] presents a model for Middleware in
telecommunications f
ocusing on the performance issues. Verdickt [19] proposes an extension
of the traditional queue networks systems, namely Layered Queuing Networks (LQN), to
model the performance of the Common Object Request Broker Architecture (CORBA).
Lladó [12] presents
an analytical model based in queuing theory that is suitable for
performance analysis of EJB systems. Lladó [13] compares versions of the analytic model
against a simulation run of the same model. Abdul
-
Fatah [01] has implemented four different
test proto
types based on the CORBA architecture, with different configurations for client
-
server interaction. The experiment results clearly show that there was no better choice
amongst them. The authors affirm that a better solution depends on the load requirements
of a
particular application. Due to the difficulty to set up test environments, we consider such
results as an indication to the need of analytical and simulation models for Middleware
systems. Liu [11] proposes a model for performance analysis of middlew
are based on LQN
and its precision has been compared against the results obtained by measurements performed
using the IBM CrossWorlds InterChange Server. Koenev [09] uses Non
-
Product
-
Form
Queuing Networks to propose an analytical model for the SPECjAppServ
er2002 J2EE
benchmark application.
The main objective of this paper is to model and evaluate the performance of
application servers using Petri Nets. Particularly, we focus on the analysis of application
servers due to its enormous utilization in the mark
etplace. In turn, the adoption of Petri Nets
has been based on the fact that it is a suitable formalism for system performance evaluation,
whilst it allows a natural modelling of various services offered by application servers (e.g.
instance pool).
The re
mainder of this paper is organized as follows. Section 2 briefly presents theory
of Stochastic Petri Nets and basic concepts of application servers. Section 3 presents our
Petri net modelling approach. Next, Section 4 presents the validation of the develop
ed models
using simulation and measurement techniques. Finally, Section 5 presents some concluding
remarks and future works.
2.
Background
2.1
Stochastic Petri Nets
Petri nets are a family of formal specification techniques that allows for a graphical,
mathematic
al representation and have powerful methods, which allow designers to perform
qualitative and quantitative analysis. Place/transition Petri nets are used to model a logical point
of view of the systems, however no formal attention is given to temporal rela
tions and
constraints. Generalised and Stochastic Petri Net (GSPN) [14] is one of the most extensively
adopted classes of stochastic Petri nets. A GSPN is def
ined as a tuple
(P, T, I, O, H,
G,
M0,
W, Π)
where:
P
is a set of places;
T
is a set of transition
s;
I
,
O
and
H
are relations describing
pre
-
conditions, post
-
conditions, and inhibition conditions, respectively; and
M0
is a mapping
from the set of places to the natural numbers describing the model's
initial
state. The set of
places represents the set o
f resources, local states and system's variables. The set of
transitions represents the set of actions. This set is divided into two subsets: the set of
immediate
transitions
that
depicts a set of irrelevant actions under the performance point of
view; and
the subset of timed transitions. Besides, two other functions are taken into account
for representing timing (and weights) and priorities. The function W associates to each timed
transition a non
-
negative real number, depicting the respective exponential
transition delay (or
rate), and to each immediate transition a non
-
negative real number representing its weight. The
priority function
Π
associates to each immediate transition a natural number that represents the
respec
tive transition priority level.
Finally,
G
is an enabling function that given an immediate
transition and a model’s state determines if the transition is or not enabled
.
T
ransitions are fired
under interleaving firing semantics, a common semantics adopted even in the untimed
place/transition model. However, immediate transitions have higher priority than those timed
transitions.
2.2
J2EE and Enterprise Java Beans
Java 2 Platfor
m, Enterprise Edition specification [18] defines a standard environment to
support the development and deployment of Java distributed applications. Implementations of
this specification are referred to as J2EE application servers.
The core of J2EE specif
ication is the definition of a framework for the development of
server
-
side components known as Enterprise JavaBeans (E
JBs) [17]. Instances of EJB
components (bean instances)
are hosted in a runtime environment, named EJB container,
which takes responsibil
ity of managing their life cycle, managing resources in
their
behalf and
providing them with predefined system
-
level services such as transaction management and
security.
EJBs call on these services declaratively by configuring them in a XML file known as
deployment descriptor.
In order to provide these services transparently, an EJB container acts
as a proxy interposing itself between clients and bean instances.
According to EJB 2.1 specification [17], there are three types of EJB components:
Session bea
ns, Entity beans and Message
-
Driven beans. Session beans are non
-
persistent
components commonly used to represent business processes. These components are not
sharable meaning that at any moment in time, each session bean instance represents a single
clien
t executing inside the application server. Session beans are classified as statefull or
stateless, depending on if they retain or not information between consecutive requests. Entity
beans are sharable and persistent components used to represent business d
ata. Entity beans
may be classified
as CMPs or BMPs
according to who is responsible for persisting their state:
the container or the bean itself
, respectively
. Finally, message
-
driven beans are used to enable
J2EE application to process requests asynchrono
usly. They are implicitly invoked by sending
messages to a queue associated with it.
2.3
EJB in JBoss
In the JBoss’ architecture [05][07], a client application
(local or remote)
has access to an EJB
component through a client
-
side proxy which exposes the sam
e methods that are exposed by
the component itself. Each client
-
side proxy has a chain of interceptors. When a client
application invokes one of the proxy’s methods, this proxy collects information about the
invoked method in an object named
invocation
and
delivery this object to the first interceptor
in its chain. This interceptor gathers some information about the context in which this
invocation occurred (e.g. information about the user doing the request), adds this information
to the invocation object a
nd forwards this object to the next interceptor in the chain.
Its
last
intercep
tor is the invoker interceptor, which is in charge of forwarding the invocation object
that represents the request to a server side component known as invoker. If client and ser
ver
are running on the same virtual machine
the invocation object is simply passed by reference,
otherwise it is m
arshal
ed
and transferred
through the network to the server side.
At the server side, when an EJB component is deployed in JBoss application s
erver a
corresponding EJB container is created. This container is, then, associated with a server
-
side
component named invoker which role is to receive
invocations from invoker proxies
,
unmarshall
them if necessary
and forward them to corresponding contain
ers.
As any complaint EJB container, that offered by JBoss is responsible for managing the
bean instances and providing them with predefined services. However, instead of implementing
these services itself, a JBoss’ container has a chain of pluggable serv
er
-
side interceptors, each
responsible for implementing a specific service. When an EJB container receives an invocation
object, it forwards that invocation to the first interceptor in its chain. This interceptor uses the
information contained in the invo
cation object to realize the corresponding service and, then,
forwards the invocation to the next one down in the chain. Important interceptors usually
present in server’s chain are the security, the transaction and the instance interceptors. The
security
interceptor gets the information concerning the user that is invoking the bean and
checks for authorization. The transaction interceptor takes care of transactional properties,
including distribution aspects. The instance interceptor is responsible for obt
aining a bean
instance to be used in the request processing
(
Section
2.4
details JBoss’ instance pooling
mechanism
)
. Finally, the last interceptor in server’s chain is responsible for identifying the
method required, and invoki
ng it using the obtained instance. Method’s return transverse the
chain in reverse order until been received by the container which deliveries it back to the
invoker. The
invoker then marshals
the returned value
(if necessary)
and sends
it
back to the
invo
ker proxy. This invoker proxy unmarsha
l
ls
(again, if necessary)
the returned value and
forwards it through the client
-
side proxy’s chain in the reverse way. After that, returned value
is finally forwarded to the client application.
Figure
1
-
JBoss' EJB Architecture
During deployment time, client and server side interceptors can be selected and
configured through JBoss’ specific X
ML configuration files.
Figure
1
shows a client
-
side proxy
and an EJB conta
iner interacting in order to fulfil
l
user requests.
2.4
JBoss’ Instance Pooling Mechanism
An
important service that can be provided by an EJB container is Instance Pooling. When an
EJB container intercepts a client’ request it may create a new bean instance to
process this
request. Otherwise, if there is an already created instance in memory it may be better to reuse
it so reducing both memory and delay necessary to process the corresponding request.
Sometimes, an EJB container may also reduce allocated resourc
es by destroy bean instances
that have not been used for a long time. All this instance management is named Instance
Pooling. It is important to observe that the exactly mechanism used in instance pooling is not
part of EJB specification, so it is EJB cont
ainer specific.
In current section, we investigate
JBoss’ default implementation of this important mechanism and its configuration.
JBoss’ instance
pool
can be configured using an XML file. Configurable parameters
include maximum size, minimum size and op
eration mode. Maximum/minimum size is the
maximum/minimum number of instances that the pool can store (default values are 100 and 0,
respectively). By the time the first client’s request comes in, the instance pool creates and
initializes this minimum numb
er of instances configured.
JBoss’ pool can operate in two different modes: strict and non
-
strict. In non
-
strict
mode, instance pool can create any number of instances in order to process simultaneous
requests but it can keep and reuse only the configured
maximum size. In the strict mode,
instance pool can create only the configured maximum number of instances, no matter how
many simultaneous requests it receives.
Figure
2
-
JBoss' Pooling mechanism
When an
instance interceptor
(see section
2.3
) receives an incoming request, it must
require an available instance from the corresponding instance pool. If this pool has available
instances, it returns one of them, otherwise if the number of instances alre
ady created is less
than pool’s maximum size, the instance pool creates and returns a new one; else, pool’s
behaviour depends on its operation mode. If it is operating in non
-
strict mode, it creates and
returns a new instance to the requestor; otherwise, t
he incoming request must wait for an
instance to become available in the pool. Additionally, to define the maximum time that an
incoming request must wait
,
a timeout can be configured.
After obtaining an instance, the instance interceptor invokes the next
interceptor in the
container’s chain. Once it receives the completion, it forwards the used bean instance back to
the instance pool, which deletes any information associated to the previous request. If the
instance pool is not full, it can retain that ins
tance; otherwise, the instance will become eligible
by the garbage collection mechanism.
Figure
2
depicts the aforementioned interactions
between instance pool, instance interceptor and its previous and next interceptors in server
’s
chain.
3.
GSPN
Modelling Approach
This section presents
GSPN
model
s
for JBoss Application Server
. Th
e
s
e
model
s
focus
on
the
instance
pool
ing
mechanism
;
other implementation detail
s are not considered
.
Proposed
models represent a scenario comprising clie
nts realizing
HTTP
requests
that are
processed by
a
J2EE
application, which
is composed by a web module and a
Stateless Session Bean
both
run
ning
inside a JBoss Application Server.
T
he
first model
designed is
referred to as
bas
e model
. In this model,
it
is assumed
that
delays associated with
timed
transitions are
exponentially distributed
random variables
with
mean value obtained
directly
from measurement experiments
.
T
he second model proposed,
referred to
as
refined
model
, is derived from the base one
r
eplacing s
elected
timed transitions
with
s
-
transition
subnets
[
WatsonIII]
having
mean
delay time
and standard deviation
match
ing the measured
values
.
Both
model
s
ha
ve
the same
three main components: clients,
network and
JBoss
application server
.
It is
al
so
important to mention that both models depict
the instance pool operating in non
-
strict mode, so that the number of bean instances created is
not constrained.
3.1
GSPN
Base Model
Base model is depicted in
Figure
3
. In this model
, c
lients
are represented by
the subnet
comprising places
ClientsReady
and
SendingRequest,
transition
generateRequest
and its
incoming and out
going
arcs.
In its initial marking,
ClientsReady
has
nrClients
tokens, e
ach
one
corresponding to
an active
client,
which
generates requests through
generateRequest
’s
firings.
In order to model simultaneous clients,
generateReques
t
transition has
infinite
server
semantics
. Once a client generates a request
,
a
token is
put in
place
SendingRequest
representing that this
request is
now
be
ing
sent
over the
network.
generateRequest
’s delay
(
dRequest
)
can
be varied
in order to represent different request rates.
Figure
3
–
GSPN
Base Model
Network component is represented by a subnet comprising t
wo t
imed tran
sitions
,
sendRequest
and
sendResponse
.
Corresponding delay parameters
(
dSendRequest
and
dSendResponse
, respectively)
can be
approximated based on
the size of the information that
is exchanged between client and server.
JBoss
application
server
c
omponent
is
itself
modeled as a composition four distinct
components:
Previous
Interceptors, InstanceInterceptor, InstancePool
and
NextInterceptor.
T
hese components
share access to server’s CPUs, which are represented
by tokens in place
CPUs
. Before realizi
ng any time consuming task, a component must
allocate
an available CPU
. This allocation is realized in our model by those immediate
transitions whose names start with
sync
. After acquiring a CPU to realize a given task, a
server enters in one of its local
states represented by places whose names starts with
Waiting
and stay in this state until the corresponding task is finished
and
the allocated CPU is released.
The
PreviousInterceptors
component is
the one that receives incoming requests
for
processing an
d out
going
responses
for forwarding
.
Incoming
r
equests
ar
e represented by
tokens
in place
RequestsReceived
.
These
request
s
cross two chains of interceptors, one
contained by the
proxy and another
by
the server. In our model, however, all the work
realized
by the incoming interceptors (contained in both chains)
before
the instance one is
invoked
is
represented by
a single
transition
,
i
nvokeI
nChain
. In its turn, bean’s response also
crosses these chains, but in the reverse way. Again,
all
the
work realized b
y the interceptors
after the instance
one
returns is represented by a single timed transition,
outChain.
When this
transition fires, representing the conclusion of the interceptors’ tasks, a token is created in
place
SendingResponse
representing that the o
utgoing response is
now
ready to be forwarded
back to the client.
InvokerInterceptor
component is
responsible for obtaining a bean instance
to be
used in the
request processing
. It receives request
s
as
token
s
in place
InvocationReceived
.
To process the i
ncoming request, the
InstanceInterceptor
requests a bean instance from
InstancePool
component
.
InstancePool
component acts as a repository of bean instances
. After receiving a
request,
InstancePool
logs this fact in JBoss log file
,
what is represented by transition
log
.
A
fter logging requests,
Instance
Pool
checks
place
Pool that stores idle instances represented
by tokens. This checking is indicated by
the
place
CheckingPool
and transitions
poolIsEmp
ty
and
poolIsNotEmpty
. If Pool already contains an idle instance (i.e. #Pool > 0),
poolIsNotEmpty
transition fires and generates a token in
Waiting
Get
place. This token
enables
getPooled
transition that represents the activity of obtaining a pooled instanc
e.
Otherwise, if pool has not an idle instance available (i.e. #Pool =0), transition
poolIsEmpty
fires and a token is moved to place
Waiting
Create
, which it means that a new instance must
be created. In this model, instance creation is represented by
trans
ition
create
.
Each instance
created is counted putting a token in place
NrCreated
. In order to turn the Petri net
structurally limited, place
CreateLimit
and transition
T1
are also represented. Place
CreateLimit
is initialized to
nrClients
in order to guar
antee that, if necessary, each client can
create an instance in order to process its request, however it will usually reuse an instance
already created. Transition
T1
has a huge delay, so that it does not affect the instance creation
counter.
A bean instan
ce is returned to
InstanceInterceptor
in the form of a token deposited
in place
InstanceReceived
(
whether it has been created or obtained
)
.
After
obtaining an
available
instance
,
InstanceInterceptor
call
s
the
N
ex
t
I
nterceptor
component
. Activities realiz
ed by
all
t
he next interceptor
s
down in server’s chain
and by the
bean processing itself
are represented together as a unique timed transition:
invokeNext
.
When
this transition
fires
,
the used
bean
instance is
returned to the
I
nstance
I
nterceptor
a
s a
token
created in place
NextInterceptorFinished
.
F
inally, the
InstanceInterceptor
can
deliver
y
the used instance
to the
InstanceP
ool
.
When t
he
I
nstance
P
ool
receives a bean instance, it
clear
s
all the information
associated with the concluded request processing
.
This task is modeled by the timed transition
clear
. After that, pool will check its current and maximum size in order to decide if that
instance should be
discarded (become
eligible for garbage collection
)
or be
retained
for further
reuse.
This decision
is modeled by places
ReleasingBean
and
FreeSlots
, and transitions
dicard
and
goToPut.
After the bean been marked as eligible for
garbage
collection or stored
in pool’s slots, the response can cross the other interceptors in both chains (as already
explaine
d represented together by timed transition
outChain
) and be forwarded to the client.
Response forwarding is represented by the
sendResponse
transition.
Details concerning the immediate transitions used are presented in
Table
1
wh
ile those
concerning the timed ones are presented in
Table
2
.
Table
1
-
Immediate transitions in the
GSPN
base model
Table
2
-
Timed transitions in the GSPN base model
Transition
Delay Time in
μs
Firing Semantic
clear
15.4947
Infinite
-
Server
create
3504.8217
Infinite
-
Server
getPooled
1.9673
Infinite
-
Server
invokeInChain
0.5
Infinite
-
Server
invokeNext
24.8122
Infinite
-
Server
log
7.9756
Infinite
-
Server
outChain
0.5
Infinite
-
Server
put
1.9
766
Infinite
-
Server
sendRequest
21.0571
Infinite
-
Server
sendResponse
48.7518
Infinite
-
Server
Transition
Weight
Priority
Enabling Function
discard
1
1
-
poolIsEmpty
1
1
#Pool=0
po
olIsNotEmpty
1
1
#Pool>0
syncClear
1
1
-
syncGet
1
1
-
syncI
nvoke
InChain
1
1
-
syncInvokeNext
1
1
-
syncLog
1
1
-
syncOutChain
1
1
-
syncPut
1
1
-
3.2
GSPN
R
efined Model
As mentioned before, o
ne important assumption implied in our
GSPN
base model (see
Figure
3
) is that the
transi
tions’
delays are exponentially distributed random variables with parameter
equals to the mean of the measured delays obtained during model calibration.
However,
the
empirical delays
that were
obtained during calibrating
are
not exponential
in nature as ca
n be
seen by
the
mean and standard deviation
values
, which
are presented in
Error! Reference
source not found.
.
In e
xponential distributions,
mean
(
μ)
and standard
deviation
(
σ)
have
the
same value leading to a coefficient of variation with a unitary value.
In effect,
more
sophisticated strategies can be used to
evaluate the quality of
this
approximation
like Chi
-
square and Kolmogorov.
In general, a good way to deal with general distribution random variables (like those
associated with the delays measured
) is to
represent
these distributions using a combination of
exponential ones in a way that some moments of
the
general distribution match with
corresponding moments of the exponential composition
. These combinations of exponential
distributions are known
as
Phase Type distributions (PH distributions) [PH].
Algorithms that
do this kind of mapping from a general distribution to a PH distribution are called
moment
matching algorithms.
In fact, what
we have
already done a moment matching in our base
model when
we
approximate
d
an empirically distributed variable by an exponential one
promoting a matching between the first moment of both distributions
(i.e., its mean value
)
.
Better results, however, can be usually obtained using other algorithms that match other
moments besides the first one.
To refine the base model
we have
used a moment matching algorithm proposed by
Watson III in [20].
This algorithm takes advantage of the fact that Erlangian distributions
usually have
, while Hyperexpon
ential distributions generally have
,
to propose
the representation of an activity with a generally distributed delay as
an
Erlangian or
an
Hyperexponential subnet referred to as s
-
transition
. Therefore,
according with
the
co
efficien
t
of variation (
σ
/
μ
) associated
an
activity
’s delay, an appropriate s
-
transition implementation
model can be selected
. For each s
-
transition implementation
model
, there are parameters that
can be configured in such way that the first and second moments ass
ociated to the delay of the
original activity match with the first and second moments of s
-
transition as a whole.
Table
3
-
Mean (μ), Standard Deviation (σ) and Coefficient of Variation for
base
models timed activities
Transition
μ
(μs)
σ (μs)
Coefficient of Variation
s
-
Transition Type
clear
15.4947
21.8129
1.4078
H
yperexponential
getPooled
1.9673
0.9872
0.5018
Erlang
invoke
Next
24.8122
35.4980
1.4367
H
yperexponential
log
7.9756
43.6292
5.4703
H
yperexponential
put
1.9766
0
.4356
0.2204
Erlang
Table 4
-
Parameter values for s
-
transition implementation used in the refined
model
Transition
r1
r2
λ
clear
0,0302
0,9698
0,0006692729
create
0,2660
0,7340
0,0014214124
getPooled
0,1783
0,8217
0,0883707783
invoke
0,0951
0.9049
0,0000930938
log
0,0323
0,9677
0,0007797157
process
0,0059
0,9941
0,0003612167
put
0,0055
0,9945
0,0017597787
According to the aforementioned algorithm, transitions
clear
,
log
and
process
should
be approximated by hyperexponential s
-
transitions, sin
ce corresponding coefficients of
variation are greater than one (Table 3).
The hyperexponential implementation for an s
-
transition proposed by Watson III is presented in Figure 4. To approximate one of such timed
transitions having mean equals to
μ
and standard
-
deviation equals to
σ
, we configure
hyperexponetial’s parameters to
,
and
so that the first and second moments can match. The values for those three parameters
asso
ciated with
corresponding
timed transition
s
used in the refined model are presented in
Table 4.
Figure 4
-
A hyperexponential implementation for an s
-
transition
On the other hand, transitions
get
and
put
should be mapped to Erlang s
-
transitions
once the
ir coefficients of variation are lesser than one (
Error! Reference source not
found.
).The
Erlang implementation for an s
-
transition
Figure 5 depicts a Petri net that comprehends the core of the refined model. We call
this net the
control net
once it has c
omplete control of the dynamics of the system modelled,
i.e., it determines the sequence of fired transitions to process a request. It is worth observing
that all timed transitions present in our base model are carefully removed and represented in
the corr
esponding subnet (see Figure 6) connected to the control net using places and
transitions that serve as
connectors
. This modification allows us to easily substitute each timed
transition by the corresponding s
-
transition without significantly changing the
overall the model.
4
.
V
alidation
of the DSPN Models
Once current work is concerning with modelling and evaluating JBoss’ EJB pooling
mechanism and not with application architecture, we could build a benchmark application
composed by a stateless session bea
n and a some web components. Clients access this
application by sending simple HTTP requests that are processed by the web components.
Those components invoke a bean instance that returns a constant string to its invokers.
Information returned by the bean
is then placed in an HTML page that is sent back to the
clients.
Ten heavy demanding virtual clients simultaneously access the benchmark application
and each one tries to realize one hundred requests per second. Each experiment consists in
running those
clients 100 seconds. Virtual clients were simulated using JMeter 2.0.3, which is
a Java
-
based tool for load testing client
-
server applications.
Figure
5
-
DSPN Refined Model: Control Net
Tests were realized in an isolated Fast
-
Ethernet network containin
g just a client and a
server machine. Client machine is an Athlon 2000+ with 768MB of RAM running windows
2000 professional edition and is used only to simulate client requests. Server machine is a
Pentium M 1.6MHz with 768MB of RAM running JBoss applicati
on server version 3.2.6.
The java virtual machine used to run JBoss is Java HotSpot Client Virtual Machine (client
VM) version 1.5.0. JVM’s heap was configured with an initial size of 256Mb and a maximum
size of 512Mb. Additional applications and services
in each machine were stopped in order to
minimize external interference. Before starting each experiment, it was realized a warm
-
up
composed by one client executing 10000 requests in a row.
Figure 6
-
DSPN
Refined Model: S
-
Transitions Subnets
4.1
Perf
ormance Results and Analysis
To validate the designed models, we ran JBoss and deployed our benchmark application
setting it to use the default instance pool implementation configured to have a minimal size of 0
and maximum size of 100, operating in non
-
st
rict mode (which is its default configuration). We
submitted the described workload and logged the number of bean instances that were
necessary to process clients’ requests and the instant time that each one was created.
After that, we used TimeNET [21]
version 3.0.4 (for linux platform) to verify the
behaviour of the same metric (number of instances created) in the DSPN models. We applied
a similar workload to one used in the measurement experiment to both models (base and
refined) during 100 seconds. Du
ring these experiments, TimeNET’s transient simulation
function was set up with the following parameters: Number of sampling points = 100,
Confidence level=95% and Maximum relative error=10%.
Figure 7 shows the number of contexts created in both, measurem
ent (continuous line)
and base model’s simulation (dashed line). Figure 8 presents a similar comparison involving
measurement (continuous line) and refined model’s simulation (dashed line).
Figure 7
-
Context Creation Curve for Pooling Mechanism’s Base M
odel
Those results demonstrate that the DSPN refined model better approximates the
actual JBoss pooling mechanism when compared to the DSPN base model.
5. Conclusions
This paper has investigated the utilization of simulation models for performance predict
ion of
application servers. To do so, we designed a performance model that represents JBoss’
pooling mechanism using an approach based on Deterministic and Stochastic Petri Nets. It is
worth observing that the pooling mechanism has an important impact on a
pplication server’s
overall performance.
The simulation results obtained with the DSPN refined model approximate measures
results satisfactorily, validating both, the approach and the model itself. We consider this point
the main contribution of this work
.
Figure 8
-
Context Creation Curve for Pooling Mechanism's Refined Model
There are some open questions concerning the development of a complete
performance model. In particular, we are now staring the replication of this approach in the
identification
and modelling of other relevant services in the application servers. Additionally, it
is currently being developed a workload generator in Petri net in order to us to simulate a
variety of scenarios.
6. References
[01]
Abdul
-
Fatah, I., Majumdar, S., “Perfo
rmance of CORBA
-
Based Client
-
Server
Architectures”, IEEE Trans. Parallel and Distributed Systems, Vol.13, No.2, pg.111
-
126,
February 2002.
[02]
Cecchet, E., Marguerite, J., and Zwaenepoel W., “Performance and scalability of EJB
applications”. In Proc. 17th
Conference on Object
-
Oriented Programming, Systems,
Languages, and Applications, Seattle, WA, 2002.
[03]
CSIRO Middleware Technology Evaluation Series: Evaluating J2EE Application
Servers version 2.1, June 2002.
[04]
Eclipse Test & Performance Tools Platf
orm (TPTP) Project,
http://www.eclipse.org/tptp/index.html.
[05]
Fleury, M., Reverbel, F., “The JBoss Extensible Server”, Proc. International
Middleware Conference, 2003.
[06]
ISO/IEC/JTC1/SC21/WG7. Reference Model of Open Distributed Processing
–
Overview.I
SO10476
-
1, 07/1995.
[07]
JBoss Inc., JBoss Admin Development Guide, JBoss 3.2.6, 2004
[08]
Khorasani, M., “Middleware in Telecommunications”, Lucent Technologies
[09]
Kounev, S. and Buchmann, A., “Performance Modeling and Evaluation of Large
-
Scale J2EE App
lications”. In Proceedings of the 29th International Conference of the
Computer Measurement Group (CMG) on Resource Management and Performance
Evaluation of Enterprise Computing Systems (CMG
-
2003), Dallas, Texas, December 7
-
12,
2003.
[10]
Kounev, S., Weis, B. and Buchmann, A., “Performance Tuning and Optimization of
J2EE Applications on the JBoss Platform”. In Journal of Computer Resource Management,
Issue 113, Autumn 2004.
[11]
Liu, T., Behroozi, A., Kumaran, S., “A Performance Model
for a Business Process
Integration Middleware”, Proceedings of the IEEE International Conference on E
-
Commerce,
2003.
[12]
LLadó, C. M., Harrison, P. G.. “Performance Evaluation of an Enterprise JavaBeans
Server Implementation”. Proceedings on the second i
nternational workshop on software and
performance, September 17
-
20, 2000, Ottawa, Canada.
[13]
Llado, C. M., PhD Thesis: “Performance Evaluation of Enterprise JavaBeans
Architectures”, Department of Computing, Imperial College of Science, Technology and
Me
dicine. University of London. December, 2001
[14]
Marsan, M., Balbo, G., Conte, G., “A class of generalized stochastic Petri nets for the
performance evaluation of multiprocessor systems”, ACM Trans n actions on Computer
Systems, 2:93
--
122, 1984.
[15]
Mar
san, M., Chiola, G., “On Petri Nets with deterministic and exponentially
distributed firing times”, Lecture Notes in Computer Science 266, pages 132
-
145. Springer
-
Verlag, 1987.
[16]
OMG. Common Object Request Broker Architecture: Core Specification (CORBA
3.0), December 2002.
[17]
Sun Microsystems Inc. Enterprise JavaBeans™ Specification v2.1, November 2003
[18]
Sun Microsystems Inc. Java™ 2 Platform, Enterprise Edition (J2EETM)
Specification, v1.4, November 2003.
[19]
Verdickt, T., Dhoedt, B., Gielen, F., Demeester, P., “Model
ling the performance of
CORBA using Layered Queueing Networks”, Proc. of the IEEE 29th Euromicro Conference,
p. 117, 09/2003
[20]
Watson III, J., Desrochers, A., “Applying Generalized Stochastic Petri Nets to
Manufacturing Systems Containing Nonexponentia
l Transition Functions”, IEEE Transactions
on Systems, MAN, and Cybernetics, Vol. 21, No. 5, September/October, 1991.
[21]
Zimmermann, A., “TimeNET: A Software Tool for the Performability Evaluation with
Stochastic Petri Nets”, Performance Evaluation Group, TU Berlin, June 2001.
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Comments 0
Log in to post a comment