请不要拿并发数混淆视听！
[问题点数：40分]
请不要拿并发数混淆视听！
[问题点数：40分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2013年9月 其他开发语言大版内专家分月排行榜第二2013年8月 其他开发语言大版内专家分月排行榜第二2013年7月 其他开发语言大版内专家分月排行榜第二2011年4月 PHP大版内专家分月排行榜第二
2013年10月 PHP大版内专家分月排行榜第三2013年5月 PHP大版内专家分月排行榜第三2013年4月 其他开发语言大版内专家分月排行榜第三2013年4月 PHP大版内专家分月排行榜第三2013年3月 其他开发语言大版内专家分月排行榜第三2011年5月 PHP大版内专家分月排行榜第三
本帖子已过去太久远了，不再提供回复功能。当前位置： →
→ ab,qps,服务器性能压力
ab,qps,服务器性能压力
& 作者及来源： 陳聽溪 - 博客园 &
&收藏到→_→：
摘要: ab,qps,服务器性能压力
"ab,qps,服务器性能压力"：：
/program/641799.html
转载：并发用户数和qps两个概念没有直接关系转自: http://blog./?p=10029关于并发用户数和qps，自己一直被这两个概念纠结，阅读了一下相关资料，总结如下：并发用户数和qps两个概念没有直接关系，但是如果要说qps时，一定需要指明是多少并发用户数下的qps，否则豪无意义，因为单用户数的40qps和20并发用户数下的40qps是两个不同的概念。前者说明该应用可以在一秒内串行执行40个请求，而后者说明在并发20个请求的情况下，一秒内该应用能处理40个请求
/articles/zbafyf
并发连接数 = pv / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 /
pv = 并发连接数 * 统计时间 *
数量/ 页面衍生连接次数 / http响应时间 / 因数
解释：& 统计时间 : pv统计的总时间，单位秒，要计算一天的pv就是86400秒& 页面衍生连接次数: 一个html页面可能会请求好几次http连接，如外部的css,
,图片等,可以估算一下，或者用10,可根据实际情况改变& http响应时间: 可以使用1秒或更少,可根据实际情况改变& 因数: 一般使用5即可,可根据实际情况计算后推出&
* &页面衍生连接次数&，&http响应时间&，&因数&这三个参数要根据实际情况分析计算后，确定一个适合的值
推算一下。单台机器1000并发的情况下，一天是1,728,000的pv(1秒响应，10个衍生连接，因子为5的情况下)& ======================================================================
保证每天多少pv的并发连接数的计算公式是：& 并发连接数＝ pv / 统计时间(一天是86400) * 页面衍生连接次数 * http响应时间 * 因数(5) /
保证4千万pv的并发连接数：& (pv / 86400秒 * 10个派生连接数 * 5秒内响应 * 5倍峰值) / 6台
= 19290连接数
======================================================================
空间管理 您的位置: 51testing 测试网 & migrant98的个人空间 & 日志& pv确定并发用户数上一篇 / 下一篇
17:07:11 / 个人分类：loadrunner
查看( 111 ) / 评论( 0 ) / 评分( 0 / 0 )& 面试时，面试官问道：1亿个pv，如何确定并发用户数？& 一时想不起来具体的公式，就记得80/20原则，就回答了一些。又说了一些原来我们公司会提供峰值的方法，确定最后施压的用户数。& 今天上网查相关资料，发现一些有用的内容，抄录下来。
网站流量是指什么? ip和pv呢？& 通常说的网站流量（traffic）是指网站的访问量，是用来描述访问一个网站的用户数量以及用户所浏览的网页数量等指标，常用的统计指标包括网站的独立用户数量、总用户数量（含重复访问者）、网页浏览数量、每个用户的页面浏览数量、用户在网站的平均停留时间等。
网站访问统计分析的基础是获取网站流量的基本数据，根据网上营销新观察的相关文章，网站流量统计指标大致可以分为三类，每类包含若干数量的统计指标。具体的网站流量统计是通过不同的ip登陆网站来计算的，也就是说。一天内同一台机器登陆网站的次数不论是多少，在流量统计中只记为一次有效登陆，这种计算方法可以较为 的计算出有多少人登陆过该网站，有效的防止了有意的对网站进行刷新从而增加自己网站的点击率。
网站流量指标
网站流量统计指标常用来对网站效果进行评价，主要指标包括：& &独立访问者数量（unique visitors）；& &重复访问者数量（repeat visitors）& &页面浏览数（page views）；& &每个访问者的页面浏览数（page views per user）；& &某些具体文件/页面的统计指标，如页面显示次数、文件下载次数等。
ip 是使用不同ip上网的人访问你网站的人数，也就是上面的独立访问者数量。& 一般来说是24小时同一ip不重复记录的, 也应该24小时不重复记录。（其实ip也不一定就是独立访问者数量，因为有的用户是公用一个ip的,但大致上可以认为就是今日的独立访问者数量。）
pv 则是上面的页面浏览数，是指这些访问者一共浏览了多少次你网站的页面，他是会重复记录的，你点这个网站10个页面，他就会记录10次。
所以pv一定是&=ip的，如一个网站今天的流量统计是100ip 200pv就是说今天有大致100个独立访问者，一共访问了200次页面，平均每个用户访问页面数量是 pv/ip=2 ，一般来说这个数字越大说明网站内容越吸引用户，但也和网站本身的页面有关。
吞吐量（tps)＝活动的用户数/响应时间& 活动用户＝并发用户*[响应时间/（响应时间+思考时间）]& 吞吐量（tps)=并发用户/（响应时间+思考时间）& 由此推出：& 并发用户＝活动用户+吞吐量*思考时间& 并发用户＝活动用户*（1+思考时间/响应时间）& 并发用户＝吞吐量*（响应时间+思考时间）
并发连接数与pv的换算公式& oncurrent connections＝pv / seconds *（para connect per a page) * (time to react) * (factor) / (web hosts)
pv = concurrent connections * seconds * (web hosts)/ (para connect per a page)/ (time to react)/ (factor)
concurrent connections：并发连接数
seconds: pv统计的总时间，单位秒，要计算一天的pv就是86400秒
para connect per a page: 页面衍生连接次数。一个html页面可能会请求好几次http连接，如外部的css,
,图片等。可以估算一下此文来自: 马开东博客
转载请注明出处 网址：
，或者用10。可根据实际情况改变
time to react：http响应时间，可以使用1秒或更少。可根据实际情况改变
factor：因数，一般使用5即可。可根据实际情况计算后推出
web hosts： 数量
* para connect per a page，time to react，factor这三个参数要根据实际情况分析计算后，确定一个适合的值
推算一下。单台机器1000并发的情况下，一天是1,728,000的pv(1秒响应，10个衍生连接，因子为5的情况下)
==================================================================================
术语说明：& qps = req/sec = 请求数/秒
【qps计算pv和机器的方式】
qps统计方式 [一般使用 http_load 进行统计]& qps = 总请求数 / ( 进程总数 * 请求时间 )& qps: 单个进程每秒请求服务器的成功次数
单台服务器每天pv计算& 公式1：每天总pv = qps * 3600 * 6& 公式2：每天总pv = qps * 3600 * 8
服务器计算& 服务器数量 = ceil( 每天总pv / 单台服务器每天总pv )
【峰值qps和机器计算公式】
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间& 公式：( 总pv数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(qps)& 机器：峰值时间每秒qps / 单台机器的qps = 需要的机器
问：每天300w pv 的在单台机器上，这台机器需要多少qps？& 答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps)
问：如果一台机器的qps是58，需要几台机器来支持？& 答：139 / 58 = 3
ps: 在实际情况中，会把这个考虑的更多一点，就是把qps再往多了调一调，以防万
原文：&/2012/12/pv-method/
&--------------------------------------------------------------------------------------
/5095.html
ps：下面是的主要概念和计算公式，记录下：
一．系统吞度量要素：
&&一个系统的吞度量（承压能力）与request对cpu的消耗、外部接口、io等等紧密关联。
单个reqeust&对cpu消耗越高，外部系统接口、io影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：qps（tps）、并发数、响应时间
&&&&&&&&qps（tps）：每秒钟request/事务&数量
&&&&&&&&并发数：&系统同时处理的request/事务数
&&&&&&&&响应时间：&&一般取平均响应时间
（很多人经常会把并发数和tps理解混淆）
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
qps（tps）=&并发数/平均响应时间
&&&&&&&&一个系统吞吐量通常由qps（tps）、并发数两个因素决定，每套系统这两个值都此文来自: 马开东博客
转载请注明出处 网址：
有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
决定系统响应时间要素
我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。
系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间；
关键路径是有cpu运算、io、外部系统响应等等组成。
二．系统吞吐量评估：
我们在做的时候就需要考虑cpu运算、io、外部系统响应因素造成的影响以及对系统性能的初步预估。
而通常境况下，我们面对需求，我们评估出来的出来qps、并发数之外，还有另外一个维度：日pv。
通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和qps我们就可以推算日流量。
通常的技术方法：
&&&&&&&&1.&找出系统的最高tps和日pv，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）
&&&&&&&&2.&通过压力测试或者经验预估，得出最高tps，然后跟进1的关系，计算出系统最高的日吞吐量。b2b中文和 面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的tps和pv关系比例也不一样。a)
的tps和pv之间的关系通常为&&最高tps：pv大约为&1 : 11*3600&（相当于按最高tps访问11个小时，这个是商品详情的场景，不同的应用场景会有一些不同）
b) b2b中文站
b2b的tps和pv之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1 : 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，可能是因为爬虫暂的比例较高的原因导致。
在 环境下，假设我们压力测试出的tps为100，那么这个系统的日吞吐量=100*11*万
这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。
无论有无思考时间（t_think），测试所得的tps值和并发虚拟用户数(u_concurrent)、loadrunner读取的交易响应时间（t_response）之间有以下关系（稳定运行情况下）：tps=u_concurrent / (t_response+t_think)。
并发数、qps、平均响应时间三者之间关系
来源：http://www./jackei/
的基本概念和计算公式
一、 性能的关注点
对一个 做时需要关注那些性能呢？
我们想想在 设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角此文来自: 马开东博客
转载请注明出处 网址：
色各自关注的性能点是什么，作为一个 工程师，我们又该关注什么？
首先，开发 的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。
对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个 性能的直观印象。也就是我们所说的响应时间，当相应时间较小时， 是很好的，当然 的响应时间包括个人主观因素和客观响应时间，在设计 时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。
用户关注的是用户操作的相应时间。
其次，我们站在管理员的角度考虑需要关注的性能点。
1、 相应时间2、 服务器资源使用情况是否合理3、
和 资源使用是否合理4、 系统能否实现扩展5、 系统最多支持多少用户访问、系统最大业务处理量是多少6、 系统性能可能存在的瓶颈在哪里7、 更换那些设备可以提 8、 系统能否支持7&24小时的业务访问
再次，站在开发（设计）人员角度去考虑。
1、 是否合理2、
设计是否合理3、 代码是否存在性能方面的问题4、 系统中是否有不合理的内存使用方式5、 系统中是否存在不合理的线程同步方式6、 系统中是否存在不合理的资源竞争
那么站在工程师的角度，我们要关注什么呢？
一句话，我们要关注以上所有的性能点。
二、 性能的几个主要术语
1、响应时间：对请求作出响应所需要的时间
网络传输时间：n1+n2+n3+n4
处理时间：a1+a3
服务器处理时间：a2
响应时间=n1+n2+n3+n4+a1+a3+a2
2、并发用户数的计算公式
系统用户数：系统额定的用户数量，如一个oa系统，可能使用该系统的用户总数是5000个，那么这个数量，就是系统用户数。
同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。同时在线用户数=每秒请求数rps（吞吐量）+并发连接数+平均用户思考时间
平均并发用户数的计算：c=nl / t
其中c是平均的并发用户数，n是平均每天访问用户数（login session），l是一天内用户从登录到退出的平均时间（login session的平均时间），t是考察时间长度（一天内多长时间有用户使用系统）
并发用户数峰值计算：c^约等于c + 3*根号c
其中c^是并发用户峰值，c是平均并发用户数，该公式遵循泊松分布理论。
3、吞吐量的计算公式
指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、 制约等方面的瓶颈；已请求数/秒的方式表示主要是受 和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：f=vu * r /
其中f为吞吐量，vu表示虚拟用户个数，r表示每个虚拟用户发出的请求数，t表示所用的时间
4、性能计数器
是描述服务器或性能的一些数据指标，如使用内存数、进程时间，在中发挥着&监控和分析&的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用&资源实际使用/总的资源可用量&形成资源利用率。
5、思考时间的计算公式
think time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中f=vu * r / t说明吞吐量f是vu数量、每个用户发出的请求数r和时间t的函数，而其中的r又可以用时间t和用户思考时间ts来计算：r = t / ts
下面给出一个计算思考时间的一般步骤：
a、首先计算出系统的并发用户数
c=nl / t f=r&c
b、统计出系统平均的吞吐量
f=vu * r / t r&c = vu * r / t
c、统计出平均每个用户发出的请求数量
r=u*c*t/vu
d、根据公式计算出思考时间
http://www.vpser.net/opt/webserver-test.html
一、http_load
程序非常小，解压后也不到100k
http_load以并行复用的方式运行，用以测试 的吞吐量与负载。但是它不同于大多数压力测试工
具，它可以以一个单一的进程运行，一般不会把客户机搞死。还可以测试https类的网站请求。
下载地址：http://soft.vpser.net/test/http_load/http_load-12mar2006.tar.gz 安装很简单 #tar zxvf http_load-12mar2006.tar.gz #cd http_load-12mar2006 #make && make install
命令格式：http_load& -p 并发访问进程数& -s 访问时间& 需要访问的url文件
参数其实可以自由组合，参数之间的选择并没有什么限制。比如你写成http_load -parallel 5 -seconds
300 urls.txt也是可以的。我们把参数给大家简单说明一下。 -parallel 简写-p ：含义是并发的用户进程数。 -fetches 简写-f ：含义是总计的访问次数 -rate&&& 简写-p ：含义是每秒的访问频率 -seconds简写-s ：含义是总计的访问时间
准备url文件：urllist.txt，文件格式是每行一个url，url最好超过50－100个测试效果比较好.文件格式
如下： http://www.vpser.net/uncategorized/choose-vps.html http://www.vpser.net/vps-cp/hypervm-tutorial.html http://www.vpser.net/coupons/diavps-april-coupons.html http://www.vpser.net/security/vps-backup-web-mysql.html 例如：
http_load -p 30 -s 60& urllist.txt 参数了解了，我们来看运行一条命令来看看它的返回结果 命令：% ./http_load -rate 5 -seconds 10 urls说明执行了一个持续时间10秒的测试，每秒的频率为5。
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274
fetches/sec, 28945.5 bytes/se ecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first
-response: 63.5362 mean, 81.624 max, 57.803 minhttp response codes: code 200 -- 49
结果分析： 1．49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds 说明在上面的测试中运行了49个请求，最大的并发进程数是2，总计传输的数据是289884bytes，运行的时间是10.0148秒 2．5916 mean bytes/connection说明每一连接平均传输的数据量=.89274 fetches/sec, 28945.5 bytes/sec 说明每秒的响应请求为4.89274，每秒传递的数据为28945.5 bytes/sec 4．msecs/connect: 28.8932 mean, 44.243 max, 24.488 min说明每连接的平均响应时间是28.8932 msecs
，最大的响应时间44.243 msecs，最小的响应时间24.488 msecs 5．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min 6、http response codes: code 200 -- 49&&&& 说明打开响应页面的类型，如果403的类型过多，那可能
要注意是否系统遇到了瓶颈。 特殊说明： 测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项，即服务器每秒能够响应的查询次数，
用这个指标来衡量性能。似乎比 apache的ab准确率要高一些，也更有说服力一些。 qpt-每秒响应用户数和response time，每连接响应用户时间。 测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析，我们还需要对服务器的
cpu、men进行分析，才能得出结论
二、webbench
webbench是linux下的一个网站压力测试工具，最多可以模拟3万个并发连接去测试网站的负载能力。下载
地址可以到google搜，我这里给出一个 下载地址：http://soft.vpser.net/test/webbench/webbench-1.5.tar.gz 这个程序更小，解压后不到50k，呵呵 安装非常简单 #tar zxvf webbench-1.5.tar.gz #cd webbench-1.5 #make && make install 会在当前目录生成webbench，直接可以使用了
webbench -c 并发数 -t 运行测试时间 url 如： webbench -c 5000 -t 120&http://www.vpser.net/
三、ab ab是apache自带的一款功能强大的测试工具 安装了apache一般就自带了， 用法可以查看它的说明
$ ./ab ./ab: wrong number of arguments usage: ./ab [options] [http://]hostname[:port]/path options are: -n requests number of requests to perform -c concurrency number of multiple requests to make -t timelimit seconds to max. wait for responses -p postfile file containing data to post -t content-type content-type header for posting -v verbosity how much troubleshooting info to print -w print out results in html tables -i use head instead of get -x attributes string to insert as table attributes -y attributes string to insert as tr attributes -z attributes string to insert as td or th attributes -c attribute add cookie, eg. 'apache=1234. (repeatable) -h attribute add arbitrary header line, eg. 'accept-encoding: gzip' inserted after all normal header lines. (repeatable) -a attribute add basic www authentication, the attributes are a colon separated username and pass . -p attribute add basic proxy authentication, the attributes are a colon separated username and pass . -x proxy:port proxyserver and port number to use -v print version number and exit -k use http keepalive feature -d do not show percentiles served table. -s do not show confidence estimators and warnings. -g filename output collected data to gnuplot format file. -e filename output csv file with percentages served -h display usage information (this message) 参数众多，一般我们用到的是-n 和-c 例如： ./ab -c 1000 -n 100&http://www.vpser.net/index.php
这个表示同时处理1000个请求并运行100次index.php文件. 四、siege 一款开源的压力测试工具，可以根据配置对一个web站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。 官方：http://www.joedog.org/ siege下载：http://soft.vpser.net/test/siege/siege-2.67.tar.gz 解压： # tar -zxf siege-2.67.tar.gz 进入解压目录： # cd siege-2.67/ 安装： #./ make #make install
使用 siege -c 200 -r 10 -f example.url -c是并发量，-r是重复次数。 url文件就是一个文本，每行都是一个url，它会从里面随机访问的。
example.url内容:
http://www.vpser.net http://soft.vpser.net
结果说明 lifting the server siege& done. transactions: 3419263 hits //完成419263次处理 availability: 100.00 % //100.00 % 成功率 elapsed time: 5999.69 secs //总共用时 data transferred: 84273.91 mb //共数据传输84273.91 mb response time: 0.37 secs //相应用时1.65秒：显示网络连接的速度 transaction rate: 569.91 trans/sec //均每秒完成 569.91 次处理：表示服务器后 throughput: 14.05 mb/sec //平均每秒传送数据 concurrency: 213.42 //实际最高并发数 successful transactions: 2564081 //成功处理次数 failed transactions: 11 //失败处理次数 longest transaction: 29.04 //每次传输所花最长时间 shortest transaction: 0.00 //每次传输所花最短时间
&&转载请注明出处：vps侦探&本文链接地址：http://www.vpser.net/opt/webserver-test.html
http://www.sphinxsearch.org/archives/305
在测试站点性能时找到个不错的说明式文章
from：http://blog.马开东/lyflower/archive//5873544.aspx
到/software/http_load/ 下载http_load ，安装也很简单直接make instlall 就行。
http_load 的标准的两个例子是：
http_load -parallel 5 -fetches 1000 urls.txt http_load -rate 2 -seconds 300 urls.txt 例子只是个参考，参数其实可以自由组合，参数之间的选择并没有什么限制。比如你写成http_load -parallel 5 -seconds 300 urls.txt 也是可以的。我们把参数给大家简单说明一下。 -parallel 简写 -p ： 含义是并发的用户进程数。
-fetches 简写 -f ： 含义是总计的访问次数
-rate&&& 简写 -p ： 含义是每秒的访问频率
-seconds 简写 -s ： 含义是总计的访问时间
urls.txt 是一个url 列表，每个url 单独的一行。当然也可以直接跟一个url 而不是url 列表文件。 实例：
http_load -rate 5 -seconds 10 urls 49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds 5916 mean bytes/connection 4.89274 fetches/sec, 28945.5 bytes/sec msecs/connect: 28.8932 mean, 44.243 max, 24.488 min msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min http response codes: code 200 & 49 分析： 1．49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds 说明在上面的测试中运行了49个请求，最大的并发进程数是2，总计传输的数据是289884bytes，运行的时间是10.0148秒
2．5916 mean bytes/connection 说明每一连接平均传输的数据量=5916
3．4.89274 fetches/sec, 28945.5 bytes/sec 说明每秒的响应请求为4.89274，每秒传递的数据为28945.5 bytes/sec
4．msecs/connect: 28.8932 mean, 44.243 max, 24.488 min 说明每连接的平均响应时间是28.8932 msecs，最大的响应时间44.243 msecs，最小的响应时间24.488 msecs
5．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
6、http response codes: code 200 & 49 说明打开响应页面的类型，如果403的类型过多，那可能要注意是否系统遇到了瓶颈。 特殊说明：这里，我们一般会关注到的指标是fetches/sec、msecs/connect 他们分别对应的常用性能指标参数qpt-每秒响应用户数和response time，每连接响应用户时间。测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析，我们还需要对服务器的cpu、men进行分析，才能得出结论
sample run:
% ./http_load -rate 5 -seconds 10 urls
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
http response codes:
code 200 & 49
4.89274 fetches/sec 这个值得就是说服务器每秒能够响应的查询次数为4.8左右
这个值得是根据 49 fetches /
10.0148 seconds 秒计算出来的
测试网站每秒所能承受的平均访问量 http_load -parallel 5 -fetches 1000 urls.txt
这段命令行是同时使用5个进程，随机访问urls.txt中的网址列表，总共访问1000次。运行之后的结果：
1000 fetches, 5 max parallel, 6e+06 bytes, in 58.1026 seconds 6000 mean bytes/connection 17.2109 fetches/sec , 103266 bytes/sec msecs/connect: 0.403263 mean, 68.603 max, 0.194 min msecs/first-response: 284.133 mean, 5410.13 max, 55.735 min http response codes: code 200 & 1000
从上面的运行结果来看，目此文来自: 马开东博客
转载请注明出处 网址：
标网站仅仅能够承受每秒17次访问，不够强壮。
测试网站是否能承受住预期的访问压力 http_load -rate 2 -seconds 300 urls.txt
在300秒内保持一定的频率访问目标url。
如果你需要测试https，你必须将 makefile中 # configure: if you want to compile in support for https, uncomment these # definitions.& you will need to have already built openssl, available at # http://www.openssl.org/& make sure the ssl_tree definition points to the # tree with your openssl installation & depending on how you installed it, # it may be in /usr/local instead of /usr/local/ssl. ssl_tree =&&& /usr ssl_defs =&&& -duse_ssl ssl_inc =&&& -i$(ssl_tree)/include ssl_libs =&&& -l$(ssl_tree)/lib -lssl -lcrypto
由于使用到openssl，你必须安装openssl和相应的开发环境
apt-get install openssl apt-get install libssl-dev
find -name ssl.h /usr /include/openssl/ssl.h
所以上面红色字体部分必须修改
http_load常见问题 平常使用http_load过程中的一些总结，分享出来，大家可以一起补充；
1.提示：bytes count wrong 如果httpd_load获取到的页面数据和上次不一致则会报错byte count wrong 如果是动态页面,此报错可以忽略；
2.报错：too many open files 系统限制的open files太小，ulimit -n 修改open files值即可；
3.无法发送大请求 （请求长度&600个字符） 默认接受请求的buf大小 http_load.c
912 static void 913 handle_connect( int cnum, struct timeval* nowp, int double_check ) 914 { 915 int url_ 916 char buf[600]; //根据需要修改，如：char buf[ int bytes,
重新编译即可得到可发送大请求
4.cannot assign requested address 客户端频繁的连服务器，由于每次连接都在很短的时间内结束，导致很多的time_wait，以至于用光了可用的端口号，所以新的连接没办法绑定端口，所以要改客户端机器的配置， 在sysctl.conf里加：
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将time-wait sockets重新用于新的tcp连接，默认为0，表示关闭； net.ipv4.tcp_timestamps=1 开启对于tcp时间戳的支持,若该项设置为0，则下面一项设置 不起作用 net.ipv4.tcp_tw_recycle=1 表示开启tcp连接中time-wait sockets的快速回收 apache ab压力测试
以前安装好apache总是不知道该如何测试apache的性能，现在总算找到一个测试工具了。就是apache自带的测试工具ab(apache benchmark).在apache的bin目录下。
格式： ./ab [options] [http://]hostname[:port]/path 参数： -n requests&&&& number of requests to perform //在测试会话中所执行的请求个数。默认时，仅执行一个请求 -c concurrency number of multiple requests to make //一次产生的请求个数。默认是一次一个。 -t timelimit&&& seconds to max. wait for responses //测试所进行的最大秒数。其内部隐含值是-n 50000。它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。 -p postfile&&&& file containing data to post //包含了需要post的数据的文件. -t content-type content-type header for posting //post数据所使用的content-type头信息。 -v verbosity&&& how much troubleshooting info to print //设置显示信息的详细程度 & 4或更大值会显示头信息， 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。 -v 显示版本号并退出。 -w&&&&&&&&&&&&& print out results in html tables //以html表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。 -i&&&&&&&&&&&&& use head instead of get // 执行head请求，而不是get。 -x attributes&& string to insert as table attributes // -y attributes&& string to insert as tr attributes // -z attributes&& string to insert as td or th attributes // -c attribute&&& add cookie, eg. &apache=1234. (repeatable) //-c cookie-name=value 对请求附加一个cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复。 -h attribute&&& add arbitrary header line, eg. &accept-encoding: gzip& inserted after all normal header lines. (repeatable) -a attribute&&& add basic www authentication, the attributes are a colon separated username and pass . -p attribute&&& add basic proxy authentication, the attributes are a colon separated username and pass . //-p proxy-auth-username:pass
对一个中转代理提供basic认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。 -x proxy:port&& proxyserver and port number to use -v&&&&&&&&&&&&& print version number and exit -k&&&&&&&&&&&&& use http keepalive feature -d&&&&&&&&&&&&& do not show percentiles served table. -s&&&&&&&&&&&&& do not show confidence estimators and warnings. -g filename&&&& output collected data to gnuplot format file. -e filename&&&& output csv file with percentages served -h&&&&&&&&&&&&& display usage information (this message) //-attributes 设置 属性的字符串. 缺陷程序中有各种静态声明的固定长度的缓冲区。另外，对命令行参数、服务器的响应头和其他外部输入的解析也很简单，这可能会有不良后果。它没有完整地实现 http/1.x; 仅接受某些&预想&的响应格式。 strstr(3)的频繁使用可能会带来性能问题，即, 你可能是在测试ab而不是服务器的性能。
参数很多,一般我们用 -c 和 -n 参数就可以了. 例如:
./ab -c 1000 -n 1000 http://127.0.0.1/index.php
这个表示同时处理1000个请求并运行1000次index.php文件. #/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312 this is apachebench, version 2.0.41-dev &$revision: 1.121.2.12 $& apache-2.0 copyright (c) 1996 adam twiss, zeus technology ltd, http://www.zeustech.net/ copyright (c)
the apache software foundation, http://www.apache.org/
benchmarking 127.0.0.1 (be patient) completed 100 requests completed 200 requests completed 300 requests completed 400 requests completed 500 requests completed 600 requests completed 700 requests completed 800 requests completed 900 requests finished 1000 requests
server software:&&&&&&& apache/2.0.54 // 平台apache 版本2.0.54 server hostname:&&&&&&& 127.0.0.1 //服务器主机名 server port:&&&&&&&&&&& 80 //服务器端口
document path:&&&&&&&&& /index.html.zh-cn.gb2312 //测试的页面文档 document length:&&&&&&& 1018 bytes //文档大小
concurrency level:&&&&& 1000 //并发数 time taken for tests:&& 8.188731 seconds //整个测试持续的时间 complete requests:&&&&& 1000 //完成的请求数量 failed requests:&&&&&&& 0 //失败的请求数量 write errors:&&&&&&&&&& 0
total transferred:&&&&& 1361581 bytes //整个场景中的网络传输量 html transferred:&&&&&& 1055666 bytes //整个场景中的html内容传输量 requests per second:&&& 122.12 [#/sec] (mean) //大家最关心的指标之一，相当于 lr 中的 每秒事务数 ，后面括号中的 mean 表示这是一个平均值 time per request:&&&&&&
[ms] (mean) //大家最关心的指标之二，相当于 lr 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值 time per request:&&&&&& 8.189 [ms] (mean, across all concurrent requests) //每个请求实际运行时间的平均值 transfer rate:&&&&&&&&& 162.30 [kbytes/sec] received //平均每秒网络上的流量，可以帮助排除是否存在过大导致响应时间延长的问题
connection times (ms) min mean[+/-sd] median&& max connect:&&&&&&& 4 646 1078.7&&&& 89&&& 3291 processing:&& 165 992 493.1&&& 938&&& 4712 waiting:&&&&& 118 934 480.6&&& 882&&& 4554 total:&&&&&&& 813 && 1093&&& 7785 //网络上消耗的时间的分解，各项数据的具体算法还不是很清楚
percentage of the requests served within a certain time (ms) 50%&& 1093 66%&& 1247 75%&& 1373 80%&& 1493 90%&& 4061 95%&& 4398 98%&& 5608 99%&& %&& 7785 (longest request) //整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093 毫秒，60％ 的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒
由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个time per request时间约等于第二个time per request时间乘以并发请求数
1)、简介 一款开源的压力测试工具，可以根据配置对一个web站点进行多用户的并发访问，记录每个用户所有请求过 程的相应时间，并在一定数量的并发访问下重复进行。
http://www.joedog.org/
3)、安装 [root@localhost software]# tar -zxvf siege-2.69.tar.gz&& #解压 [root@localhost software]# cd siege-2.69 [root@localhost siege-2.69]# ./configure &prefix=/usr/local/siege #配置安装目录 [root@localhost siege-2.69]# make && make install&&& #编译安装
注意：安装是会提示一下错误， make[3]: entering directory `/usr/local/software/siege-2.69/doc& /usr/bin/install: cannot create regular file `/usr/local/siege/etc/siegerc&: no such file or directory make[3]: *** [install-exec-hook] error 1 make[3]: leaving directory `/usr/local/software/siege-2.69/doc& make[2]: *** [install-exec-am] error 2 make[2]: leaving directory `/usr/local/software/siege-2.69/doc& make[1]: *** [install-am] error 2 make[1]: leaving directory `/usr/local/software/siege-2.69/doc& make: *** [install-recursive] error 1 解决办法是：mkdir -p /usr/local/siege/etc/siegerc 建立这样一个目录就可以继续向下安装的。
命令格式：siege -c 并发量 -r 重复次数 -f urllist文件 urllist格式：
结果说明： lifting the server siege& done. transactions: 3419263 hits //完成419263次处理 availability: 100.00 % //100.00 % 成功率 elapsed time: 5999.69 secs //总共用时 data transferred: 84273.91 mb //共数据传输84273.91 mb response time: 0.37 secs //相应用时1.65秒：显示网络连接的速度 transaction rate: 569.91 trans/sec //均每秒完成 569.91 次处理：表示服务器后 throughput: 14.05 mb/sec //平均每秒传送数据 concurrency: 213.42 //实际最高并发数 successful transactions: 2564081 //成功处理次数 failed transactions: 11 //失败处理次数 longest transaction: 29.04 //每次传输所花最长时间 shortest transaction: 0.00 //每次传输所花最短时间
本文来自 博客，转载请标明出处：http://blog.马开东/lyflower/archive//5873544.aspx
&/4617.html
ps：网站性能压力测试是性能调优过程中必不可少的一环。只有让服务器处在高压情况下才能真正体现出各种设置所暴露的问题。apache中有个自带的，名为ab的程序，可以对apache或其它类型的服务器进行网站访问压力测试。
apachebench命令原理：
ab命令会创建很多的并发访问线程，模拟多个访问者同时对某一url地址进行访问。它的测试目标是基于url的，因此，既可以用来测试apache的负载压力，也可以测试nginx、lighthttp、tomcat、iis等其它 的压力。
ab命令对发出负载的计算机要求很低，既不会占用很高cpu，也不会占用很多内存，但却会给目标服务器造成巨大的负载，其原理类似cc攻击。自己测试使用也须注意，否则一次上太多的负载，可能造成目标服务器因资源耗完，严重时甚至导致死机。
apachebench参数说明
格式：ab [options] [http://]hostname[:port]/path参数说明：-n requests number of requests to perform//在测试会话中所执行的请求个数（本次测试总共要访问页面的次数）。默认时，仅执行一个请求。-c concurrency number of multiple requests to make//一次产生的请求个数（并发数）。默认是一次一个。-t timelimit seconds to max. wait for responses//测试所进行的最大秒数。其内部隐含值是-n 50000。它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。-p postfile file containing data to post//包含了需要post的数据的文件，文件格式如&p1=1&p2=2&.使用方法是 -p 111.txt 。 （配合-t）-t content-type content-type header for posting//post数据所使用的content-type头信息，如 -t &application/x-www-form-urlencoded& 。 （配合-p）-v verbosity how much troubleshooting info to print//设置显示信息的详细程度 & 4或更大值会显示头信息， 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。 -v 显示版本号并退出。-w print out results in html&tables//以html表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。-i use head instead of get// 执行head请求，而不是get。-x attributes string to insert as table attributes-y attributes string to insert as tr attributes-z attributes string to insert as td or th attributes-c attribute add cookie, eg. -c &c1=,c3=3& (repeatable)//-c cookie-name=value 对请求附加一个cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复，用逗号分割。提示：可以借助session实现原理传递
essionid参数， 实现保持会话的功能，如-c & c1=,c3=3,
essionid=ff056cd16da9d71cb131c1d56f0319f8& 。-h attribute add arbitrary header line, eg. &accept-encoding: gzip& inserted after all normal header lines. (repeatable)-a attribute add basic www authentication, the attributesare a colon separated username and pass .-p attribute add basic proxy authentication, the attributesare a colon separated username and pass .//-p proxy-auth-username:pass
对一个中转代理提供basic认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。-x proxy:port proxyserver and port number to use-v print version number and exit-k use http keepalive feature-d do not show percentiles served table.-s do not show confidence estimators and warnings.-g filename output collected data to gnuplot format file.-e filename output csv file with percentages served-h display usage information (this message)//-attributes 设置属性的字符串. 缺陷程序中有各种静态声明的固定长度的缓冲区。另外，对命令行参数、服务器的响应头和其他外部输入的解析也很简单，这可能会有不良后果。它没有完整地实现 http/1.x; 仅接受某些&预想&的响应格式。 strstr(3)的频繁使用可能会带来性能问题，即你可能是在测试ab而不是服务器的性能。
参数很多，一般我们用 -c 和 -n 参数就可以了。例如:
# ab -c 5000 -n 600 http://127.0.0.1/index.php
apachebench用法详解：
在linux系统，一般安装好apache后可以直接执行；# ab -n 4000 -c 1000 /
如果是win系统下，打开cmd命令行窗口，cd到apache安装目录的bin目录下；
-n后面的4000代表总共发出4000个请求；-c后面的1000表示采用1000个并发（模拟1000个人同时访问），后面的网址表示测试的目标url。
稍等一会得到类似如下显示结果：
结果分析：
this is apachebench, version 2.3copyright 1996 adam twiss, zeus technology ltd, http://www.zeustech.net/licensed to the apache software foundation, http://www.apache.org/
benchmarking 192.168.80.157 (be patient)completed 400 requestscompleted 800 requestscompleted 1200 requestscompleted 1600 requestscompleted 2000 requestscompleted 2400 requestscompleted 2800 requestscompleted 3200 requestscompleted 3600 requestscompleted 4000 requestsfinished 4000 requests
server&software: apache/2.2.15server hostname: 192.168.80.157server port: 80
document path: /phpinfo.php#测试的页面document length: 50797 bytes#页面大小
concurrency level: 1000#测试的并发数time taken for tests: 11.846 seconds#整个测试持续的时间complete requests: 4000#完成的请求数量failed requests: 0#失败的请求数量write errors: 0total transferred:
bytes#整个过程中的网络传输量html transferred:
bytes#整个过程中的html内容传输量requests per second: 337.67 [#/sec] (mean)#最重要的指标之一，相当于lr中的每秒事务数，后面括号中的mean表示这是一个平均值time per request:
[ms] (mean)#最重要的指标之二，相当于lr中的平均事务响应时间，后面括号中的mean表示这是一个平均值time per request: 2.961 [ms] (mean, across all concurrent requests)#每个连接请求实际运行时间的平均值transfer rate: 16866.07 [kbytes/sec] received#平均每秒网络上的流量，可以帮助排除是否存在过大导致响应时间延长的问题connection times (ms)min mean[+/-sd] median maxconnect: 0 483
9052processing: 2 556
11763waiting: 1 515
11756total: 139
275 11843#网络上消耗的时间的分解，各项数据的具体算法还不是很清楚
percentage of the requests served within a certain time (ms)50% 27566% 29875% 32880% 37390% 326095% 907598% 926799% 11713100% 11843 (longest request)#整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于275毫秒，66％的用户响应时间小于298毫秒，最大的响应时间小于11843毫秒。对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个time per request时间约等于第二个time per request时间乘以并发请求数。
总结：在远程对 进行压力测试，往往效果不理想（因为网络延时过大），建议使用内网的另一台或者多台服务器通过内网进行测试，这样得出的数据，准确度会高很多。如果只有单独的一台服务器，可以直接本地测试，比远程测试效果要准确。
############################################################
http://www.blogjava.net/neverend/archive//343514.html
术语说明： qps = req/sec = 请求数/秒
【qps计算pv和机器的方式】
qps统计方式 [一般使用 http_load 进行统计] qps = 总请求数 / ( 进程总数 *&& 请求时间 ) qps: 单个进程每秒请求服务器的成功次数
单台服务器每天pv计算 公式1：每天总pv = qps * 3600 * 6 公式2：每天总pv = qps * 3600 * 8
服务器计算 服务器数量 =&& ceil( 每天总pv / 单台服务器每天总pv )
【峰值qps和机器计算公式】
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间 公式：( 总pv数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(qps) 机器：峰值时间每秒qps / 单台机器的qps&& = 需要的机器
问：每天300w pv 的在单台机器上，这台机器需要多少qps？ 答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps)
问：如果一台机器的qps是58，需要几台机器来支持？ 答：139 / 58 = 3
http://blog./?tag=web-%e6%80%a7%e8%83%bd-qps-%e7%ad%89%e5%be%85%e6%97%b6%e9%97%b4/blog/703864
&##########################################################################
http://www./yjf512/archive//2974842.html
文件服务器
web页面开发
再考虑到非功能配套：
&=================================================
http://ruby-china.org/topics/7075
工具用http_load，在公司的服务器上做的测试，我这边的带宽不是问题
我在云服务器上的rails应用，nginx+passenger $ http_load -p 5 -s 10 urls 175 fetches, 5 max parallel, 1.48505e+06 bytes, in 10 seconds 8486 mean bytes/connection 17.5 fetches/sec, 148505 bytes/sec msecs/connect:&11.7533 mean, 100.123 max, 1.872 min msecs/first-response: 253.544 mean, 1797.26 max, 50.015 min http response codes: code 200 -- 175
$ http_load -p 30 -s 10 urls 255 fetches, 30 max parallel, 2.16393e+06 bytes, in 10 seconds 8486 mean bytes/connection 25.5 fetches/sec, 216393 bytes/sec msecs/connect:&231.678 mean, 450.523 max, 1.917 min msecs/first-response: 595.631 mean, 2215.58 max, 142.245 min http response codes: code 200 -- 255
$ http_load -p 30 -s 30 urls 784 fetches, 30 max parallel, 6.65302e+06 bytes, in 30 seconds 8486 mean bytes/connection 26.1333 fetches/sec, 221767 bytes/sec msecs/connect:&310.235 mean, 450.555 max, 2.066 min msecs/first-response: 481.559 mean, 1282.8 max, 133.443 min http response codes: code 200 -- 784
$ http_load -p 50 -s 30 urls 780 fetches, 50 max parallel, 6.61908e+06 bytes, in 30 seconds 8486 mean bytes/connection 26 fetches/sec, 220636 bytes/sec msecs/connect:&518.74 mean, 750.023 max, 2.041 min msecs/first-response: 779.266 mean, 1890.49 max, 142.368 min http response codes: code 200 -- 780
qps到26就上不去了，latency在不断变大 同时也测试了ruby-china和codecampo也是这样的
&===========================================
http://studiogang./852
我们知道压力测试的 确实很多，诸如微软的wast，惠普的loadrunner以及等等其他的，但这些 学习起来还是需要花费些时间，在选择上实在头痛，后来在郭欣的那本《构建 web站点》上看到了他介绍的这款apache自带的压力测试工具ab，十分喜爱，于是今天终于有机会体验下ab对网站的压力测试。
&&& 实验之前我的apache已经安装了，：ubuntu 10.04 vmware 7.0
1、先查看一下版本信息 ab -v（注意是大写的v）
studiogang@studiogang:~$&ab&-v &
this&is&apachebench,&version&2.3&&$revision:&655654&$& &
copyright&1996&adam&twiss,&zeus&technology&ltd,&http://www.zeustech.net/ &
licensed&to&the&apache&software&foundation,&http://www.apache.org/ &
&2、我们也可以使用小写的v查看下ab命令的一些属性 ab -v
studiogang@studiogang:~$&ab&-v &
ab:&option&requires&an&argument&--&v &
ab:&wrong&number&of&arguments &
usage:&ab&[options]&[http[s]://]hostname[:port]/path &
options&are: &
&&&&-n&requests&&&&&number&of&requests&to&perform &
&&&&-c&concurrency&&number&of&multiple&requests&to&make &
&&&&-t&timelimit&&&&seconds&to&max.&wait&for&responses &
&&&&-b&windowsize&&&size&of&tcp&send/receive&buffer,&in&bytes &
&&&&-p&postfile&&&&&file&containing&data&to&post.&remember&also&to&set&-t &
&&&&-u&putfile&&&&&&file&containing&data&to&put.&remember&also&to&set&-t &
&&&&-t&content-type&content-type&header&for&posting,&eg. &
&&&&&&&&&&&&&&&&&&&&'application/x-www-form-urlencoded' &
&&&&&&&&&&&&&&&&&&&&default&is&'text/plain' &
&&&&-v&verbosity&&&&how&much&troubleshooting&info&to&print &
&&&&-w&&&&&&&&&&&&&&print&out&results&in&html&tables &
&&&&-i&&&&&&&&&&&&&&use&head&instead&of&get &
&&&&-x&attributes&&&string&to&insert&as&table&attributes &
&&&&-y&attributes&&&string&to&insert&as&tr&attributes &
&&&&-z&attributes&&&string&to&insert&as&td&or&th&attributes &
&&&&-c&attribute&&&&add&cookie,&eg.&'apache=1234.&(repeatable) &
&&&&-h&attribute&&&&add&arbitrary&header&line,&eg.&'accept-encoding:&gzip' &
&&&&&&&&&&&&&&&&&&&&inserted&after&all&normal&header&lines.&(repeatable) &
&&&&-a&attribute&&&&add&basic&www&authentication,&the&attributes &
&&&&&&&&&&&&&&&&&&&&are&a&colon&separated&username&and&pass . &
&&&&-p&attribute&&&&add&basic&proxy&authentication,&the&attributes &
&&&&&&&&&&&&&&&&&&&&are&a&colon&separated&username&and&pass . &
&&&&-x&proxy:port&&&proxyserver&and&port&number&to&use &
&&&&-v&&&&&&&&&&&&&&print&version&number&and&exit &
&&&&-k&&&&&&&&&&&&&&use&http&keepalive&feature &
&&&&-d&&&&&&&&&&&&&&do&not&show&percentiles&served&table. &
&&&&-s&&&&&&&&&&&&&&do&not&show&confidence&estimators&and&warnings. &
&&&&-g&filename&&&&&output&collected&data&to&gnuplot&format&file. &
&&&&-e&filename&&&&&output&csv&file&with&percentages&served &
&&&&-r&&&&&&&&&&&&&&don't&exit&on&socket&receive&errors. &
&&&&-h&&&&&&&&&&&&&&display&usage&information&(this&message) &
&&&&-z&ciphersuite&&specify&ssl/tls&cipher&suite&(see&openssl&ciphers) &
&&&&-f&protocol&&&&&specify&ssl/tls&protocol&(ssl2,&ssl3,&tls1,&or&all) &
3、现在我们就对51cto的网站进行一次压力测试吧，使用命令ab&-n1000&-c10&http://www.51<//index.php，其中 -n1000 表示总请求数 -c10表示并发用户数为10&http://www.51<//index.php&表示请求的url，下面是测试的结果，其中我们最关心的三个指标，我已经注释出来了。
studiogang@studiogang:~$&ab&-n1000&-c10&http://www.51<//index.php &
this&is&apachebench,&version&2.3&&$revision:&655654&$& &
copyright&1996&adam&twiss,&zeus&technology&ltd,&http://www.zeustech.net/ &
licensed&to&the&apache&software&foundation,&http://www.apache.org/ &
benchmarking&www.51&(be&patient) &
completed&100&requests &
completed&200&requests &
completed&300&requests &
completed&400&requests &
completed&500&requests &
completed&600&requests &
completed&700&requests &
completed&800&requests &
completed&900&requests &
completed&1000&requests &
finished&1000&requests &
&/* 用的是nginx*/
server&software:&&&&&&&&nginx &
server&hostname:&&&&&&&&www.51 &
server&port:&&&&&&&&&&&&80&
document&path:&&&&&&&&&&/index.php &
document&length:&&&&&&&&154&bytes &
concurrency&level:&&&&&&10&
time&taken&for&tests:&&&74.373&seconds &
complete&requests:&&&&&&1000&
failed&requests:&&&&&&&&0&
write&errors:&&&&&&&&&&&0&
non-2xx&responses:&&&&&&1000&
total&transferred:&&&&&&330000&bytes &
html&transferred:&&&&&&&154000&bytes
/*大家最关心的指标之一，指的是吞吐率
相当于 lr 中的&每秒事务数&，后面括号中的 mean 表示这是一个平均值*/ &
requests&per&second:&&&&13.45&[#/sec]&(mean)
/*大家最关心的指标之二，指的是用户平均请求等待时间
相当于 lr 中的&平均事务响应时间&，后面括号中的 mean 表示这是一个平均值*/&
time&per&request:&&&&&&&743.726&[ms]&(mean)
/*大家最关心的指标之三，指的是服务器平均请求处理时间
time&per&request:&&&&&&&74.373&[ms]&(mean,&across&all&concurrent&requests) &
transfer&rate:&&&&&&&&&&4.33&[kbytes/sec]&received &
connection&times&(ms) &
&&&&&&&&&&&&&&min&&mean[+/-sd]&median&&&max &
connect:&&&&&&129&&163&245.3&&&&145&&&&3154&
processing:&&&129&&576&1510.8&&&&147&&&11756&
waiting:&&&&&&129&&567&1502.0&&&&147&&&11756&
total:&&&&&&&&261&&739&1543.7&&&&294&&&11888&
percentage&of&the&requests&served&within&a&certain&time&(ms) &
&&50%&&&&294&
&&66%&&&&297&
&&75%&&&&304&
&&80%&&&&308&
&&90%&&&1290&
&&95%&&&3452&
&&98%&&&7582&
&&99%&&&7962&
&100%&&11888&(longest&request) &
4、为了使结果更有对比性，我们将并发用户更改为100个进行压力测试，我这里只将三个指标贴出来。
requests&per&second:&&&&190.95&[#/sec]&(mean) &
time&per&request:&&&&&&&523.694&[ms]&(mean) &
time&per&request:&&&&&&&5.237&[ms]&(mean,&across&all&concurrent&requests) &
5、将并发用户改为200个进行测试
requests&per&second:&&&&186.00&[#/sec]&(mean) &
time&per&request:&&&&&&&&[ms]&(mean) &
time&per&request:&&&&&&&5.747&[ms]&(mean,&across&all&concurrent&requests) &
6、500个并发用户时的情况
requests&per&second:&&&&180.99&[#/sec]&(mean) &
time&per&request:&&&&&&&&[ms]&(mean) &
time&per&request:&&&&&&&5.263&[ms]&(mean,&across&all&concurrent&requests) &
&&&& 我们来分析下测试的结果，先对比下吞吐率，当并发用户的时候吞吐率最高为190 reqs/s,当并发用户数为200,500 吞吐率下降了，随之用户的等待时间更是明显增加了，已经有2s的等待时间了。这说明性能明显下降了。当然分析这个测试结果并不是说明51cto的网站的并发用户只能在500左右，因为我是在服务器负荷的情况下就行测试的，这显然不能说明问题。另外我们在生产环境下测试的时候，最好能将测试结果做成 ，这样可以非常清晰地对比出问题来，好了，我该准备下，给上面提交一份我们公司网站的测试报告了。
本文出自 &studiogang's blog& 博客，请务必保留此出处http://studiogang./852
<p style="font: 15px/1.5 margin: 1.2em 0 padding: 0 text-align: color: #002200; text-transform: text-indent: 0 letter-spacing: word-spa搜索此文相关文章：此文来自: 马开东博客
网址: 站长QQ
ab,qps,服务器性能压力_博客园相关文章
博客园_总排行榜
博客园_最新
博客园_月排行榜
博客园_周排行榜
博客园_日排行榜}