Nginx application case sharing: Stress Testing

Stress testing is a very important task in O & M. For example, before a website goes online, the quality of data indicators will directly affect the user experience. However, there is a commonality in the stress test, that is, the results of the stress test are not exactly the same as those of the actual load, even if the stress test is done well, it cannot be guaranteed that 100% is the same as online performance indicators. In the face of these problems, we have to try our best to simulate them. Therefore, stress testing is very necessary. With this data, we can be aware of our own maintenance platform. Currently, common website stress testing tools include webbench, AB (apache bench), tcpcopy, and loadrunner. The advantages and disadvantages of webbench are developed by Lionbridge, it mainly tests the number of requests per second and the amount of data transmitted per second. It also supports static, dynamic, simple SSL deployment, and static and dynamic tests. This tool is applicable to stress testing for small websites (a single instance can simulate a maximum of 30 thousand concurrency). It is a stress testing tool that comes with apache (AB, the main function is to test the number of requests processed by the website per second. It is usually used for static stress testing. The function is weak. The non-professional stress testing tool tcpcopy is used to copy requests based on the underlying application and can forward various online requests to the testing server, with the distributed stress test function, the tested data is close to the actual production data, and is mainly used for medium and large stress tests. All tcp-based packages can be used to test the stress test of loadrunner, you can create virtual users to simulate real user access flows and record them as scripts. The test results are the most realistic and realistic. You can perform independent unit tests, but the deployment configuration is complicated, professional personnel are required. Next, I will take webbench as an example to explain how the stress test was performed before the website went online. Install webbench # wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz # Tar zxvf webbench-1.5.tar.gz # cd webbench-1.5 # make & make install stress testing concurrency 200 # webbench-c 200-t 60 http://blog.luwenju.com/index.php Parameter explanation:-c is the number of concurrent threads,-t is the time (seconds) Webbench-Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://blog.luwenju.com/index.php 200 clients, running 60 sec. speed = 1454 pages/min, 2153340 bytes/sec. requests: 1454 susceed, 0 failed. when the concurrency is 200, the Website access speed is normal and the concurrency is 800 # webbench-c 800-t 60 http://blog.luwenju.com/index.php Webbench-Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://blog.luwenju.com/index.php 800 clients, running 60 sec. speed = 1194 pages/min, 2057881 bytes/sec. requests: 1185 susceed, 9 failed. when the concurrent connection is 800, the Website access speed is slightly slow. When the concurrency is 1600, www.2cto.com # webbench-c 1600-t 60 http://blog.luwenju.com/index.php Webbench-Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://blog.luwenju.com/index.php 1600 clients, running 60 sec. speed = 1256 pages/min, 1983506 bytes/sec. requests: 1183 susceed, 73 failed. when the concurrent connection is 1600, the Website access speed is very slow and the concurrency is 2000 # webbench-c 2000-t 60 http://blog.luwenju.com/index.php Webbench-Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://blog.luwenju.com/index.php 2000 clients, running 60 sec. speed = 2154 pages/min, 1968292 bytes/sec. requests: 2076 susceed, 78 failed. when the concurrency is 2000, the website displays "502 Bad Gateway", which means that the web server can no longer process user access requests. Conclusion: 1. stress testing should be conducted before the product is launched, instead of going online 2. Try to perform tests across the public network, rather than the Intranet. 3. The concurrency during testing should gradually increase from small to small. For example, when the concurrency is 100, check the website load and whether the process is enabled, when the concurrency is 200, when the website is opened slowly, and when the website cannot be opened, the concurrency is 4. Perform unit tests as much as possible. For example, B2C websites can focus on test cart and promotion pages, because these pages account for a large proportion of the total site traffic