Performance test using Web Application Stress Tool (WAS) (2)
Set test script
New recorded scripts cannot be used immediately to test. You must also complete the following settings:
· Adjust scripts and their properties
· Adjust test script test
· Create a page group and click on 100%
· Create user account
· Establish a client
· Establish performance counters
Adjusting script
When you modify a test script, you need to consider a few points, we will introduce below.
Remove unwanted scripts
Remove the redundancy to reduce the noise factors in the test or remove those invalid URLs. When you want to adjust a special feature, remove all scripts that point to images, style forms, and other auxiliary static files.
Specify the thinking time for the script
The last item of the script item form is called "delay". This allows you to specify a specific delay time (also called thinking time) before executing the script item.
For performance testing, how to define the thinking time is not a separate standard. Some people use zero thinking time, some people consider using 30 seconds for thinking time.
Mainly on the purpose of the site and the purpose of testing. For example, a site with long page content requires a long time than a simple page, because the user needs to use a multi-point time to read the page content.
Also, if your purpose is to quickly determine the throughput of only a small number of clients, you can consider zero thinking time. If you don't think about time, each thread of the WAS applies a pressure to the web server at the fastest speed.
Set a series of values for scripts
WAS allows you to assign values for a pair of names-values for a script, rather than using the same value for each request. This feature is very important for simulating the real situation, no user will request the same page with the same data value?
For example, one of the test scripts is requested to request an ASP page to show a detailed information for a product. We can set the WAS randomly select different values from a predefined product ID instead of requesting the ASP page with the same product ID.
Establish a column for script items
1. On the script item of the WAS window, double-click the first square button (first column of the form) open this detailed menu.
2. In the QueryString tag (also called QueryString Editor, as shown in Figure 3), select Format Data To CGI Standard. The corresponding name-value pair will appear in the form under Check Box.
Figure 3. QueryString Editor Screen
3. Click the selected name - value pair, a new button will appear
4. Click this button to open the Field Values dialog
5. Enter a string value in the Field Values dialog, each line a value. You can also input a spreadsheet data file by cutting.
6. In QueryString Editor, there is the same name in the form - value of the DISTRIBUTION. Select Random in the drop-down menu.
Set SSL for script items
To activate SSL for a specific script, you need to do the following:
1. On the script item of the WAS window, double-click the first square button (first column of the form) open this detailed menu.
2. In the SSL tag, select USE SSL. (Note Make sure the port value should be between 80 and 443 when you activate SSL). Adjustment script settings
For you to run your performance test satisfactorily, you need to modify the settings of your test script. By double-clicking on the script name to expand the script on the left, you will find a settings tag, where you can specify a lot of settings for your test script. Click on it to open the Settings view on the right window, as shown in Figure 4.
Figure 4. Settings View Screen
Specify target web server
By default, the target server is "localhost" and should be replaced with the IP address or the domain name of the target server.
Change setting
1. The name of the window point test script on the left
2. The IP address or domain name of the server input target server at the top of the right window
Note If you want to test a server group with Network Load Balancing, just like Duwamish Online, you need to enter an IP address group.
Set the number of concurrent connections
In the Concurrent Connections section in the settings, you can specify the value of Stress Level (Threads) and Stress Multiplier (Sockets Per Thread) to control the pressure / load level of the target server. Stress Level is the total number of Windows NT threads generated by all clients. Each thread can generate multiple sockets and each Socket is a concurrent request.
The following formula explains the relationship between them:
Total Concurrent Requests = Stress Level (THREADS) X stress multiplier (sockets per thread) = Total Number Sockets
In our laboratory, we use different Stress hierarchical performance tests. For example, we have used values of 100, 200, 300, 1500, and 2000 to continuously test to study how our server group reacts for continuous growth.
You should adjust these values based on the results of the initial test. In general, you need to collect more data points at low negative loads, as this time the system throughput increases linearly with the growth of threads. On the other hand, you can run less tests at high orientation to save time and effort, especially when system throughput is above peak.
Note Our first test will be set to 1000 threads. The purpose is to run enough requests to build data buffers in our program. Because the performance of the program is very different because there is no buffering, this will help us maintain a consistent environment for the load test.
Set the test run time
At the Test Run Time section of the setting view, you can set the total running time in days, hours, minutes, and seconds. Depending on your script's expected reaction time, it is recommended that you run the test script at least a few minutes to generate enough requests to avoid deformation test results. The higher the reaction time of your program, the longer the time of the test, in order to produce a lot of data.
You can run a short-intensive test to monitor any questions in your site. In addition, you need to run longer test times (for example, 30 days) to see if your site is degraded over time, especially under intermediate or advanced load pressures.
At Duwamish Online, most performance tests run 7 to 10 minutes to have enough time to stabilize the test results.
Set random delay time
In the Request Delay section of the setting view, you can choose to join the random delay time (or think time) for each script before performing the test. If the USE Random DELAY option box is selected, each WAS thread will idle a random time (between the maximum and minimum values) plus the fixed thinking time specified for each script. The following formula explains the calculation method of the delay time:
Delay time of each item = random delay time 10 fixed delay time
The characteristics of the random delay time are especially important when the fixed delay time is specified to the script. If the random delay time is not used, all threads will send a request to the web server almost the same time, then wait almost the same fixed delay time and then send the next request. Random delay time helps to flatten peaks and valley when applied to the web server, so a more accurate environment is presented for the required load level.
Set the pending time
In the Suspend section of the set view, you can set the Warmup and Cold NowN time at day, hours, minutes, seconds. Warmup time is initializing test running time, which does not collect and calculate performance data during this time. Similarly, the COOLDOWN time is the test time in the specified end phase, nor does not collect data. WARMUP and COOLDOWN are used to minimize the distortion of the test results.
Typically, in the initialization phase of a new test run, many system resources are consumed by specific activities, such as buffering initialization of components or applications. Warmup time helps to stabilize the system before any test data is collected.
On the other hand, the COOLDOWN time helps to avoid deformation of data at the end phase of the test run, and additional system resources are used to stop testing and start collecting data from the client. In addition, the Socket connection may stop early, causing a large number of socket errors.
In Duwamish Online, we use 30 to 60 seconds as the Warmup and CoolDown time for most performance tests.
Specify bandwidth bottleneck
In the Bandwidth section in the setup view, WAS allows you to simulate the network bandwidth connected to the 14.4 Kbps MODEM to the T1 (1.5 Mbps) Local Area Network (LAN) connection. The greatest advantage of this feature is that a large number of concurrently connected to the target server. This is the case of most Web sites (users using low-speed MODEM connections).
Activate bandwidth bottleneck
1. Select the THROTTLE BANDWIDTH option box in the BandWidth section of the setting view.
2. In the drop-down menu, select a bandwidth that represents the connection throughput of most users.
In Duwamish Online, we tried the settings of different bandwidth bottlenecks. Initialization. We set the user to 56 kbps, and we would like to understand how our procedure is in most Web sites. We also tried to connect users in ISDN Dual Channel (128 kbps) to simulate future broadband trends, most users access our site via fast connection. Finally, we test our site with the situation where there is no bandwidth bottleneck. Interestingly, we found that the load conditions generated by this setting are the same as 128 kbps.
No matter how you set the bandwidth bottleneck, you must keep consistency in all tests you want to compare the test results.
Specify other settings
In the other part of the setting view, we maintain the default value, except for the HTTP redirection. We deliberately remove the FOLLOW HTTP Redirects option. This is necessary when you record the URL redirection when you record the script during the creation of a script. You don't need to run those URLs twice twice.
Set page group
In WAS, you can organize a series of scripts into a so-called page group. This feature allows you to organize all page elements (including HTML files, image files, style forms, etc.) or multiple connected pages into a logical unit. You can specify a different click rate for each page group, so that you can control which page or connected page will access more or less. If you have your website's usage - like directory browsing or shopping cart - page group allows you to run with you want your site. Create a page group
1. Expand the information of the script of the left window
2. Point Page Groups Node Open the appropriate view on the right window
You will see that the default page group in 100% distribution rate has been created. All scripts are initialized to this group by default.
3. In the blank line of the group form, enter a new group name in the group column ("Home" as the home page), enter the value at the Distribution column. The distribution rate will be used to calculate the click rate of this page group, see the percentumn. Repeat this step to add more page groups.
4. Script name of the left window Back to this script
5. Select one of the page groups from the drop-down menu on the Group list of the script item form. Repeat this step for each script. All associated pages should choose the same page group.
Figure 5. EXAMPLE OF Page Groups Definition
6. Script name of the left window Back to this script
7. A list of Groups in the form of the script, one of the page groups from the drop-down menu, see Figure 6.
Figure 6. Script items View Screen Showing GROUP SELECTION
8. Repeat 6 to 7 to select a page group for each script. All related items (like ASP pages, style forms, and image files) should choose the same page group.
Another way to create and specify a page group is to specify a page group when recording a script. To use this method, return to the WAS window before the browser jumps to the new page (see Figure 2). Click the Change Group button and enter the group name in the New Group dialog. Script items recorded later are assigned to this new group.
Specify user
When testing the Web site that needs to be signed up, WAS provides a feature called users, which can be used to store usernames, passwords, and cookie information for multiple users.
When a test begins, all users are assigned to each thread set for a given pressure coefficient. When the request starts, each thread uses the username, password, and cookie obtained from the shared pool connected to the thread. If the number of users configured is less than the thread, some threads will have no users - all sign-on page will be logged in failure, and any interaction with cookies will be disabled. So, when testing a website that requires personal authentication, the number of users has more important than threads.
There is no rigid specified and restrictions on the number of users that can be created in WAS. However, because each user will require a certain amount of memory and resources, if a large number of users will make your test start and stop time longer.
Create a new user
1. Expand the information of the script on the left window
2. Click the USERS node to open the appropriate view on the right window
3. Double-click the Default user group to open the user view.
Note that 200 users have been created by default. You can simply modify the username and password.
You can also do the following to create a new user
1. Point Remove All Clear all records
2. In Number Of Users, enter the number of new users you want to create 3. In User Name Prefix, you can enter the prefix value in front of the user number, such as "User."
4. In Password, enter your password. The same password will assign all users.
5. Finally, click the CREATE button. The user form will fill the specified number of users
If you want to use a custom username and password list, you can import them from a schedule format text file. Refer to the "Importing User Names and Passwords" section of the WAS Help file.
