In order to be able to tune a system it is necessary to establish how the system currently performs. This is done by establishing and running a defined scenario. What this means will be explained shortly. The performance will be established according to the measured performance criteria (as defined previously). Accurately simulate the system usage – the key aspect of this is the definition of a baseline scenario. A baseline scenario defines a number of business processes that are used to emulate real user behavior for the business system.
A scenario is based on a number of business processes that are executed by virtual (automated) users according to a percentage user distribution.
User Think Time (think time)
The think time defines a value in seconds a virtual user will wait after completing a User Action before stating the next User Action and is independent of the system performance.
Identifying the think time and user distribution
Think time and user distribution describe what we define as a usage pattern for the system. Lets start with explaining the importance of those two factors on the performance of a system. The think time, as defined earlier, represents the time a user would take from having received a screen to submitting the next request. This time depends very much on the amount of information a user has to process before making and taking a decision on its further action as well as any amount of data that needs to be entered.
When we look at the Petstore application, for example, the time it takes from looking at the home page to clicking on a link will be significantly less than from looking a the address and payment details entry screen to submitting this information. The shorter the think time the higher the number of requests send to the system within a business process and therefore the higher the load on the system. There are different ways in obtaining think time information for a business process, i.e.:
• User interview.
• User observation.
• Logging of user behavior on the system.
When user interview and observation are not possible, i.e. public web site, then a logging of user behavior should be implemented and evaluated.
In cases where this data does not exist, estimations should be made on basis of own usage pattern and/or other data, i.e. the number of submitted orders during a day. We could now argue that the individual thinktime is irrelevant and could be calculated as an average thinktime between transactions based on the whole expected or calculated duration of a business process. Well if no other data is available this might be a solution, but keep the following in mind:
• Individual think times will create a different load pattern on the system than equally spaced out think times. The load pattern observed with individual think times can sometimes be referred to as a Heartbeat pattern, where quick successive requests follow a long period of idle time. The system therefore will need to be able to handle a spikier request pattern.
• Equally spaced out think times will avoid some of the spiky request pattern and enable the system to handle more load in terms of concurrent users than it would in reality. This needs to be pointed out when establishing the maximum number of concurrent users for a system.
The next parameter that determines the performance behavior of a system is the user distribution over the business processes (BP). For example, we have two business processes, one is Browse Books (BP 1) and the other one is Find all books that contain the letter ‘A’ in the title (BP 2). Given a number of concurrent users on the system as 100%. If 50% of all users are executing BP 1 at any one time on the system, the work the system will have to do will differ significantly from having 80% of all users executing BP 2.
Again the distribution of users over business processes can be retrieved on the same manner as for think times.
Information sources that help establishing think times and user distribution over business process can be the following:
• Access logs
• Session logs
• Page Requests per second
• Code execution statistics
• Database analysis