In the first part of the project, you will create a web application that allows users to check the state of the past flights. Data are retrieved from the bureau of transport of USA.
Each flight must be described by the following fields:
- TRANSACTION ID: id of the transaction
- YEAR: year the flight took place
- DAY_OF_WEEK: 1..7, 1=Sunday
- FLIGHT_DATE: yyyymmaa
- OP_CARRIER_FL_NUM: flight number
- OP_CARRIER_AIRLINE_ID: unique id of the carrier line
- ORIGIN_AIRPORT_ID: unique id of the origin airport
- ORIGIN: origin airport name
- ORIGIN_CITY_NAME: origin city
- ORIGIN_STATE_NM: origin state
- DEST_AIRPORT_ID: unique id of the destination airport
- DEST: destination airport name
- DEST_CITY_NAME: destination city,
- DEST_STATE_NM: destination state
- DEP_TIME: local departure time
- DEP_DELAY: departure delay
- ARR_TIME: arrival time
- ARR_DELAY: arrival delay
- CANCELLED: 1=Yes, 0=No
- AIR_TIME: length of the flight
The web app must work as a micro service providing a RESTful implementation based on HTTP and JSON.
The following queries must be implemented:
- Given flight date and flight number, return the delay of departure and landing.
- Given a date interval and a minimum delay D, return the description of the flights (id, data, source city, destination city) with a delay of at least D minutes within the time interval specified.
- Given a time interval and a positive integer n, return the n airports which had the highest percentage of delayed departures (delayed departures/total departures).
If you are building your applications as a monolithic software running on a single PC, you may identify for sure the CPU and the disk with will be used both by your front end (the web server) and your backend (database of backend application). If your application is more intriguing and has more disks or run on more than one machine, spot the key-components accordingly.
Set up a closed-loop benchmarking test with a single customer. For each type of query required by the previous assignment, identify the resource demand (relative visit ratio and service time).
How do you do it? Since you have a single request, you assume that the expected response time measured by Tsung is the expected service time. The relative visit ratio, e.g., at the disk, may be derived by counting the disk accesses during the experiment and divide them by the number of requests.
Pay attention that no other demanding application is running on your system during this benchmarking! top command allows you to monitor system utilization and at https://www.opsdash.com/blog/disk-monitoring-linux.html you may find some tool descriptions.
In this part, you will study the response time and the throughput of the system as function of the number of users. Model the system as an interactive system and compare the measurements obtained with Tsung and the solution of the queueing network model obtained with JMT. You may choose only two types of requests and consider them in isolation.
Use operational analysis to determine the bottleneck od the system and the optimal number of users assuming that all the queries are the same (i.e., single class model) for each query type.
Modify the model to increase the number of parallel customers that it can serve. Motivate your choices and show the optimal number of users obtained thanks to the operational analysis before and after your modifications.
Change your model to a multi-chain one, in which each chain corresponds to one query type. Queries with similar demands can be merged together to form one chain. Use JMT to study a mixture traffic, i.e., given a certain configuration find the saturation point for different percentage of jobs in the chains.