The ab tool takes a single URL and requests it repeatedly in as many separate threads as you specify, with a variety of command-line arguments to control the number of times to fetch it, the maximum thread concurrency, and so on. A couple of nice features include the optional printing of progress reports periodically and the comprehensive report it issues. Example 4-1 is an example running ab. We instructed it to fetch the URL 100,000 times with a maximum concurrency of 149 threads. We chose these numbers carefully. The smaller the number of HTTP requests that the test client makes during the benchmark test, the more likely the test client will give less accurate results because during the benchmark the Java VM’s garbage collector pauses make up a higher percentage of the total testing time. The higher the total number of HTTP requests that you run, the less significant the garbage collector pauses become and the more likely the benchmark results will show how Tomcat performs overall. You should benchmark by running a minimum of 100,000 HTTP requests. Also, you may configure the test client to spawn as many client threads as you would like, but you will not get helpful results if you set it higher than themaxThreads you set for yourConnectorin your Tomcat’s conf/server.xml file. By default, it is set to150. If you set your tester to exceed this number and make more requests in more threads than Tomcat has threads to receive and process them, performance will suffer because some client request threads will always be waiting. It is best to stay just under the number of yourConnector’smaxThreads, such as using 149 client threads. Example 4-1. Benchmarking with ab $ ab -k -n 100000 -c 149 http://tomcathost:8080 Benchmarking tomcathost (be patient) Completed 10000 requests Server Software: Apache-Coyote/1.1 Document Path: /
Concurrency Level: 149 Time taken for tests: 19.335590 seconds Complete requests: 100000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 79058 Total transferred: 830777305 bytes HTML transferred: 813574072 bytes Requests per second: 5171.81 [#/sec] (mean) Time per request: 28.810 [ms] (mean) Time per request: 0.193 [ms] (mean, across all concurrent requests) Transfer rate: 41959.15 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 4.0 0 49 Processing: 2 26 9.1 29 62 Waiting: 0 12 6.0 13 40 Total: 2 28 11.4 29 65 Percentage of the requests served within a certain time (ms) 50% 29 66% 30 75% 31 80% 45 90% 47 95% 48 98% 48 99% 49 100% 65 (longest request) If you leave off the-kin the abcommand line, ab will not use keep-alive connections to Tomcat, which is less efficient because it must connect a new TCP socket to Tomcat to make each HTTP request. The result is that fewer requests per second will be handled, and the throughput from Tomcat to the client (ab) will be smaller (see Example 4-2). Example 4-2. Benchmarking with ab with keep-alive connections disabled $ ab -n 100000 -c 149 http://tomcathost:8080/ Benchmarking tomcathost (be patient) Completed 10000 requests
Server Software: Apache-Coyote/1.1
Concurrency Level: 149 Connection Times (ms)
Percentage of the requests served within a certain time (ms)
blog comments powered by Disqus | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|