Using Stochastic Petri Nets for Performance Modelling of JBoss Application Server

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.