Simulation Analysis of a Web Application Solution



Simulation Program Functional Demo: .

  • Submit all your main code and scripts, and input files if any.

  • Code should be well-commented

  • Code should produce a clean, somewhat readable trace.

  • In your demo you will have to point out (reason-through) a few examples (from trace output) of why you think the code is correct

  • You need not show metrics calculation at this point.

Final Submission (Code, Analysis in slides format) due:Sunday, April 28th, 2018,



  • Submit a file called assmt2_final_name1_name2.tar. Tarball should have:

    • All code (please delete junk files), scripts, all input files used.

    • Slides which show the graphs, observations and conclusions

Assignment is to be done by TWO team members.

Overall Goal of the Assignment

In this assignment you will continue the study of the performance of a Web Application, this time through a discrete event simulation model. You will take advantage of the power of simulation analysis and model behaviours that are difficult to capture using theoretical queuing systems and Markov chain models. You will write a program, and then run it to ask various interesting questions. For all metrics you will perform proper statistical soundness analysis.

Detailed Specifications

Write a simulation program in any general purpose simulation language (except C. It is not a good habit in today’s times to program in C – please use every opportunity to program in object oriented languages. C++, Java or python is fine.)

System Characteristics

Your system should have the characteristics of the Web server environment that you measured.

The following is recommended, you can add/modify.

  • Multi-core server machine

    • Assume thread-to-core affinity. Once a thread is “assigned” to a core, it will remain there

  • Multi-threaded Web server

  • Thread-per task model – until max is reached, after which queuing for threads starts.

  • Round-robin scheduling, with context-switching overhead

  • Request time-outs

  • Users are in a standard closed loop – issue request, wait for response, think then issue request again.

    • Think time should have a mode not close to zero – don’t assume exponential think time

  • Have options of various request execution time distributions, such as – constant, uniform, exponential.

  • Request timeout should also have a well-chosen distribution

    • Have some sort of a minimum, and then a variable component

Performance Metrics

Metrics/graphs will be similar to what you measured for assignment

  • Average Response Time vs number of users

    • Generate confidence intervals for this metric. Point estimates (averages of estimates from independent runs) are ok for the remaining metrics

  • Throughput, Goodput, Badput vs Number of users

    • Badput = rate of completion of requests which were already timed out.

    • Goodput = rate of completion of requests that were not timed out

    • Throughput = goodput + badput

  • Request Drop rate vs number of users

  • Average core utilization vs Number of users

  • Some additional graphs representing your own curiosity regarding system performance vs some system parameter

Ensure that the transient is determined and discarded in each of your simulation runs. You can do this informally, or follow Welch’s procedure. .

Self-Proposed DES Project

  • Sunday March Draft Proposal submission

  • Tuesday March Proposal finalization after feedback/discussion

  • March in class: design plan

  • Simulation Program Functional Demo:

  • Final submission: Sunday,

  • Project Presentations


error: Content is protected !!