Software Design

We are going to upgrade a software system that executes web sessions from users from the Internet. The system offers a betting service to the users on sport events. We have observed the running system during 5 complete days. During these days, we have seen that 648000 user sessions have been completed. Actually, we have seen that sessions arrived at a rate of 90 sessions per minute; and therefore, we can deduce that all sessions that arrived were completed. The system is composed of five service centers: A WebServer, a WinnerPaymentServer, a PlayerEngagement Server, a Database, and BettingServer. The description of the system and measured information is the following: Each user's session starts executing in the Web Server. There is only one resource for the Web Server, whose service time is 30ms in average. After the Web Server executes, the user session can follow two different paths, depending on whether the user is the winner of a previous bet or not. If the user is a winner of a previous bet, which happened 25% of times, the user executed in the WinnerPayment Server and credit is transferred to the user's account. The utilization of the WinnerPayment Server is 37,5%. After transferring the credit, the session continues in the PlayerEngagement Server, which offers new betting possibilities to the user in events that will happen in the next 30 minutes. If the user is not a winner of a previous bet, which happened 75% of times (because the user lost the previous bet or because the user did not bet the last time), the user session moves directly to the PlayerEngagementServer. This server checks all the possible bettable events in a championship that will be resolved in the next 30 minutes and generates lists with the events that are most likely to captivate the user to do a new bet. o A user session iterates, in average, 2 times its execution in this PlayerEngagement Server, server (because an average user is interested in 2 different championships). 2 Each iteration of this kind of bet recommendation" service needs a lot of CPU to discover the preferences of the user. The service time of a job in the PlayerEngagement Server are 400ms and it has 2 servers working in parallel. . Each iteration of the PlayerEngagement Server also needs to perform a request to the Database to retrieve the data about the existing bettable sport events in a concrete championship. We have observed that the demand (DK) of a user session in the Database are 120ms. After executing in the PlayerEngagement Server , the user may have been convinced to bet on one of the elements in the list, or he/she may leave the system (we have not been able to directly measure the frequency with which users take any of these two options). If the user has been convinced to bet, the session continues its execution in the Betting Server. The Betting Server executes the bet of the user in the system. There is a single resource for executing the Betting Server. We have not been able to directly observe the service time of the Betting Server. However, we could observe that there were, in average, 0.265 jobs in the Betting Server; that the average time between a job arrived to the Betting Server and its execution was completed (including the time it spent waiting for service in a queue) was 0.2525 seconds, and that the utilization of the server is You have to submit a PDF document with your answers to the following 3 exercises: A) Use the operational laws to calculate the service time Sk of the WinnerPayment Server, the Database, and the Betting Server; and to calculate the utilization of the Webserver. B) Model the System using Queueing Networks in JMT or in your preferred Queueing Network simulation engine). Add screenshots of: the structure of the network and about all the information you add to each component (service times, routing probabilities, etc.). Simulate the model to calculate the System Response time, the Utilization and Throughput of each of the four components in the system and show screenshots of the results. Hint1: In the cases that, from a service center (e.g., WebServer) a job can go to more than one service center, use Probabilistic Routing. 13 Hint2: Use the exponential distribution for all times and rates (frequencies) you need to model. Hint3: When a request iterates X times in a group of service centers, you can model it adding an additional loopback arc (see slide 4 in document 2DV608-Performance2.pdf), having the loopback arc probability (X-1)/X and the arc that leaves the service center probability 1/X. C) We are going to upgrade the functionality of the system in order to gain the attention of more users. The upgrade is the following: The PlayerEngagement Server will check more championships in which a user can bet and, therefore, it will iterate 4 times its execution in average (with its corresponding request to the Database in each iteration), instead of the previous 2 times. With this upgrade we expect that the number of users that are interested in our betting system system will double; that is, the system will receive 180 sessions per minute, instead of the previous 90 sessions per minute. Your intuition makes you think that these increments in the number of users and in number of iterations for each user could saturate the PlayerEngagementServer and the Database. Therefore, o Use the operational laws to calculate whether any of these two servers saturate. o If any of them saturate, use the operational laws to calculate the minimum number of parallel servers for the PlayerEngagementServer and the Database that will be necessary to avoid system saturation. o Update your previous Queueing Network model in part B)" with the new number of iterations, new number of users per minute, and new number of servers for the PlayerEngagement Server and the Database. Simulate the model to calculate the System Response time and add a screenshot of the result. We are going to upgrade a software system that executes web sessions from users from the Internet. The system offers a betting service to the users on sport events. We have observed the running system during 5 complete days. During these days, we have seen that 648000 user sessions have been completed. Actually, we have seen that sessions arrived at a rate of 90 sessions per minute; and therefore, we can deduce that all sessions that arrived were completed. The system is composed of five service centers: A WebServer, a WinnerPaymentServer, a PlayerEngagement Server, a Database, and BettingServer. The description of the system and measured information is the following: Each user's session starts executing in the Web Server. There is only one resource for the Web Server, whose service time is 30ms in average. After the Web Server executes, the user session can follow two different paths, depending on whether the user is the winner of a previous bet or not. If the user is a winner of a previous bet, which happened 25% of times, the user executed in the WinnerPayment Server and credit is transferred to the user's account. The utilization of the WinnerPayment Server is 37,5%. After transferring the credit, the session continues in the PlayerEngagement Server, which offers new betting possibilities to the user in events that will happen in the next 30 minutes. If the user is not a winner of a previous bet, which happened 75% of times (because the user lost the previous bet or because the user did not bet the last time), the user session moves directly to the PlayerEngagementServer. This server checks all the possible bettable events in a championship that will be resolved in the next 30 minutes and generates lists with the events that are most likely to captivate the user to do a new bet. o A user session iterates, in average, 2 times its execution in this PlayerEngagement Server, server (because an average user is interested in 2 different championships). 2 Each iteration of this kind of bet recommendation" service needs a lot of CPU to discover the preferences of the user. The service time of a job in the PlayerEngagement Server are 400ms and it has 2 servers working in parallel. . Each iteration of the PlayerEngagement Server also needs to perform a request to the Database to retrieve the data about the existing bettable sport events in a concrete championship. We have observed that the demand (DK) of a user session in the Database are 120ms. After executing in the PlayerEngagement Server , the user may have been convinced to bet on one of the elements in the list, or he/she may leave the system (we have not been able to directly measure the frequency with which users take any of these two options). If the user has been convinced to bet, the session continues its execution in the Betting Server. The Betting Server executes the bet of the user in the system. There is a single resource for executing the Betting Server. We have not been able to directly observe the service time of the Betting Server. However, we could observe that there were, in average, 0.265 jobs in the Betting Server; that the average time between a job arrived to the Betting Server and its execution was completed (including the time it spent waiting for service in a queue) was 0.2525 seconds, and that the utilization of the server is You have to submit a PDF document with your answers to the following 3 exercises: A) Use the operational laws to calculate the service time Sk of the WinnerPayment Server, the Database, and the Betting Server; and to calculate the utilization of the Webserver. B) Model the System using Queueing Networks in JMT or in your preferred Queueing Network simulation engine). Add screenshots of: the structure of the network and about all the information you add to each component (service times, routing probabilities, etc.). Simulate the model to calculate the System Response time, the Utilization and Throughput of each of the four components in the system and show screenshots of the results. Hint1: In the cases that, from a service center (e.g., WebServer) a job can go to more than one service center, use Probabilistic Routing. 13 Hint2: Use the exponential distribution for all times and rates (frequencies) you need to model. Hint3: When a request iterates X times in a group of service centers, you can model it adding an additional loopback arc (see slide 4 in document 2DV608-Performance2.pdf), having the loopback arc probability (X-1)/X and the arc that leaves the service center probability 1/X. C) We are going to upgrade the functionality of the system in order to gain the attention of more users. The upgrade is the following: The PlayerEngagement Server will check more championships in which a user can bet and, therefore, it will iterate 4 times its execution in average (with its corresponding request to the Database in each iteration), instead of the previous 2 times. With this upgrade we expect that the number of users that are interested in our betting system system will double; that is, the system will receive 180 sessions per minute, instead of the previous 90 sessions per minute. Your intuition makes you think that these increments in the number of users and in number of iterations for each user could saturate the PlayerEngagementServer and the Database. Therefore, o Use the operational laws to calculate whether any of these two servers saturate. o If any of them saturate, use the operational laws to calculate the minimum number of parallel servers for the PlayerEngagementServer and the Database that will be necessary to avoid system saturation. o Update your previous Queueing Network model in part B)" with the new number of iterations, new number of users per minute, and new number of servers for the PlayerEngagement Server and the Database. Simulate the model to calculate the System Response time and add a screenshot of the result