How many concurrent users can you support your web server and application? Does the software have problems in the event of a lot of concurrent requests? These issues are unable to answer by the usual test. This article introduces the free tools WAS and their usage provided by Microsoft for this purpose. In addition, this paper introduces a performance optimization method for web applications and uses WAS testing its performance improvement. Original: http://www.asptoday.com/articles/20000420.htm Compile: As the server-side processing task is increasingly complex and the rapid growth of website access, the optimization of server performance has become a very urgent task. Before optimization, it is best to test the performance performance of the server under different conditions. Finding the performance bottleneck is a critical step in the design performance improvement program. This article introduces Microsoft's Web Application Stress Tool (WAS, Web Application Load Test Tool) Application in Web Server Performance Test (Note: Stress is basically meaningful to "heavy pressure; pressure", etc., "load" is "load"). In addition, we will also evaluate a relatively simple website performance improvement method. This method is to generate a static HTML page on the server to avoid excessive database calls. Load test is an important step in the development cycle of any web application. If you construct a application for a large number of users, you can figure out how much your product configuration is very important. If you are constructing a small intranet website, testing can eventually lead to memory vulnerabilities and competition in the server crash. No matter which situation, spending a payload test for application to obtain important reference performance data, which is convenient for future code optimization, hardware configuration, and system software upgrade. Even the limited development organization can also load their websites, because Microsoft's WAS is available for download. WAS requires Windows NT 4.0 SP4 or higher, or Windows 2000. In order to carry out the website, WAS can simulate a large number of users through one or more clients. WAS supports authentication, encryption, and cookies, can also simulate a variety of browser types and modem speeds, which can be comparable to 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 access the comparison page of the Microsoft Web Tool. To load testing on the website, you must first create a WAS script to simulate user activity. We can create a script with one of the following four methods: By recording the activity of the browser; by importing the IIS log; by pointing the WAS to the content of the web site; or manual manual Figure 1 shows part of the script generated by the browser event, the website is the Duwamish book Store of Microsoft. DuWamish is an example of Microsoft's e-commerce web application that can download this package from the "Phase 4" link from the Duwamish website. The download package contains its own WAS test script. [Figure 1] Making a WAS script is quite simple, but it is a bit complicated to make a script that simulates real user activity. If you already have a running web site, you can use the web server log to determine the user tap distribution on the Web site. If your app has not started running, then I have some guess according to my experience. Figure 1 In this script we assume that 30 members are browsing the bookstore, and there is another member being purchased. To simulate the blend of both, first you must create a page group and determine the click distribution in the script.
In the branch of Page Group, we can increase, modify or delete the page group, or modify the distribution of traffic for each group. Figure 2 shows the two page groups of GRP_BROWSE and GRP_BUY and the flow distribution of 30 to 1. [Figure 2] After the page group is created, we can give each request different page group in the main scriptime, as shown in Figure 3. Specifying a page group for each request is equivalent to how to distribute traffic. Remember that the request for the GRP_BUY group page accounts for about 3% of the total number of requests, and about 97% of the request for the GRP_BROWSE group page. Figure 3】 If you need to pass the Name-Value pair in the query string, you can use the WAS query string editor to define all possible values of each variable. After entering the variable value, each value of the variable can be required to use the variable, or the WAS may be required to randomly select the variable value when the request is requested. This increases the authenticity of the script simulation behavior to a certain extent, and can help avoid buffering the impact of the test results to prepare the test script, we can adjust the test configuration to observe the application performance under different conditions. Figure 4 is the setting interface of the WAS. Figure 4】 Stress Level and Stress Multiplier These two items determine the number of concurrent connections to the server. Microsoft recommends not to select a Stress Level value of 100. If the number of concurrent connections to analog is more than 100, Stress MultiPlier can be adjusted or using multiple clients. WAS will coordinate with other clients during load testing. See http://webtool.rte.microsoft.com/kb/hkb13.htm by using multiple clients in testing. If the site provides personalized services, you have to authenticate or use cookies, we also have to provide a user directory for WAS. The user in the WAS stores the password sent to the server and the server sent to the client. Increase the number of users does not increase the load of the web server. A sufficient number of users must be provided to meet the requirements of concurrent connections (Sterns Level multiplied by Stress Multiplier). For more information on threads, users, cookies interactions, see http://webtool.rte.microsoft.com/threads/wasthreads.htm. WAS allows the WARMUP (warm-up) time, typically can be set to 1 minute. During WARMUP, WAS starts a script, but does not collect statistics. Warmup time gives MTS, databases, and disk buffering and other opportunities to prepare. If you collect statistics within Warmup time, the overhead of these operations will affect performance test results. Another useful feature provided by setting the page is to limit the bandwidth (THROTTLE BANDWIDTH). The bandwidth restriction function is capable of testing MODEM (14.K K, 28.8 k, 56 k), ISDN (64 k, 128 k), and T1 (1.54 m). The use of bandwidth restrictions can accurately predict the performance of the client feels that the Web server accesses the web server via a dial network or other external connection. It is necessary to understand how these different settings affect the application, it is necessary to understand how to collect performance data using WAS. It is very convenient to obtain and analyze performance counters from remote Windows NT and Windows 2000 machines. The add counter is used to use the perf counters shown in Figure 5. [Figure 5] Select which counters in the test obviously be related to the test object. Although the list below is impossible to accurately isolate the performance bottleneck, it is a good start for the performance test of the general web server.
· Processor: CPU Using Percentage (% CPU Utilization) · Thread: Context Switches Per Second (Total) · ASP: Requests Per Second · ASP: Request Execution Time (Request Execution Time) · ASP: Request Wait Time · ASP: Requests Queued CPU Requests Queued CPU reflects the processor overhead. The CPU uses a percentage of more than 75% of the percentage of the performance bottleneck in the processor's obvious sign. The number of copied exchanges per second indicates the work efficiency of the processor. If the processor is trapped for thousands of contexts per second, it is busy switching threads instead of processing an ASP script. ASP request quantity, execution time, and waiting time per second are very important monitoring items in various test situations. The number of requests per second tells us the number of ASP requests to successfully process the server within each second. Perform time and wait time and the reaction time is displayed, which is the time required for the server to handle the recommended page. We can draw a change in the number of request quantities and reaction time as the number of users in the test. The number of requests per second will also increase when the number of concurrent users is increased. However, we will eventually reach such a point, at which time the number of users starts "overwhelming" servers. If you continue to add concurrent users, the number of requests per second begins to decline, and the reaction time increases. To find hardware and software capabilities, find out that the number of computed users start "overwhelming" server is very important. The number of ASP requests that placed in the queue is also an important indicator. If this quantity is fluctuated in the test, the number of requests received by a COM object exceeds its processing power. This may be because a low-efficiency component is used in the intermediate layer of the application, or a single-threaded unit component is stored in the ASP session object. The client CPU usage rate running WAS is also necessary to monitor. If the CPU usage on these machines continuously more than 75%, the client does not have enough resources to run the test correctly, and it should be considered that the test results are not credible. In this case, the number of test clients must increase, or reduce the Stress Level of the test. WAS will generate a detailed report after each test run, even if the test is stopped in advance. The WAS report can select Reports from the View menu. Here is a few important parts in the report. If this is a newly created test script, you should check the Result Codes section of the report. This part of the content contains the number of request code, description, and the number of result code returned by the server. If 404 code appears here (no page is found), you will explain the page request in the script. The page summary section provides the name of the page, the average time (TTFB) of the first byte is received, and the average time (TTLB) of the last byte is received, and the hit number of each page in the test script. Two values of TTFB and TTLB are important for calculating the server performance as seen by the client. The TTFB reflects the time sum (in millisecond meter) requested from the issued page request to the first byte of the answer data, and the TTLB contains TTFB, which is the accumulated time required to receive the last byte of the page. All performance counters are also included in the report. These data show the measured values of each project of the runtime, and also provides maximum, minimum, mean, and the like. The actual information provided by the report far exceeds the content we can introduce here. In order to give you an impression of the type of information provided, Figure 6 summarizes a report instance.
[Figure 6] With the increasingness of Internet applications, users' requirements and expectations are constantly developing. Today's customers expect individual customizable programs, expecting these solutions not only simple, and fast, reliable, low cost. For a customized page that can accommodate user demand, static HTML has exited the stage, such as one of the pages requested by the customer request. All requires the system to save relevant data, such as data about the user itself and the user may request. WEB developers keeping with these trends have begun to provide a customizable web site. Tasks such as search data can now be performed by the server without customer intervention. However, these changes have also led to a result, which is that many websites are called using a large number of unopened databases, making the application performance. We can use the following methods to solve these problems: 1. Optimize the ASP code. 2. Optimize the database call. 3. Use the stored procedure. 4. Adjust server performance. Excellent website design will pay attention to these issues. However, any database call adjustment significantly affects the response speed of the Web site compared to the speed of the static page, which is mainly due to the database call to each access website before sending the page. The performance optimization solution proposed here is based on the following fact: Accessing the static HTML page is fast than accessing those content depending on the database calls. Its basic idea is to write a static HTML page stored on the server before using the database extract information before the user access the page. In order to ensure that these static pages can reflect the changing database data in time, there must be a scheduler to manage the generation of static pages. Of course, this program is not able to adapt to all situations. For example, if a small amount of information is extracted from a large-capacity database of continuous changes, this solution is inappropriate. However, it is still a lot of occasions that can be applied to this program. To ensure that the static HTML page can be updated at the appropriate time, add the following code to the corresponding ASP page: [Figure 7] Whenever the page is called, the script will extract the last update time and compare it with the current time. . If the difference between two times is greater than the predetermined value, the update.asp script will run; otherwise, the ASP page sends the remaining HTML code to the browser. The last update time is obtained from the Application variable, and its first initialization is done by Global.asa. The specific update time interval should be adjusted according to the update of the page content. If the latest information is provided every time you access the ASP page, or the output is closely related to the user input, this method is not practical, but this method can adapt to the case where the information is updated at a fixed time interval. If the database content is updated by the customer by the appropriate ASP page, make sure the static page can automatically reflect the change in data, we can call the Update script in the ASP page. In this way, there is also the latest static HTML page on the server whenever the database content changes. Another way to process frequent variation data is to use the Microsft SQL Server 7.0 WEB Assistant Wizard, which can use Transact-SQL, stored procedures, etc. from SQL Server data to generate standard HTML files. With the SQL Server task, the Web Assistant Wizard can be used to periodically generate an HTML page. As the scheme described above, the web assistant can update the HTML page by trigger, such as executing updates at the specified time or performing updates when database data changes. SQL Server creates an HTML page using the stored procedure named sp_makewebtask, which is the name of the target HTML file and the name of the stored procedure, and the output of the query is sent to the HTML page. Alternatively, you can choose a template file that can be inserted with the result data.
As can be seen from the previous code, when the ASP page htmlmain.asp needs to be updated, the physical path to the ASP file is transferred to the Update page. The task of the UPDATE script is to use the new HTML data refresh to issue a call-to-the ASP file and add the scheduled ASP code to the beginning of the file. To do this, the UPDATE script opens the scheduler file, copy the scheduled ASP code, and then controls to another part of the script, this part of the script main task is to perform database operations. Update uses path parameters to open HTMLMain.asp files in writing mode, and the output of the database operation is written in HTML format. In case of the user access to the page, it is executing the update, we can use the lock or other similar mechanism to delay the page for a few seconds. HTMLMain.asp (pure HTML Demand ASP code) and main.asp (ordinary ASP file) perform performance test under WAS. Main.asp file To find 5 different tables as page extraction data. In order to compare with these two files, a SingletAbletest.asp and a pure HTML file (Plainhtml.html) have also been tested. The test results are as follows:
