Load Profiling a Web Server or Web Application

To get a profile of how a web application performs under various loads, we want to incrementally increase the arrival rate until we get to a point where the server is effectively at 100% utilization, and requests are starting to be queued. This point is where the request arrival rate is just greater than the request departure rate (or throughput). When we reach this point, we can calculate the number of resource in the system that can concurrently process requests. In theory a 2 cpu server would equate to 2 resource handlers, but I/O bottlenecks and other blocking will reduce this.

Start by unpacking the JStress distribution archive, and opening a prompt in the jstress/example directory.

If you have an URL you want to test, put it in a file called service_urls.lst. Please use an url to your own server.

Next we need to set the start and stop rates for the profile. Change the values of the following properties in the jstress.properties file, which assumes that your server average response time is somewhere between 100ms and 10ms.

jstress.LinearStepRun.IntervalStart=100
jstress.LinearStepRun.IntervalEnd=10

  ../bin/jstress jstress.load.LoadURLTask LinearStepRun

If you don't have an URL to test, from the command line (without making any changes to jstress.properties), execute:

  ../bin/jstress jstress.load.LoadIndependentTask LinearStepRun

On the screen you will see various metrics printed out, these same values are also being stored in the log/jstress.log file for use with R, gnuplot, or any other tool. See the jstress.properties file for a list of the column names. The class ResultFields enumerates all the available fields. Note that the field values are only calculated if they are requested, so keep the number of columns to a minimum if you want to reduce the amount of cpu time JStress uses, some have more overhead than others.

When JStress completes, execute:

   r CMD BATCH r/plot.r

The line marked forced flow shows where the arrival rate and departure rate are equal (this line is calculated by R). Where the blue dotted line (departure rate) departs from this line is where your system has reached 100% utilization. In the above graph, this is at 6 requests a second. Following this point down the axis to the pink dotted line (concurrent requests), you can see how many requests were in the server at that arrival rate. Since this is exactly the point where the server has reached 100% utilization, we know none of the requests are queued, so the number of requests in the system at this rate are equal to the number of effective resource handlers in the server, in this example, the value is 2.

Note that your graph may not be as pretty as the one above, so you may need to tweak the properties file for a smoother profile (smaller step increments, or longer increment duration), or play around with the R settings. You can also narrow the start and end times to reduce the time it takes to execute the test.

If you want a mix of requests, you can add as many URLs to the service_urls.lst file as you like.