内容摘要 ab的全称是ApacheBench,是 Apache 附带的一个小工具,专门用于 HTTP Server 的benchmark testing,可以同时模拟多个并发请求。前段时间看到公司的开发人员也在用它作一些测试,看起来也不错,很简单,也很容易使用
中国源码网内相关主题链接
Java开源Html解析类库
自己写的Rap3d 引擎 开源发布啦
开源性能测试工具- Apache Bench
微软发布Oxite开源博客平台
开源license总结
开源商业模式失败但理念长存
Gartner:明年开源软件将在所有...
Sun要用开源赢未来
引子
按照原定计划,今天开始研究 JMeter,一天的时间看完了大半的 User Manual,发现原来只要沉住气,学习效率还是蛮高的,而且大堆的英文文档也没有那么可怕 ^_^
本来想顺便把文档翻译一下,不过后来想了想,看懂是一回事,全部翻译出来又是另外一回事了,工作量太大,而且这也不是我一开始要研究 JMeter 的本意。不如大家有兴趣一起研究的遇到问题再一起讨论吧。
开源工具通常都是为了某个特定的目的而开发出来的,所以如果想找到一个开源的性能测试工具去与LoadRunner 或者 QALoad 之类去比较,实在有些勉强。但是开源工具也有它自己的优势:小巧、轻便,在自己擅长的领域可以提供优秀的解决方案。所以,我们可以考虑准备一个自己的“开源测试工具箱”,平时利用空闲时间了解各种工具所适用的环境和目的,知识慢慢积累下来以后,就可以在遇到问题时顺手拈来,轻松化解 ^_^
另外,如果8月份和9月份的空闲时间足够多,我想我会写一个系列文章来讲述在实际的开发和测试过程中引入开源性能测试工具的情况。如果有朋友感兴趣,希望大家可以一起研究和讨论。
简介
ab的全称是ApacheBench,是 Apache 附带的一个小工具,专门用于 HTTP Server 的benchmark testing,可以同时模拟多个并发请求。前段时间看到公司的开发人员也在用它作一些测试,看起来也不错,很简单,也很容易使用,所以今天花一点时间看了一下。
通过下面的一个简单的例子和注释,相信大家可以更容易理解这个工具的使用。
一个简单的例子
/*在这个例子的一开始,我执行了这样一个命令 ab -n 10 -c 10 http://www.google.com/。这个命令的意思是启动 ab ,向 www.google.com 发送10个请求(-n 10) ,并每次发送10个请求(-c 10)——也就是说一次都发过去了。跟着下面的是 ab 输出的测试报告,红色部分是我添加的注释。*/
C:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 10 -c 10 http
://www.google.com/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.google.com (be patient).....done
Server Software: GWS/2.1
Server Hostname: www.google.com
Server Port: 80
Document Path: /
Document Length: 230 bytes
Concurrency Level: 10
/*整个测试持续的时间*/
Time taken for tests: 3.234651 seconds
/*完成的请求数量*/
Complete requests: 10
/*失败的请求数量*/
Failed requests: 0
Write errors: 0
Non-2xx responses: 10
Keep-Alive requests: 10
/*整个场景中的网络传输量*/
Total transferred: 6020 bytes
/*整个场景中的HTML内容传输量*/
HTML transferred: 2300 bytes
/*大家最关心的指标之一,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值*/
Requests per second: 3.09 [#/sec] (mean)
/*大家最关心的指标之二,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值*/
Time per request: 3234.651 [ms] (mean)
/*这个还不知道是什么意思,有知道的朋友请留言,谢谢 ^_^ */
Time per request: 323.465 [ms] (mean, across all concurrent requests)
/*平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题*/
Transfer rate: 1.55 [Kbytes/sec] received
/*网络上消耗的时间的分解,各项数据的具体算法还不是很清楚*/
Connection Times (ms)
min mean[+/-sd] median max
Connect: 20 318 926.1 30 2954
Processing: 40 2160 1462.0 3034 3154
Waiting: 40 2160 1462.0 3034 3154
Total: 60 2479 1276.4 3064 3184
/*下面的内容为整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间,其中 50% 的用户响应时间小于 3064 毫秒,60 % 的用户响应时间小于 3094 毫秒,最大的响应时间小于 3184 毫秒*/
Percentage of the requests served within a certain time (ms)
50% 3064
66% 3094
75% 3124
80% 3154
90% 3184
95% 3184
98% 3184
99% 3184
100% 3184 (longest request)
转载自:
版权声明:本文可以被转载,但是在未经本人许可前,不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载,请在转载是保留此版权声明,并保证本文的完整性。也请转贴者理解创作的辛劳,尊重作者的劳动成果。
作者:陈雷 (Jackei)
邮箱:
[email protected]
Blog:http://jackei.cnblogs.com