Performance Modeling of Non-homogeneous MultiServer Systems using MOSEL Gunter Bolch and Aymen I. Zreikat. Informatik 4, University of Erlangen, Germany
[email protected],
[email protected]
Abstract
server system with different service times. The most simple case is with one queue and different servers. This case is extended to more than one queue where each queue belongs to one or more servers. For the performance modeling of such sytem using MOSEL language, we need the number of queues and the number of servers in the system, the arrival rates to each queue and the service rate of each server. In addition, we need to know the strategy to assign a job to a specific server. Here we consider two strategies : FFS and random selection. The implementation is done by assuming that the system we describe is Reliable. So in this case, we don’t need to care about the failure and repair of the servers.
We introduce in this paper a Non-homogeneous multi-server system with Markovian arrival and service processes. First we consider the case with only one queue and different servers and the job assigns to one server. Then we extend this model to more than one queue in which the jobs are assigned to different queues. We assume that our system has different servers with different service times (Non-Homogeneous MultiServer System) and a job is assigned to a server using the strategies: FFS (fastest free server) or random selection. In our problem, we consider a general queuing system (M/M/n) with K is a finite number of jobs in the whole system. In which we have different queues with different jobs and the jobs are served by different number of servers. The performance modeling of this type of system is done by using the programming language MOSEL (MOdeling Specification and Evaluation Language), which contains several constructs to describe the system, the results (performance parameters) and the graphical representation.
2. The Model Description Language MOSEL The idea behind the design of MOSEL was to have a common and easy to use language for all available tools that allows the user (designer) to describe the system directly without any knowledge of the underlying methods or tools. To reach this goal, this common language for modeling systems has to fulfill the following requirements: MOSEL allows the modeling and performance evaluation also of complex systems in a very intuituve and simple way. The core of MOSEL consists of constructs to specify the possible states and state transitions of the underlying CTMC of the system under consideration. This specification is very compact and easy to understand. With additional constructs the interesting performance or reliability measures and also the graphical representation of them can be specified.
1. Introduction The determination of the performance characteristics, dependability, and availability is one the main issues when designing, analyzing, and tuning systems of any kind. There are a variety of modeling techniques for evaluating existing and even not yet existing systems using analytical and simulative methods. In addition, numerous software tools have been developed to support the different methods, each with its own language for describing the model to be evaluated. In this contribution, we consider a Non-homogeneous multi-
1
MOSEL fulfills all the requirements to be graded as an universal modelling language, since it is high level, system-oriented and general usable. It is open and integrating for many tools. By providing compilers, which translate descriptions specified in MOSEL into the tool-specific languages, all already implemented tools with their different methods and algorithms (including simulation) can be used. The language MOSEL consists of a series of constructs which can be summarized in five parts: • Parameter declaration part (optional). • System state definition part. • Transition definition part. • Results part (optional). • Picture part (optional). If the user has specified PICTURE constructs in his MOSEL description file and he has also started one or more tools (option -s), the MOSEL program generates an IGL file. IGL is an acronym for Intermediate Graphic Language, which can be interpreted by the IGL interpreter to show the results as graphs. The IGL interpreter, which is a part of MOSEL program package, is not only able to show the results by interpreting the IGL file, but also allows the graphical editing of such pictures to accommodate them to the needs of the user.
//q1s2ffs1_list.msl //=========================== //DEFINITIONS #define Q 10 //jobs in the queue #define n 2 // Nub.of servers #define mue 1.9 //Service rate #define
lambda 3 //Arrival rate
//HELP Variable HELP int K= Q + n;//jobs in system //NODES NODE p1[Q]; NODE m1[1]; NODE m2[1]; NODE num[K]; //RULES FROME TO FROM p1 FROM p1 FROM FROM
p1,num W lambda; TO m1; TO m2 IF (m1==1);
m1,num TOE m2,num TOE
W W
mue; mue;
//RESULTS RESULT>>Mean_q_length = MEAN p1; RESULT>> rho1 = UTIL m1; RESULT>> rho2 = UTIL m2; RESULT>> throughput = rho1*mue + rho2*mue;
3. Homogeneous Multi-Server System
//====PICTURE======================= PICTURE "Mean Queue Length" -TITLE "Mean_q_length,througput, rho1, rho2" -FONT Courier -FONTSIZE 22 LIST Mean_q_length,througput,rho1,rho2 LEGEND -NOVISIBLE //=================================
As an example, we consider a system with one queue and two identical servers and the two strategies: random and FFS. The graphical representation of this problem is shown in Figure 1.
3.2 Strategy 2: Random
mue
lambda
Following is the MOSEL description for this case. mue
//q1s2random.msl //================================ //DEFINITIONS #define Q 10,80,100,120 #define n 2 // The number of servers #define mue 1.9 #define lambda 3
Figure 1: One Queue 2 Servers
3.1 Strategy 1: FFS (Fastest Free Server)
//HELP Variable HELP int K = Q + n;
MOSEL Description
//NODES NODE NODE NODE NODE
This model could be described in MOSEL as it is shown in the following listing (q1s2ffs1 list.msl):
2
p1[Q]; m1[1]; m2[1]; num[K];
//RULES FROME IF
TO
p1, num
(m1 == 0)
FROM FROM
p1 p1
FROM FROM
p1 TO p1 TO
FROM FROM
m1, num m2, num
AND
TO TO
(m2 == 0)
m1 m2 m1 m2
//RULES FROME TO FROM p1 FROM p1
W lambda;
P P
0.5; 0.5;
FROM FROM
W W
m1,num TOE m2,num TOE
W W
mue1; mue2;
//RESULTS RESULT>>Mean_q_length = MEAN p1; RESULT>> rho1 = UTIL m1; RESULT>> rho2 = UTIL m2; RESULT>> througput = rho1*mue1 + rho2*mue2;
IF (m2 == 1); IF (m1 == 1); TOE TOE
p1,num W lambda; TO m1; TO m2 IF (m1==1);
mue; mue;
The result and the picture part are identical to the FFS case. Here we obtain the same results for the random and FFS case, since the service times of the both servers are the same. The above implementation was for Homogeneous systems; in which the servers have the same service rate. Next you will see how we can implement the above example, assuming that the servers have different service rates. We will see how the values of the different parameters are changing.
The picture part is again identical to the previous one.
The results If we start MOSEL with the following command: mosel -cs q1s2ffs1 list.msl, the following result file q1s2ffs1 list.res is provided by this run of the MOSEL program: ====================================== Results provided by the tool ‘SPNP’ ====================================== Constants: Q = 10 n = 2 mue1 = 1.1 mue2 = 1.9 lambda = 3 - - - - - - - - - - - - - - - - - - - Results: Mean_q_length = 4.42600589461 rho1 = 0.947610225044 rho2 = 0.903267761192 throughput = 2.75857999381 Help variables: K=12;
4. Non-homogeneous Multi-Server System Here again we use the one queue two servers example and can use the same MOSEL description. The only difference is that we have now two different service rates. As example, we consider the FFS case. In the random case we have corresponding changes.
4.1 Strategy 1: FFS (Fastest Free Server) Mosel Description
By looking to the above results, we notice for example how the values of rho1 and rho2 are different since we have a nonhomogeneous system and that it is heavily loaded.
//q1s2ffs1_list.msl //=========================== //DEFINITIONS #define Q 10 //jobs in the queue #define n 2 //Nob.of servers #define mue1 1.1 //Service rate 1 #define mue2 1.9 //Service rate 2 #define lambda 3 //Arrival rate
IGL (Intermediate Graphic Language) The IGL file q1s2ffs1 list.igl is also provided by the run of the MOSEL program and the graphical results are shown in Figure 2.
//HELP Variable HELP int K= Q + n; //jobs in the whole system //NODES NODE p1[Q]; NODE m1[1]; NODE m2[1]; NODE num[K];
3
5. Non-Homogeneous Multi-Queue Multi-Server System
Mean_queue_length, througput, rho1, rho2
5 4.5 4 3.5
lambda 1
3
mue 1
2.5 2 1.5
lambda 12
1
mue 2
0.5 0 .
Mean_q_length
througput
rho1
rho2
lambda 2
Figure 2: One Queue 2 Servers (FFS-Steady State Solution)
Figure 4: Three queues 2 servers Now, we consider the case where we have more than one queue and again non identical servers. The graphical representation of this problem with three queues and two servers is shown It is also possible in MOSEL to get the transient solution over in Figure 4. time by: First. We have to use a variable TIME in the PICTURE part of MOSEL Description the program. Second. We have to use additional parameters in the command This model could be described in MOSEL as it is shown in the following listing (q3s2ffs list.msl): line and start MOSEL with the following command: mosel -cst0.5,15,0.5 q1s2ffs1 list.msl. The meaning of the additional parameter t is that to show the //PROGRAM q3s2ffs_list.msl result over time starting from value 0.5 continue increase this //==================================== //DEFINITIONS value by 0.5 till you reach the last value which is in the above #define Q 3 // number of queues #define n 2 // number of servers command is 15. #define l 4 //MAX jobs in every queue The graphical results for the transient solution are shown in Figure 3. #define lambda# #
4.2 Transient Solution
#define
mue#
1.
//HELP Variables HELP int K =(Q*l)+n;
Mean_queue_length, Througput, rho’s....Over Time Legend Mean_q_length througput rho1 rho2
HELP int HELP int //NODES NODE NODE NODE
5 4.5 4 3.5
a# =(n - #+1) * (Q - #+1); b# =(n - #+1) * (Q - 3+1);
m#[1]; p#[l]; num[K];
3 2.5
//RULES FROME
2 1.5
TO
p#, num
W
lambda#;
1 0.5
FROM FROM
Time
0 0.5
1.5
3.0
4.5
6.0
7.5
9.0
10.5
12.0
13.5
15.0
FROM
p# p3
TO TO
m#, num
m# m# TOE
Figure 3: One Queue 2 Servers (FFS- Transient Solution) //RESULTS RESULT>>mean_noj = MEAN num;
4
PRIO PRIO W
a#; b#;
mue#;
- - - - - - - - - - - - - - - - - - - Results: mean_noj = 9.55960742257 thruput = 2.89476303997 util_m1 = 0.997504522664 util_m2 = 0.998837805495 Help variables: K=14; a1=6; a2=2; b1=2; b2=1;
RESULT>>throughput = util_m1*mue1 +util_m2*mue2; RESULT>>util_m# = UTIL m#; //=================PICTURE========== PICTURE "Mean Queue Length" -TITLE "Mean_noj in the whole system, throughput,utilization" -FONT Courier -FONTSIZE 22 LIST mean_noj,thruput,util_m1,util_m2 LEGEND -NOVISIBLE //==================================
Please note that the priorities in the program above are given by an expression and this expression is a function that makes a relationship between the queues and the servers priorities. It multiplies the priority of each queue with the priority of each In this description, a typical and very helpful MOSEL construct server and produce the result which is the priority of the arrow is used; the so called shortcut. The numbersign # in a line is going from the queue to server. You will see this relation clearly replaced by the numbers in front of the line. For example, if you look to the program code. < 1..3 > NODE m#[1]; is identical to: Actually, we can guess about the behavior of this system before we look to the results. So we expect that in this type of system: NODE m1[1]; The Mean Number of Jobs is increased dramatically . NODE m2[1]; Mean Queue Length is also increased and we expect that the NODE m3[1]; two servers will be utilized all the time and heavily loaded. This will be clear if you have a look to the graphical representation IGL (Intermediate Graphic Language) generated by IGL in Figure 5. The graphical representation of the results by IGL is shown in Figure 5 and the numerical representation in the following table.
6. Conclusion It is shown in this paper how MOSEL (MOdeling Specification and Evaluation Language) can be used to implement Homogeneous and Non-homogeneous systems very smoothly. We assumed that our system is Reliable; in which there is no possibility for the server to fail at some point of time. But it is easy to show how also the Unreliable systems can be solved using MOSEL with the additional parameters : mtbf (Mean Time Between Failures) and mttr (Mean Time To Repair) which describe the failure and repair behaviour of the system.
Mean_noj in the whole system,Throuput, Util
10 9 8 7 6 5 4 3 2 1
References
0 .
mean_noj
thruput
util_m1
util_m2
[BGMT98] G. Bolch, S. Greiner, H. de Meer, and K. S. Trivedi. Queuing Networks and Markov Chains, John Wiley & Sons, New York, 1998, 716 pages.
Figure 5: Three Queues 2 Servers (FFS-Steady Solution)
[BBH2000] K. Begain, G. Bolch, H. Herold. Practical Performance Modeling - Application of the MOSEL language, Kluwer Academic Publishers, Boston, 2000, 408 pages.
======================================== Results provided by the tool ‘SPNP’ ======================================== Constants: Q = 3 n = 2 l = 4 lambda1 = 1 lambda2 = 2 lambda3 = 3 mue1 = 1.4 mue2 = 1.5
5
