There are several questions that arise when it comes to identifying performance bottlenecks and generating a refined performance report.
As you run any schedule in RPT, first it will have a run status as "Ramping" and later it goes to "Running" state. Once that run completes, then you get combined reports of both Ramp-up and Running state (Steady state).
So, you might ask: Is it possible to get separate reports for Ramp-up and Steady state (Running state) when you execute any schedule? Many customers have this question.
If no, then do you have any settings in RPT to get such separate report of Ramp-up state and Running state???
In RPT "Change Rate" is synonymous with "Ramp Up" or "Ramp Down". So, if you do not specify a change rate there is no ramp. If can also use the word ramp when describing your entire schedule, using "ramping up"
to refer to multiple successive stages where the user population is increasing or decreasing.
Response times are reported all the time. View response times for stage duration time range, if you do not want to see response times for the other periods of a single stage, which includes ramp up, ramp down,
or settle. The purpose of the change rate for a single stage is to provide support for "ramp up" or "Ramp Down". Change rate in combination with steady state duration together provide the opportunity to get past any caching / calming / indexing periods prior to gathering response times during the stage duration.
So, the next question that generally comes up is:
Does the response time include or vary with users ramp up duration or with the think times that we specify ?
The answer is if you right-click on the default report and select "Choose Time Range" you can choose to get report information for any of the user levels. The response times shown for the chosen time range only include response time for the stage duration, not the time spent ramping or in lag.
- The page response time does not include think time.
- Response time are reported all the time including during ramp up.
- Response time can be affected by the introduction of additional users during ramp up.
- Steady state lag time was introduced just for this reason -- to allow participating systems to calm down or reach steady state after users have been added during ramp up. The time range for a particular stage (population of users) starts after ramp up and after steady state lag.