Introduction to WAS server load testing software

Post: Unknown Source How many concurrent user accesses can your Web servers and Applications Support? Is the software faulty when a large number of concurrent requests occur? These questions cannot be answered by common testing methods. This article introduces Microsoft's free tool WAS for this purpose and its usage. In addition, this article introduces a Web application performance optimization method, and uses WAS to test its performance improvement degree. Compilation is as follows: with the complexity of server processing tasks and the rapid growth of website traffic, server performance optimization has become a very urgent task. Before optimization, it is best to test the performance of servers under different conditions. Identifying performance bottlenecks is a crucial step before designing a performance improvement solution. This article introduces Microsoft's Web Application Stress Tool (WAS, Web Application load testing Tool) in Web server performance testing applications (note: the basic meaning of Stress is "heavy load; pressure", etc, this article is called "LOAD "). In addition, we will also evaluate a relatively simple website performance improvement method through WAS. The basic idea of this method is to generate static HTML pages on the server to avoid excessive database calls. Load testing is an important step in the development cycle of any Web application. If you are constructing an application that serves a large number of users, it is very important to figure out how much load your product configuration can bear. If you are constructing a small Intranet website, the test will expose the memory vulnerabilities and competition that will eventually cause the server to crash. In either case, it takes some time to perform load tests on the application to obtain important benchmark performance data, facilitating future code optimization, hardware configuration, and system software upgrades. Development organizations with limited funds can perform load tests on their websites because Microsoft WAS can be downloaded for free. WAS requires Windows NT 4.0 SP4 or higher, or Windows 2000. To perform load tests on websites, WAS can simulate a large number of user activities through one or more clients. WAS supports authentication, encryption, and Cookies. It can also simulate various browser types and Modem speeds. Its functions and performance can be comparable to those of tens of thousands of dollars. If you are interested in the difference between WAS and Microsoft's other Test Tool Web Capacity Analysis Tool (WCAT), you can visit the Microsoft Web Tool comparison page. To test the website load, you must first create a WAS script to simulate user activity. We can use one of the following four methods to create a script: Record browser activities, import IIS logs, direct WAS to Web site content, or manually create a script. Figure 1 shows part of the script generated by recording browser events. The website is Microsoft's Duwamish Book Store. Duwamish is an e-commerce Web application example developed by Microsoft. You can download this software package from the "Phase 4" link on the Duwamish website. The downloaded package contains its own WAS test script. [Figure 1] creating a WAS script is quite simple, but it is a bit complicated to create a script to simulate real user activity. If you already have a running Web site, you can use the Web server logs to determine the user click distribution on the Web site. If your application has not started running, you have to make some guesses based on experience. Figure 1 in this script, we assume that 30 members are browsing the bookstore, and another member is purchasing. To simulate a combination of the two, you must first create a Page Group and confirm the click distribution in the Page Group branch of the script. In the Page Group branch, we can add, modify, or delete Page groups, or modify the traffic distribution for each Group. Figure 2 shows the grp_browse and grp_buy page groups and the traffic distribution of ratio 30 to 1. [Figure 2] after creating a page group, we can assign different page groups to each request in the main script, as shown in figure 3. Specifying a page group for each request is equivalent to telling WAS how to distribute traffic. Remember that in this example, requests to the grp_buy group page account for about 3% of the total, and requests to the grp_browse group page account for about 97%. [Figure 3] If you need to pass the "name-value" pair in the query string, you can use the query string editor of WAS to define all possible values of each variable. After entering the variable value, you can either require that WAS use the variable values sequentially or randomly select the variable value during the request. This increases the authenticity of the behavior simulated by the script to a certain extent, and helps avoid the impact of buffering on the test results. After preparing the test script, we can adjust the test configuration to observe the application performance under different conditions. Figure 4 shows the WAS setting interface. Figure 4 Stress Level and Stress multiplier determine the number of concurrent connections to the server. Microsoft recommends that you do not select a Stress Level value greater than 100. If the number of concurrent connections to be simulated exceeds 100, you can adjust the Stress multiplier or use multiple clients. During the load test, WAS will coordinate with other clients through DCOM. For more information about using multiple clients in the test, see http://webtool.rte.microsoft.com/kb/hkb13.htm. If the website provides personalized services and requires authentication or use of Cookies, we also provide a user directory for WAS. Users in WAS store the password sent to the server and Cookies sent from the server to the client. Increasing the number of users does not increase the load on Web servers. A sufficient number of users must be provided to meet the requirements for concurrent connections (Stesss Level multiplied by Stress Multiplier ). For more information about the interaction between threads, users, and Cookies, see http://webtool.rte.microsoft.com/threads/wasthreads.htm. WAS allows you to set the warm-up time. Generally, it can be set to 1 minute. During the warmup period, WAS starts to execute scripts, but does not collect statistics. The warmup time provides MTS, databases, and disk buffering opportunities to prepare for the operation. If statistical data is collected during the warmup time, the overhead of these operations will affect the performance test results. Another useful function provided by the page is to limit the bandwidth (throttle bandwidth ). The bandwidth limit function can simulate the speed of Modem (14.k K, 28.8 K, 56 K), ISDN (64 K, 128 K), and T1 (1.54 M) for testing. The bandwidth Limit Function accurately predicts the performance of a user who accesses a Web server through a dial-up network or other external connections. To understand the impact of these different settings on applications, it is necessary to understand how to use WAS to collect performance data. WAS is convenient for obtaining and analyzing Performance counters from remote Windows NT and Windows 2000 machines. To add a counter, use the Perf Counters branch shown in Figure 5. Figure 5: The counters selected in the test are clearly related to the purpose of the test. Although the following list cannot precisely isolate the performance bottleneck, it is a good start for general Web server performance tests. · Processor: CPU usage percentage (% CPU Utilization) · thread: Number of Context Switches Per Second (Total) · ASP: Number of Requests Per Second (Requests Per Second) · ASP: Request Execution Time · ASP: Request Wait Time · ASP: Number of Requests placed in the queue (Requests Queued) CPU usage percentage reflects the CPU overhead. CPU usage continuously exceeds 75%, which is a significant indication of performance bottleneck in the processor. The number of context switches per second indicates the processing efficiency. If the processor is stuck in thousands of context switches per second, it is busy with switching threads rather than processing ASP scripts. The number of ASP requests, execution time, And wait time per second are important monitoring items in various test cases. The number of requests per second indicates the number of ASP requests successfully processed by the server per second. The sum of execution time and wait time shows the response time, which is the time required for the server to respond to the response on the processed page. We can plot the change of the number of requests per second and the response time as the number of concurrent users increases in the test. When the number of concurrent users is increased, the number of requests per second also increases. However, we will eventually reach this point where the number of concurrent users begins to overwhelm the server. If you continue to increase the number of concurrent users, the number of requests per second starts to decrease, and the response time increases. It is important to understand the hardware and software capabilities and find out the critical point where the number of concurrent users begins to overwhelm the server. The number of ASP requests placed into the queue is also an important indicator. If the number of requests varies during the test, the number of requests received by a COM Object exceeds its processing capability. This may be because an inefficient component is used in the application's middle layer, or a single-threaded unit component is stored in the ASP session object. It is also necessary to monitor the CPU usage of the client running WAS. If the CPU usage on these machines continues to exceed 75%, it means that the client does not have enough resources to correctly run the test. In this case, the test results should be considered untrusted. In this case, the number of test clients must increase or reduce the test Stress Level. After each test is completed, WAS generates a detailed report, even if the test is stopped in advance. You can select Reports from the View menu to View WAS Reports. The following describes several important parts of the report. If this is a newly created test script, check the Result Codes section of the report. This part contains the request result code, description, and number of results codes returned by the server. If Code 404 is displayed (the page is not found), it indicates that there is an error page request in the script. The page summary section provides the name of the page, the average time of the first byte received (TTFB), and the average time of the last byte received (TTLB ), and the number of hits on each page in the test script. The TTFB and TTLB values are of great significance for the server performance seen by the computing client. TTFB reflects the total time (in milliseconds) from sending a page request to receiving the first byte of the response data. TTLB includes TTFB, it is the cumulative time required by the client to receive the last byte of the page. The report also contains information about all performance counters. The data shows the measured values of each item during running, and provides the maximum value, minimum value, and average value. The actual information provided by reports far exceeds what we can introduce here. To give you an impression on the types of table information, figure 6 extracts a report instance. [Figure 6] With the increasing popularity of Internet applications, users' requirements and expectations are constantly evolving. Today's customers are looking forward to personalized and customizable solutions that are not only simple, but also fast, reliable and cost-effective. For custom pages that can adapt to changing user requirements, static HTML has been withdrawn from the stage. For example, pages whose content varies according to customer requests are an example. All of this requires the system to save relevant data, such as the data about the user itself and what information the user may request. Web developers that keep up with these trends have begun to provide customizable Web websites. Tasks such as data search can now be executed by the server without customer intervention. However, these changes have also led to a result, that is, many websites are using a large number of unoptimized database calls, thus greatly reducing the applicability. We can use the following methods to solve these problems: 1. Optimize ASP code. 2. Optimize database calls. 3. Use stored procedures. 4. Adjust the server performance. Excellent website design will focus on these issues. However, compared with the speed of static pages, any database call will significantly affect the Web site response speed, this is mainly because the database must be called separately for each user accessing the website before sending the page. The performance optimization scheme proposed here is based on the fact that accessing static HTML pages is faster than accessing pages that depend on Database calls. Its basic idea is: before a user accesses a page, information is extracted from the database in advance and written to the static HTML page stored on the server. To ensure that these static pages can reflect constantly changing database data in a timely manner, a scheduler must manage the generation of static pages. Of course, this solution cannot adapt to all situations. For example, it is not appropriate to extract a small amount of information from a large database that is constantly changing. However, there are still many scenarios where this solution can be applied. To ensure that static HTML pages can be updated at the appropriate time, add the following code to the front of the corresponding ASP page: With the increasing popularity of Internet applications, user requirements and expectations are constantly evolving. Today's customers are looking forward to personalized and customizable solutions that are not only simple, but also fast, reliable and cost-effective. For custom pages that can adapt to changing user requirements, static HTML has been withdrawn from the stage. For example, pages whose content varies according to customer requests are an example. All of this requires the system to save relevant data, such as the data about the user itself and what information the user may request. Web developers that keep up with these trends have begun to provide customizable Web websites. Tasks such as data search can now be executed by the server without customer intervention. However, these changes have also led to a result, that is, many websites are using a large number of unoptimized database calls, thus greatly reducing the applicability. We can use the following methods to solve these problems: 1. Optimize ASP code. 2. Optimize database calls. 3. Use stored procedures. 4. Adjust the server performance. Excellent website design will focus on these issues. However, compared with the speed of static pages, any database call will significantly affect the Web site response speed, this is mainly because the database must be called separately for each user accessing the website before sending the page. The performance optimization scheme proposed here is based on the fact that accessing static HTML pages is faster than accessing pages that depend on Database calls. Its basic idea is: before a user accesses a page, information is extracted from the database in advance and written to the static HTML page stored on the server. To ensure that these static pages can reflect constantly changing database data in a timely manner, a scheduler must manage the generation of static pages. Of course, this solution cannot adapt to all situations. For example, it is not appropriate to extract a small amount of information from a large database that is constantly changing. However, there are still many scenarios where this solution can be applied. To ensure that the static HTML page can be updated at the appropriate time, add the following code to the front of the corresponding ASP page: <% LastUpdated = Application ("LastUpdated") presentTime = now if DATEDIFF ("h", lastUpdated, presentTime)> = 1 then Application ("LastUpdated") = presentTime response. redirect "Update. asp? Physicalpath = "& Request. ServerVariables (" PATH_TRANSLATED ") end if %> Each time the page is called, the script extracts the last update time and compares it with the current time. If the difference between the two times is greater than the predefined value, the Update. asp script runs. Otherwise, the ASP page sends the remaining HTML code to the browser. The last update time is obtained from the Application variable. Its first Initialization is completed by global. asa. The specific update interval should be adjusted according to the Update Requirements of the page content. This method is not practical if you need to provide the latest information each time you access the ASP page, or the output is closely related to user input, however, this method can be used to update information at a fixed interval. If the database content is updated by the customer through an appropriate ASP page, to ensure that the static page can also automatically reflect data changes, we can call the Update script on the ASP page. In this way, the server also has the latest static HTML page whenever the database content changes. Another way to process frequently changed data is to use the Web Assistant Wizard of Microsft SQL Server 7.0 ), this wizard can generate standard HTML files from SQL Server data, such as Transact-SQL and stored procedures. The Web Assistant wizard can periodically generate HTML pages using SQL Server tasks. As described above, the Web assistant can trigger a sub-update HTML page, such as executing an update at a specified time or performing an update when the database data changes. SQL Server uses a stored procedure named sp_makewebtask to create an HTML page. Its parameters are the name of the target HTML file and the name of the stored procedure to be executed. The query output is sent to the HTML page. You can also select the template file that can be inserted into the result data. As shown in the preceding Code, when the HTML main. ASP page needs to be updated, the physical path of the asp file is changed to the Update page. The Update script job is to use the new HTML data to refresh the called ASP file and add the scheduling ASP code to the beginning of the file. To this end, the Update script opens the scheduling template file, copies the ASP code for scheduling, and then transfers the control to another part of the script. The main task of this part is to execute database operations. Update uses path parameters to open the HtmlMain. asp file in write mode. The output of database operations is written to this file in HTML format. In case that the user accesses the page while performing updates, we can use the lock or other similar mechanisms to delay the page for several seconds. HtmlMain. asp (HTML-only and ASP scheduling code) and main. asp (Common ASP files) are tested in WAS. The main. asp file looks for five different tables to extract data for the page. In order to compare the two files, an ASP page (singletabletest.asp;and a pure HTML file (plainhtml.html) of a single table is also tested. The test results are as follows: File Name Number of hits Average TTFB (MS) Average TTLB (MS) PlainHtml.html 8 47 474 SingleTableTest. asp 8 68.88 789.38 Main. asp 9 125.89 3759.56 HtmlMain. asp 9 149.89 1739.89 TTFB refers to Total Time to First Byte, and TTLB refers to Total Time to Last Byte. These tests are performed on a Windows NT Workstation 4.0 SP6 machine running the Personal Web Server. To make the performance indicator more obvious, the bandwidth is limited to 14.4 kb. In the actual environment, the value may change greatly, but this result accurately reflects the performance differences of each page. The test results show that the processing time for accessing an ASP page for a single table is 720.5 ms, while that for a pure HTML file is 427 ms. The output time of Main. asp and HtmlMain. asp is the same, but their processing time is 3633.67ms and 1590 ms, respectively. That is to say, in this test environment, we can increase the processing speed by 43%. If we want to update the page every few times, for example, 100 times, the 100th users must wait for the new HTML page to be generated. However, this price may not be too high, and 99 Other users have benefited. The Static Page method is not suitable for all types of pages. For example, some pages must have user input before any processing. However, this method can be successfully applied to pages that do not rely on user input but call a large number of databases, and in this case it will exert greater efficiency. In most cases, the generation of dynamic pages will greatly improve the website's performance and do not require functional compromise. Although many large websites use this policy to improve performance, many websites have poor performance because of a large number of unnecessary database calls. Microsoft's WAS is a highly functional server performance testing tool that helps us determine exactly what solutions will be suitable for improving website performance; whether a scheme (such as the static page scheme in the second part of this article) can significantly improve the performance. The introduction of WAS in this article is quite rough and superficial. WAS also provides an object model, which can be expanded using scripts. Access http://webtool.rte.microsoft.com /? ObjModel/default.htm shows a script example. This script registers the maximum number of requests per second on the Web server and automatically increases the Stress Level value until the server processor utilization reaches 90%. WAS provides you with rich information about ASP applications and the hardware they run. After spending some time on WAS, you can gain a deeper understanding of the performance, stability, bottlenecks, and limitations of your applications. It is worthwhile to spend this time.