Stress testing is a very important work in operation and maintenance. For example, before a website goes online, how many visits can it endure and how well it performs in the case of large visits, the quality of these data indicators will directly affect the user experience.

However, there is a common feature in stress testing, that is, the results of stress testing will not be exactly the same as the actual load results, even if the stress testing work is done well, it can not guarantee that 100% and online performance indicators are the same. Faced with these problems, we can only try our best to simulate. Therefore, stress testing is very necessary, with these data, we can maintain their own platform to do well in mind.

At present, webbench, ab(apache bench), tcpcopy and load runner are the most common stress testing tools for websites.

webbench is developed by Lionbridge. It mainly tests the number of requests per second and data transmission per second. It also supports static, dynamic and SSL. It is easy to deploy and can be tested both statically and dynamically. Suitable for small website stress testing (single case can simulate up to 30,000 concurrent).

ab(apache bench)Apache has its own stress testing tool, which is mainly used to test the number of requests processed per second by the website. It is often used for static stress testing, with weak functions and non-professional stress testing tools.

tcpcopy is based on the replication of the underlying application request, and can forward various online requests to the test server. It has distributed stress testing function. The test data is close to the actual production data. It is mainly used in medium and large-scale stress testing. All packets based on tcp can be tested.

The leader of load runner stress testing circle can create virtual users, simulate users'real access process and record scripts. The test results are also the most realistic simulation and the most realistic, and can carry out independent unit testing. However, the deployment configuration is more complex, which requires professionals to do.

Next, I will take webbench as an example to explain how stress testing is done before the website goes 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

Conduct stress test, concurrent 200 hours.

# webbench -c 200 -t 60 http://down.chinaz.com/index.php

Parametric interpretation: - c is concurrent, and - t is time (seconds)

Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://down.chinaz.com/index.php
200 clients, running 60 sec.
Speed=1454 pages/min, 2153340 bytes/sec.
Requests: 1454 susceed, 0 failed.

When concurrent 200, the site visits at normal speed

Concurrent 800 hours

#webbench -c 800 -t 60 http://down.chinaz.com/index.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://down.chinaz.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 access speed of the website is slightly slow.

Concurrent 1600 hours

#webbench -c 1600 -t 60 http://down.chinaz.com/index.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://down.chinaz.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 access speed of the website is very slow.

Concurrent 2000 hours

#webbench -c 2000 -t 60 http://down.chinaz.com/index.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://down.chinaz.com/index.php
2000 clients, running 60 sec.
Speed=2154 pages/min, 1968292 bytes/sec.
Requests: 2076 susceed, 78 failed.

When concurrent 2000 occurs, "502 Bad Gateway" appears on the website, which shows that the web server can no longer process user access requests.

Conclusion:

1. Stress testing should be done before the product goes online, not after it goes online.

2. When testing, try to cross the public network, not the intranet.

3. The concurrency in testing should be gradually increased from small to large. For example, when concurrent 100, observe the load of the website, whether the process is open, and how much concurrency is when concurrent 200, how much concurrency is when the website opens slowly, and how much concurrency is when the website cannot be opened.

4. Unit testing should be done as far as possible. For example, B2C website can focus on testing shopping carts and promoting pages, because these pages account for a large proportion of the total site visits.