Return to HomePage

---

How To: Model a Workload (Workload Modeling)

Source: http://msdn.microsoft.com/library/en-us/dnpag/html/scalenetchapt16.asp
J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman

Workload modeling is the process of identifying one or more workload profiles to be simulated against the target test systems. Each workload profile represents a variation of the following attributes:
* Key scenarios.
* Numbers of simultaneous users.
* Rate of requests.
* Patterns of requests.

The workload model defines how each of the identified scenarios is executed. It also defines approximate data access patterns and identifies user types and characteristics.
You can determine patterns and call frequency by using either the predicted usage of your application based on market analysis, or if your application is already in production, by analyzing server log files. Some important questions to help you determine the workload for your application include:
* What are your key scenarios?
Identify the scenarios that are critical for your application from a performance perspective. You should capture these scenarios as a part of the requirements analysis performed in the very early stages of your application development life cycle.
* What is the maximum expected number of users logged in to your application?
Simultaneous users are users who have active connections to the same Web site. This represents the maximum operating capacity for your application. For the sample e-commerce application, assume 1,000 simultaneous users. If you are developing a new application, you can obtain these numbers by working with the marketing team and using the results of the team's analysis. For existing applications, you can identify the number of simultaneous users by analyzing your Internet Information Services (IIS) logs.
* What is the possible set of actions that a user can perform?
This depends upon the actions a user can perform when he or she is logged into the application. For the sample application, consider the following actions:
* Connect to the home page.
* Log on to the application.
* Browse the product catalog.
* Search for specific products.
* Add products to the shopping cart.
* Validate and place an order.
* Log out from the application.

* What are the various user profiles for the application?
You can group together the various types of users and the actions they perform. For example, there are groups of users who simply connect and browse the product catalog, and there are other users who log on, search for specific products, and then log out. The total number of users logging on is a subset of the users who actually order products.
Based on this approach, you can classify your user profiles. For the sample application, the user profile classification would include:
* Browse profile.
* Search profile.
* Place order profile.

* What are the operations performed by an average user for each profile?
The operations performed by an average user for each profile are based on marketing data for a new application and IIS log analysis for an existing one. For example, if you are developing a business-to-consumer e-commerce site, your research-based marketing data tells you that on an average, a user who buys products buys at least three products from your site in a single session.
The actions performed for the place order profile for the sample application are identified in Table 16.7.
Table 16.7: Actions Performed for the Place Order Profile
Operation Number of times performed in a single session
Connect to the home page. 1
Log on to the application. 1
Browse the product catalogue. 4
Search for specific products. 2
Add products in the shopping cart. 3
Validate and place order. 1
Log off from the application. 1

A typical user for the place order profile might not search your site, but you can assume such actions by averaging out the activity performed by various users for a specific profile. You can then create a table of actions performed by an average user for all the profiles for your application.
* What is the average think time between requests?
Think time is the time spent by the user between two consecutive requests. During this time, the user views the information displayed on a page or enters details such as credit card numbers, depending on the nature of operation being performed.
Think time can vary depending on the complexity of the data on a page. For example, think time for the logon page is less than the think time for an order placement page where the user must enter credit card details. You can average out the think time for all the requests.
For more information about think time, see “Testing Considerations,” later in this chapter.
* What is the expected user profile mix?
The usage pattern for each scenario gives an idea in a given time frame of the percentage mix of business actions performed by users. An example is shown in Table 16.8.
Table 16.8: Sample User Profile Over a Period of Time
User profile Percentage Simultaneous users
Browse 50% 500
Search 30% 300
Order 20% 200
Total 100% 1,000

* What is the duration for which the test needs to be executed?
The test duration depends on the workload pattern for your application and may range from 20 minutes to as long as a week. Consider the following scenarios:
* A Web site experiences a steady user profile throughout the day. For example, if you host an online e-commerce site, the operations performed by an average user visiting the site are unlikely to vary during the course of an 8-to-10 hour business day. The test script for such a site should not vary the profile of users over the test period. The tests are executed simply by varying the number of users for each test cycle. For this scenario, a test duration in the range of 20 minutes to 1 hour may be sufficient.
* A Web site experiences a varying profile of users on a given day. For example, a stock brokerage site might experience more users buying (rather than selling) stocks in the morning and the opposite in the evening. The test duration for this type of application may range between 8 and 16 hours.
* You may even run tests continuously for a week or multiple weeks with a constant load to observe how your application performs over a sustained period of activity. This helps you identify any slow memory leaks over a period of time.

---

Return to HomePage