SEKE 2012 Proceedings - Knowledge Systems Institute

flexibility they provide to model systems with multithreaded
executions. In comparison, analytical approaches
such as Ma rkov models are difficult to express multithreaded
systems, at least because of the state-space
explosion problem, as each Petri net marking becomes a
single state in the Markov model. As Markov models can
be seen as a finite state machine, they are more suitable
for single-threaded systems.
The paper is organized as follows. Section II presents
a) the description of experiments, b) an analytical model,
and c) the Petri net model for HTTP request rejection rate
in JBoss. Section III focuses on experimental and
analytical results. Section IV offers some possible
directions to the future research and finally section V
contains some concluding remarks.
II.
DESCRIPTION OF EXPERIMENT
A. Experimental Environment
The experimental environment consists of two hosts
(client and server) remotely located from each other in a
LAN environment. The host server on which JBoss is
running is excluded from running other tasks to ensure the
consistency of data sets collected. The Duke’s Bank
application [18] is transformed into a web service and
deployed on JBoss. JBoss uses the Apache Tomcat as its
default web server. The client host generates service
requests to JBoss. The bandwidth of the LAN is shared
with other users not relevant to this experiment. Tools like
Wireshark [19] and Ping are used to measure the round
trip delay (RTD), excluding the time spent in the hosts. In
comparison to the time spent in the server, the RTD is
observed to be so negligible that it is ignored in the
experimental analyses. The system structure is illustrated
in Fig. 1.
WS client
SoapUI
SOAP- Http Request
SOAP- Http Response
Figure 1.
Client
The experimental setup.
JBoss AS
Banking
WS
Server
OS Windows 7 Windows Vista
Processor 1.67 GHz 2.66 GHz
RAM 1.00 GB 2.00 GB
Software SoapUI (3.6.1) JBoss AS (4.2.2)
SoapUI [20] is used to generate controlled service
request loads to the server. SoapUI is an open source
testing tool solution for service-oriented architectures.
With a graphical user interface, SoapUI is capable of
generating and mocking service requests in SOAP format.
There are two main parameters in SoapUI load testing
tool that can be set to control the workload of the
application server: number of threads representing the
virtual users, and the number of requests (runs) generated
per thread. For example, if the number of threads is set to
20 and number of runs per thread is set to 10, then there
are 20 clients, each sending 10 SOAP requests for a total
of 200 requests. SoapUI measures several performance
parameters such as the average response time, avg,
transactions per second, tps, and the number of
transaction requests failed in the process, which is denoted
as err. Avg is the average time difference between the
times a request is sent out until the response is received.
Tps, also called arrival rate, is th e average number of
requests generated by the clients per second.
The experiments have been conducted with sixteen
different load configurations. For each load test, SoapUI
returns the values for avg, tps, and err. Each test is
repeated 5 times and the average of the returned values
are calculated. The total time T for each load test
configuration is computed as follows:
where cnt is the total number of requests for each test.
Consequently, the error and success rates for each load are
computed by:
The error reports generated by SoapUI consist of all
types of potential errors that are generated by the network,
application server, and web service itself. However, this
study considers only the errors that are generated by JBoss
when the HTTP requests are rejected. Th erefore,
is treated as .
B. The Analytical Model
The actual rate of requests rejected can be obtained
from (2). This rate can be estimated in a different way.
Recall that avg is the average response time for one
request. Therefore, the service rate is 1/avg. In order for
JBoss not to reject any incoming request, it should be able
to use enough threads to keep up w ith the arrival rate.
Thus, JBoss will reject no requests if the following holds:
1
threads
avg
1
tps threads
avg
tps 0
Otherwise some requests will be rejected. Thus, number
of requests rejected per unit of time, i.e. ,
will be:
)
Consequently, the total number of requests rejected is:
(4)
306