Server: Discrete Event-Driven Simulations

Transcription

1 Professor Wittie CSCI 204 Introduction to Computer Science II Fall Objectives Use a Queue ADT Use an enum Use inheritance Design and execute a test plan Use version control Use Javadoc Write documentation Revise your work Comment your code Server: Discrete Event-Driven Simulations 2 Background Systems such as banks or webservers provide services to clients. The efficiency of a row of bank tellers or a set of processors for a webserver can be measured by how long the client had to wait before service began. These systems can be simulated to give us efficiency data so that the bank or webserver maintainers can improve the service if necessary. 3 Assignment Write a program to simulate the behavior of a web server with a waiting queue. The simulation here is a Discrete Event Driven Simulation. The simulation is based on events happening in the system over time. The waiting queue holds requests which have come in and have to wait for the server when it is too busy. 4 The Web Server The web server to simulate is called All-In-One-Server, or AIOS, which provides web service, ftp service, and service over the Internet. The AIOS waits for requests for service over the Internet. When a service request arrives, it can be one of three types, WEB, FTP, or . Each type of request uses a different amount of work-time (the time spent running in the server). A WEB service takes a random amount of time between 3 to 5 minutes to complete; an FTP service takes a random amount of time between 5 to 10 minutes to complete; while an service takes a random amount of time between 4 to 7 minutes to complete. The time between the start of requests is called the inter-arrival time. The inter-arrival times between the WEB, FTP and traffic are random values of 0 to 10 minutes. The FTP and do not generate other consecutive requests when they finish service. The WEB service, however, will generate a new WEB service request with a probability of 30%, a new FTP service request with a probability of 20%, and a new service request with a probability of 15%. Note that a second-round WEB service will not generate any further requests. You will need to make these two types of WEB events as different ones. The first type may generate further service request, let s call it WEB. The second type doesn t, let s call it WEB2. 1

2 The AIOS server can only service one request at a time. If the server is servicing a request while another request arrives, the newly arrived request has to be put into a waiting queue. When finishing serving a request, if any requests are waiting in the queue to be serviced, the web server takes the first one off the queue and continues to serve the requests. If the waiting queue is empty, the web server will be set idle. 4.1 Discrete Event Driven Simulation Discrete event driven simulation is based on the sequence of events that take place in the system. The basic idea is that the simulation maintains an event list that keeps the events in the order of their event time, the time the event is supposed to take place. The simulation proceeds by taking the event off the event list in order and processing it. When processing an event, a new event might be generated and inserted into the event list, depending on the type of the event being processed. The event list is typically implemented as a priority queue where the nodes in the list in the queue are ordered by event time. A simulation program can be initialized in different ways. In this project, we take the approach we discussed in the class. A sequence of initial events are first generated and placed in the event list. This sequence of events may include three types of events, WEB, FTP and . What you can do is first generate a sequence of initial WEB events, then a sequence of initial FTP events, followed by a sequence of events. Once these initial events are generated, the simulation starts the processing of these events until the simulation time is exhausted. While processing events, new events may be generated. The new events could be more of the request, e.g. a WEB-COMPLETE event may generate more FTP request; or the new events could be of the type completing a request, e.g. WEB-COMPLETE, FTP-COMPLETE, and -COMPLETE. If the current event is WEB2-COMPLETE, FTP- COMPLETE or -COMPLETE, no new events will be generated. The main simulation loop will look (approximately) as follows. generate 5,000 initial events (requests) and insert these events into the event list; while (the event list is not empty) { retrieve the first event from the event list; set the simulation time to be the event time; remove the first event from the event list; switch event type case WEB : processwebevent; case WEB2: processweb2event; case FTP : processftpevent; case process event; case WEB_CMPL: processwebcomplete; case WEB2_CMPL: processweb2complete; case FTP_CMPL: processftpcomplete; case _CMPL: process complete; end switch end while } 2

3 When processing a new request event, the program checks to see if the server is busy. If the server is not busy, the newly arrived request will receive service right away. Schedule a completion event for this request on the event queue to happen when this event will actually finish. Note when inserting the completing event into the event list, there could be many requesting events that are already scheduled to take place on this list. So the newly generated departure event would have to find a proper place to insert in the event list so that the list is ordered strictly by the time of event happening. If a completing event and a requesting event are scheduled to take place at the same time (e.g. both a WEB-COMPLETE event and an FTP request event take place at time 55), put the completing event before the requesting event. When processing a completing event, the simulation does several things. First, it calculates the time this event spent in the waiting queue. (You know initial request time and current time. A little math gives you the waiting time). Any other packet statistics you need can also be calculated now. Second, it finds the current length of the waiting queue. Third, the program then checks if any requests are in the waiting queue. If any, the front event should be removed from the waiting queue, receive service, and the simulation should schedule an event accordingly. The code to run your simulation must be in a class named WebServer. Your main method may not contain more than the following public static void main(string[] args) { WebServer s = new WebServer(); s.generateevents(); s.runserver(); s.printstats(); } You do not have to name your methods as I show here. Your WebServer constructor may generate the events if you want. You may not begin running the server in your constructor. 4.2 The Event Class As seen from previous description, there are a number of types of events in this simulation. These events have some common features. They all have event time. They have some differences as well, for example, the event type is different. Requesting events have a service time length while the completing events don t. You must create a class named Event. Then a number of different events will inherit this parent class: RequestEvent, and CompleteEvent. Within the two child classes, you must use an enum to represent different types of requests and completions. The enum can be in its own class. Why? Your event and waiting queues must be full of one type of Object...an Event Object will do the trick. By using an enum to tell WEB, FTP, etc.. events apart, you can use a switch statement. This gives you practice using inheritance, enums, and switch statements. 4.3 The EventQueue Class The whole simulation is based on the event behaviors. The event queue is a central piece of any event-driven simulation. An event queue is a priority queue sorted according to the event start times. It holds all the events that will occur as time passes. Both RequestEvents and CompleteEvents will go on this queue. You should implement the event queue as an efficient data type which has all the behaviors needed, no excess behaviors, and is fast. Explain and defend your choice in your technical specification. You must provide a Big-O analysis of the run time for all queue methods. You must write this class yourself and cannot use one of the Queue classes in the Java libraries. You must name this class EventQueue. Why? This proves you understand the queue ADT well enough to make your own. You may use code from 204 labs and lectures and readings. 4.4 The WaitingQueue Class The waiting queue holds events which have entered the system (their start time has happened) and are waiting to run. This queue behaves like a standard FIFO queue. Only RequestEvents go on this queue. 3

4 You may use code from class, lab, the readings, or the Java libraries for this class or you may write it yourself. Explain and defend your choices in your technical specification. You must provide a Big-O analysis of the run time for all queue methods. Be aware that you d better be able to say why the Java library implementation is fast if you go that route. If you write the class yourself, you must name it WaitingQueue. If you use a class provided by Java, this is not necessary. 4.5 Testing This project has many parts which must all work together. 1. You must develop a testplan for both queue classes to make certain all of the functions work correctly. If your WaitingQueue is provided by Java, the Java API documentation will suffice. See the main method of the List, Stack, and Queue labs for an example (Warning: I do not promise these are tests of the full class. However, they do test the newly added features). 2. You must develop a testplan for the initial request creation generated by WEB events. This plan must show that the correct number of initial tests is actually generated and that WEB, FTP, and s each make up a third of those requests. You should also check on the inter-arrival times and the length of each request type. (Min, max, and average of each of these should give you sufficient information.) 3. You must develop a testplan for the secondary requests generated by completed WEB events. For the secondary requests, you must test that a reasonable number of secondary requests are produced and that the number of each type matches the percentages given above. 4. You must develop a testplan to show that the overall running of the server goes as plans. This might be simplest to show by printing the queue contents repeatedly as the server runs on a very small number of requests. 5. Lastly, you must have a testplan to make sure the simulator is indeed run on 5000 events plus an extra secondary events. Carefully explain all testplans and show the actual results. See the CSCI 203 testplan guide for help. Remember that a good test plan could be carried out by a third party who is not looking at your code. They check off the items in your test plan one by one to make sure the project works. Here are good and bad examples of items in a test plan: 1. bad: useless Test that the event queue works. 2. bad: inspecific Stuff gets added to the event queue. 3. good items added to the event queue appear in sorted order by the arrival time. For normal events, this is the start time. For completion events, this is the completion time. Example: Event Queue Type WEBC FTP WEB FTP WEB FTP Time Length Note that the items are all sorted by time. 4. good Items come off the front (left) end of the event queue. Example: before Event Queue and after Event Queue Type WEBC FTP WEB FTP WEB FTP Time Length Type WEBC FTP WEB FTP WEB FTP Time Length

5 4.6 Running the Simulator You will run your simulator on 5000 requests. (And the WEB requests may generate additional requests). To see the efficiency of the server on the 5000 requests, print out the average waiting time (average time a request spent in the waiting queue) and the minimum and maximum waiting times (the shortest and longest waits had). You must have the option to print out the contents of the queues each round and the option not to. This can be as simple as a parameter to the WebServer constructor. The easier this is on the user, the better the design. You will need to print out information on how many of each event was initially generated and how many were finally processed. This information could be printed in a small table at the end. You should also print out the initial size of the EventQueue and the overall number of events generated. This information could also be printed in the above mentioned table. When necessary, test runs should show both queues printing repeatedly as they run. To save sanity, it is perfectly reasonable to do the test for the EventQueue (items 1 and 2) with only a few events (perhaps 5-10). You can seperatly show that the EventQueue indeed filled with 5000 initial events by printing its size but not the actual queue. This is why your webserver needs noisy and quiet modes. 4.7 Simulator Example Here is an example of the simulator in action. Your event queue and waiting queue begin empty. Your simulation first generates a bunch of random events into the event queue. I ve shown all data for each event so you can track them. The Time is the time the request occurs. For a request event, this is the time the request comes in. For a complete event, this is the time the completion happens. The Length is the length of time the request will spend running in the server. Events which have just moved or changed are shown in boldface. Event Queue Waiting Queue Server: free Time: 0 Type Web FTP WEB FTP WEB FTP Time Length Type Time Length When the system begins to run, we serve the first event in the Event Queue. It will complete at current time + work time (2+4=6). Type WebC FTP WEB FTP WEB FTP Event Queue Time Length Waiting Queue Type Time Length Server: Event Web, time 2, length 4 Time: 2 Next time flies and we get the WEBC event. Lets say it generates a new WEB event occurring at time 9 with length 6. Type WEB2 FTP WEB FTP WEB FTP Event Queue Time Length

6 Waiting Queue Server: free Time: 6 Type Time Length Then we get the event. The current time is 6 so it will end at 10. Type WEB2 FTP C WEB FTP WEB FTP Event Queue Time Length Waiting Queue Type Time Length Server: Event , time 6, length 4 Time: 6 Then we get the WEB2 event but the server is currently busy and it must go on the waiting queue. Type FTP C WEB FTP WEB FTP Event Queue Time Length Type Web2 Waiting Queue Time 9 Length 6 Server: Event , time 6, length 4 Time: 9 Then the FTP event and the server is still busy. Type C WEB FTP WEB FTP Event Queue Time Length Type Web2 FTP Waiting Queue Time 9 9 Length 6 8 Server: Event , time 6, length 4 Time: 9 Then we get the C event and the server becomes free. It s time 10. This event was suposed to occur at 6 and take 4 minutes. How long did it have to wait? We immediately let the first waiting event get served and the server becomes busy again. Type WEB WEB2C FTP WEB FTP Event Queue Time Length Type FTP Waiting Queue Time 9 Length 8 Server: Event WEB2, time 9, length 6 6

7 Time: 10 The simulation continues on from here. It will end when all queues are empty and the server is free. 5 What To Hand In You will need to produce Javadoc for this assignment. As always you need appropriate comments. You must use Eclipse and Subversion for this project. 5.1 Phase 0 - The day it is assigned For this project, you will work alone. Why? To show me that what you learned this term. Your project should go in your labs folder on the Subversion server. 5.2 Phase 1 Due Project Description CRC and UML Technical specification in Javadoc Testplans Do not wait for my input before beginning the next phase. 5.3 Phase 2 Due The WebServer, Event and EventQueue classes as well as all the children of the Event and the enum for event types. All things must be appropriately commented using Javadoc comments and internal comments. I plan to grade the Event, Event kids, enum, and EventQueue classes now and not have to look at them again. All EventQueue methods must have a Big-O analysis in their Javadoc comment. Copy testruns into a file. These test runs must match your test plan for the EventQueue (item 1) and for filling the EventQueue (item 2) with the initial 5000 items. I expect that your EventQueue can fill with appropriate events and your test runs show that the original event generation and event queue usage are all working. The WebServer must fill the EventQueue with events but processing can be limited to simply removing the events one by one. Your code should follow the Style Guide posted on the CSCI 204 web site Do not wait for my input before beginning the next phase. 7

8 5.4 Phase 3 Your code should follow the Style Guide posted on the CSCI 204 web site Due User manual Technical specification in Javadoc Testplans Completed code. This includes comments and Big-O analysis. Copy testruns into a file. These test runs must match your entire test plan and include all items in the testing section above. (Note: item 1 must be done for both the EventQueue and the WaitingQueue). Clearly seperate each test case from the next one. Also include the output mentioned in the section on running the simulator. 8