Writer: demonalex
Email: demonalex_at_dark2s.org
I have read the SQL statement "simulate DoS attacks to request services with web stress testing tools", especially for the purpose of finding out
For some of the functions, I did some experiments for a while (on the way, I would like to thank many netizens for donating my servers) and wrote
In the next article, I hope I can add some tips that SQL has no point in this article.
References: Simulate DoS attacks to request services using web stress testing tools, and Web Stress Testing Guide
Web stress testing (webstress) has always been a lot of IDC reviewers, network administrators, and network security experts targeting servers.
Focuses on performance and evaluation objects. Today, I am lucky to have a web stress test for a netizen's Vm (Suggestion: Stress Testing
Usually after penetration testing ).
Lab environment:
Tested (server): Win2000 advance SERVER + IIS + optical fiber bandwidth
Tester (client): Win2000 professional + MS web application stress + China Telecom ADSL
Purpose:
Test and analyze the overall stability of HTTP services provided by Web servers.
Test Plan:
Baseline: Static Test Case (HTM, JPG) [because friends only use simple HTML]
Test Tools: single client, test case library, client program
Analysis Method: use comparative analysis
Tested by: enterprise-class all-around VM
Target Audience: "Medium resource" virtual host (dark2s.net)
Test Scheme condition numerical indicator:
**************************************** **************************************** *****
URL thread Duration: whether to use random delay. Other values of virtual strangulation bandwidth
Bytes ------------------------------------------------------------------------------------
Random traversal address 20 5 minutes 200-400 (MS) 56 K modem (44 K) Default
**************************************** **************************************** *****
Tutorial steps:
Use web application stress (was) to generate two new stress testing scripts-> use record to record its url-> Configure
Conditional test indicators-> test-> Generate Report-> compare and analyze the results in the form of reports
Specific operations:
On the client (localhost), open the menu bar of the MS web application stress main program and choose "scripts"-> "CREATE"->"
Record ", select" record delay between request ", and press" Next ".
"Finish ".
Next, enter the address of the web server you want to test in the address bar of the pop-up browser, randomly browse several pages, and simulate normal failover.
Randomly use some web functions. Close the browser and click "stop recording" in was to return to the main page.
At the bottom of the script display interface, you will see a URL behavior list script (including behavior, URL address, group, and latency value ).
Enter the host address to be tested in the "server" input column at the top of the page. For example:
After completing the preceding steps, click "Settings" in the script list to go to the settings display page, and enter relevant parameter indicators.
Return to the main display page and click "run script" on the toolbar to enter the stress testing status.
Using Active ports to view the connection status, it is not difficult to find that was currently uses a multi-thread in the process for host
Simulate a connection test.
After the test is complete, click "reports" in the toolbar to view the test report. The test report is distributed in a tree, and the root is the tested service.
Split, the Child root is the test date, and the branch section under it is the classification index value of various numerical values. We want to obtain the entire tested server.
You only need to click the test date "sub-root" for the macro-value index.
The remaining server to be tested using the same steps and parameter indicators as above (due to the time relationship, John has
Put the prepared items in advance: P ).
The last task is data planning and comparative analysis. At the beginning, I thought that we needed manual data planning for these delicate sorting work (
The little god is out of sight !), It was later discovered that was has a built-in database (Microsoft is not a fuel-saving Lamp ). Use MS
Open the was. mdb database file under the was directory, and test all the test conditions in the project.
The data obtained through the test will be arranged in front of you in the form of a 'table. You only need to find the expected attribute class table and click it,
It is clear.
Next, save the. mdb database and use it as the initial data analysis blueprint for the test. After that, you only need to perform comparative analysis.
Use access to open the previously saved. mdb database, and link the data-type table to be analyzed
The 'report' class table can be linked to easily compare and analyze metric data.
Of course, if your boss has any special needs, you can also use Word, Excel and other tools to make a variety of analysis reports.
Submit the table... the "things" behind it will not be said: P.
This article writes that this simple web stress testing project has come to an end. Of course, web stress testing in real life
It's not that simple (maybe webstress testing in real life will drive you crazy: P ).
Finally, let's summarize the basic steps of the test:
① Understand the software used for testing. This is preparations before the test, any project, before starting the test,
All of them should have a comprehensive understanding of it, such as what the software is, and its functions and performance are mainly reflected in
And how can we reflect these features.
② Develop a test plan. A test plan is the process of defining a test project so that it can be correctly measured and controlled.
Testing.
③ Implement the test process. Follow the test plan and run the pre-designed test script under various conditions to record
Performance Parameters of server B and related clients.
④ Analyze the test results. The test will collect a large amount of data, which can help analyze the Web Application
Sequential performance.
######################################## ######################################## ##################################
Some tips about was:
After was is installed, a service named "WebTool" (process: "webtool.exe") is started every time windows is started.
To "Management Tools"-> "service", adjust this service to "Manual", and stop the service after each use of was, to avoid
Your system resources are used for a long time.
######################################## ######################################## ##################################
Related testing procedures web application stress (was) can go to my home page http://demonalex.dark2s.org
Download.
Appendix: basic metrics for web stress testing
========================================================== ========================================================== ====================
Number of hits: the total number of times virtual users click pages during the test interval
Requests per second: number of client requests per second
Threads: Number of threads, that is, the number of concurrent virtual users
Socket errors CONNECT: Number of socket errors
Socket errors send: Number of socket errors
Ttfb AVG: average between the first byte from the first request sent to the test tool and the first byte of the server response data received by the test tool
Time
Ttlb avg: flat between the first request sent and the last byte of the server response data received by the test tool
Average time
Based on the above data, you can analyze application performance from the following aspects and generate corresponding reports:
Number of hits vs. Users: total points that can be processed by the server within the specified time as the number of virtual users increases
Number of hits
Requests per second vs. Users: as virtual users increase, the server can process
Number of requests per second
Errors vs. Time: number of errors that may occur as the simulated access time continues
Errors vs. Users: number of errors with the increase of virtual users
Performance distribution vs. Users: Application Performance distribution for the number of virtual users, including services
Memory, CPU usage, etc.
Performance vs. Users: Changes in application performance as virtual users change
========================================================== ========================================================== ====================