I've been working on web service these days to find a tool test Under the concurrent request processing capabilities, we began to find web-ct, windows client, but it is not good to use after installation, and the free version can test up to 40 concurrent requests, up to 10 seconds.

This basically does not test anything, and there is 360 software Butler can not uninstall, need to go to the windows control panel to uninstall! ___________ Nausea...

A new continent, Webbench, was suddenly discovered today. Linux Next, it's very convenient, open source, no restrictions on concurrent access times and time... Da Ai!

Download Webbench

Import linux using wget or windows, at http://home.tiscali.cz/cz210552/distfiles/webbench-1.5.tar.gz

Compilation and installation

1. root@jack-desktop:~/software# tar xvzf webbench-1.5.tar.gz   
2. root@jack-desktop:~/software/webbench-1.5# make  
3. cc -Wall -ggdb -W -O   -c -o webbench.o webbench.c  
4. webbench.c: In function 'alarm_handler':  
5. webbench.c:77: warning: unused parameter 'signal'  
6. cc -Wall -ggdb -W -O  -o webbench webbench.o    
7. ctags *.c  
8. root@jack-desktop:~/software/webbench-1.5# make install  
9. install -s webbench /usr/local/bin  
10. install -m 644 webbench.1 /usr/local/man/man1  
11. install -d /usr/local/share/doc/webbench  
12. install -m 644 debian/copyright /usr/local/share/doc/webbench  
13. install -m 644 debian/changelog /usr/local/share/doc/webbench  
14. root@jack-desktop:~/software/webbench-1.5#   
15. root@jack-desktop:~/software/webbench-1.5# web  
16. webbench  webs     

ok, successful installation

Look at his help documentation

1. root@jack-desktop:~/software/webbench-1.5# webbench --help  
2. webbench [option]... URL  
3.   -f|--force               Don't wait for reply from server.  
4.   -r|--reload              Send reload request - Pragma: no-cache.  
5.   -t|--time <sec>          Run benchmark for <sec> seconds. Default 30.  
6.   -p|--proxy <server:port> Use proxy server for request.  
7.   -c|--clients <n>         Run <n> HTTP clients at once. Default one.  
8.   -9|--http09              Use HTTP/0.9 style requests.  
9.   -1|--http10              Use HTTP/1.0 protocol.  
10.   -2|--http11              Use HTTP/1.1 protocol.  
11.   --get                    Use GET request method.  
12.   --head                   Use HEAD request method.  
13.   --options                Use OPTIONS request method.  
14.   --trace                  Use TRACE request method.  
15.   -?|-h|--help             This information.  
16.   -V|--version             Display program version.  
17. root@jack-desktop:~/software/webbench-1.5#   

Use

The usage is simple. Here's a simple test usage

1. root@jack-desktop:~/software/webbench-1.5# webbench -c 100 http://localhost:12345/test  
2. Webbench - Simple Web Benchmark 1.5  
3. Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.  
4.   
5. Benchmarking: GET http://localhost:12345/test  
6. 100 clients, running 30 sec.  
7.   
8. Speed=495888 pages/min, 586798 bytes/sec.  
9. Requests: 247944 susceed, 0 failed.  

100 concurrent, running for 30 seconds, all access requests succeed, speed 495888 pages/min, 586798 bytes/sec

1. root@jack-desktop:~/software/webbench-1.5# webbench -c 1000 http://localhost:12345/test  
2. Webbench - Simple Web Benchmark 1.5  
3. Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.  
4.   
5. Benchmarking: GET http://localhost:12345/test  
6. 1000 clients, running 30 sec.  
7.   
8. Speed=414996 pages/min, 490915 bytes/sec.  
9. Requests: 207430 susceed, 68 failed.  

1000 concurrently, running for 30 seconds, accessing 68 failures and slowing down, 414996 pages/min, 490915 bytes/sec

But it fully meets my needs! Ha-ha

In addition, I also found a problem, that is, when the concurrency is very large, my server occupies a lot of resources, mainly the CPU occupies too much, sometimes up to 80%.

Conclusion:

 

Reproduce someone else's! But there's a reason for that.

1. Stress testing should be done before the product goes online, not after the product 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 how much the website load is, whether the process is open, 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 carried out as far as possible. For example, B2C websites can focus on testing shopping carts, promoting pages and so on, because these pages account for a large proportion of the total site visits.