Queuing Systems Simulation Tool Seyed Hamid Hamraz
[email protected]
Introduction In this manuscript, I am trying to present an overview of the tool I developed for simulating queuing systems. I won’t describe detailed issues; you can read the source code for very detailed implementations. I first describe how to use the tool for simulating queuing networks, and then present a simple framework of the program. I will describe how the program can be extended for simulating any kind of queuing system. I have also added some comments to the code and the javadocs is also available in the project main directory. The reader is required to have simple background information on Queuing Systems and Discrete-Event Simulation Systems (DESS).
Simulating a Queuing Network In this part, I describe how to use the program for simulating simple queuing networks. The topology and properties of the network is described in a simple format. For the first step, just run the program with the main method in the QNetFrame class. The appeared frame is simple and interactive. The top white editor is for describing the network and the blue one will depict the output of the simulation. You can press F5 for starting the simulation. Queuing Network Description There are three parts for describing the net. Each part starts with a header and finishes with an “End”. The header and the “End” should reside in separate lines and there should not be any blank line between the header and the “End” statement. The first header should be “Queues”; under this header and the first “End” the queue nodes of the net are described- each node in one line. Note the example: Queues first second
25 20
2 1
E E
1.5 E 1
2
End This block describes two nodes for the network. Each node is described in a separate line, and it has only one internal queue and at least one server. The second line above describes a node named “first”. The maximum length of the queue is set to 25. The “2” after the “25” designates number of servers. Each server is demonstrated by two tokens. The first one should be “E”, i.e. exponential distribution. The only supported distribution by now is exponential. Adding new statistical distributions is straight forward due to simple and extendible design and structure of the program. The second token, that is the number after the “E”, represents mean service time of the server. Therefore, the node “first” has two servers with mean service time of 1.5 and 2 respectively. Note that the order of servers is important; the client will check to find the first free server in the same order as the description text. The header of the second part is “Arrivals”. In this part the clients arrival gates to the net are described- each of which in one separated line. For example: Arrivals first End
E
1.2 100000
The block describes one arrival gate to the network. The second line shows that clients will enter the node “first” in the network in exponential rate, and the mean duration between two adjacent arrivals is 1.2. The last number is the total number of clients who shall enter via the gate throughout the simulation. If there are more than one arrival gates, the simulation proceeds until at least one gate is satisfied. The third section header is “Edges”- place for describing the network interconnections. Each line describes all the output branches of one node to others. Example: Edges first second End
second first
0.9 first 0.1 0.05
The second line describes two outputs from the node “first” to “second” and “first” with the probabilities 0.9 and 0.1 respectively. The clients going out of “second” may enter “first” with the probability of 0.05 as described in the third line above. The network described throughout the examples is depicted below.
This network can be found in the main directory of the project, in the file named “qnet.txt”.
Queuing Network Simulation Results After the simulation, results will be shown for each node of the network in the blue area. Everything is rather clear. Mean service time is the mean of all the contributing servers in the node. Disappointed to enter designates the percentage of clients that have left the network because of no place in the queue of the node. Efficiency and work percentage of each server is also offered. Note that the sum of all the servers’ works plus disappointed clients should be 100%.
Program Structure In this section the main parts of the simulation package is described. A simple UML is demonstrated below.
The backbone of the simulation program is the classes in black. The Event class provides a simple structure for representing an event in the DESS. EventList provides a structure for listing the events and retrieving the closest-to-happen one. Note that each event points to a SimulationSystem in which the event will take place. QueuingSystem is a sub-class of the SimulationSystem, and it contains an array of internal queues and an array of servers and provides methods for handling two kinds of events in a queuing system, i.e. entering and exiting. The heart of execution is in Simulator class. See the simulate() method in the class, below.
1 2 3 4 5 6 7 8 9 10
public void simulate() { initializeEventList(); while(!isEnough()) { Event e = fel.getNextEvent(); time = e.time; Collection newEvents = e.realize(); fel.add(newEvents); generateEvent(); } }
In iteration of the loop the closest-to-happen event is retrieved from the future event list at first step (line 4). The time of the simulation is updated. The event is then realized and consequent events are added to the future event list (lines 6, 7). The last line of the loop provides opportunity for generating the arrival events dynamically. Note that, the loop will not be terminated until isEnough() method returns true. isEnough() and generateEvent() are both abstract and should be implemented in the subclasses. The combination of the two methods provides the facility to progress and stop the simulation in any manner the programmer decides. For implementing a new queuing DES scenario it is enough to create subclasses of Simulator and QueuingSystem classes and implement the abstract methods as intended and then collect any required statistical data. The current package has done this job for implementing queuing nets (the green part in the UML). Each node in the nets has a single internal queue and an array of servers. The nodes are connected to each other based on probabilities. Each object of QueueNode class holds an array of other nodes to which the node is connected. After each exit event in the node an enter event to one of the connected nodes may be generated based upon the probabilities. Thus, there is not an explicit structure for representing the network; instead the network is simulated in a distributed manner in the shape of an array of QueueNode objects. Although the implemented tool for queuing networks can be used to simulate a wide range of queuing systems, there still exists some kind of special-purpose queuing system that can not be handled e.g. a queuing system with more than one internal queue, a network in which there is some other special-case interconnections between the nodes, etc. The program
framework (the black part of the UML) is still useful and straight forward to implement any shape of queuing systems, as described above; that is implementing sub-classes for Simulator and QueuingSystem classes.
