标签：
"ab,qps,服务器性能压力"：关键词：ab qps 服务器 性能 压力
http://www.makaidong.com/program/641799.html
转载：并发用户数和qps两个概念没有直接关系
转自: http://blog.hummingbird-one.com/?p=10029
关
于并发用户数和qps，自己一直被这两个概念纠结，阅读了一下相关资料，总结如下：并发用户数和qps两个概念没有直接关系，但是如果要说qps时，一定
需要指明是多少并发用户数下的qps，否则豪无意义，因为单用户数的40qps和20并发用户数下的40qps是两个不同的概念。前者说明该应用可以在一
秒内串行执行40个请求，而后者说明在并发20个请求的情况下，一秒内该应用能处理40个请求
http://www.tuicool.com/articles/zbafyf
并发连接数 = pv / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 / 其他web服务器 数量
pv = 并发连接数 * 统计时间 * 其他web服务器 数量/ 页面衍生连接次数 / http响应时间 / 因数
解释： 统计时间 : pv统计的总时间，单位秒，要计算一天的pv就是86400秒 页面衍生连接次数: 一个html页面可能会请求好几次http连接，如外部的css, js ,图片等,可以估算一下，或者用10,可根据实际情况改变 http响应时间: 可以使用1秒或更少,可根据实际情况改变 因数: 一般使用5即可,可根据实际情况计算后推出 其他web服务器 数量: 其他web服务器 数量
* “页面衍生连接次数”，”http响应时间”，”因数”这三个参数要根据实际情况分析计算后，确定一个适合的值
推算一下。单台机器1000并发的情况下，一天是1,728,000的pv(1秒响应，10个衍生连接，因子为5的情况下) ======================================================================
例子：
保证每天多少pv的并发连接数的计算公式是： 并发连接数＝ pv / 统计时间(一天是86400) * 页面衍生连接次数 * http响应时间 * 因数(5) / 其他web服务器 数量
保证4千万pv的并发连接数： (40000000pv / 86400秒 * 10个派生连接数 * 5秒内响应 * 5倍峰值) / 6台其他web服务器 = 19290连接数
======================================================================
面试时，面试官问道：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, js ,图片等。可以估算一下
，或者用10。可根据实际情况改变
time to react：http响应时间，可以使用1秒或更少。可根据实际情况改变
factor：因数，一般使用5即可。可根据实际情况计算后推出
web hosts：其他web服务器 数量
* 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再往多了调一调，以防万
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*3600=396万
这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。
无论有无思考时间（t_think），测试所得的tps值和并发虚拟用户数(u_concurrent)、loadrunner读取的交易响应时间（t_response）之间有以下关系（稳定运行情况下）：
tps=u_concurrent / (t_response+t_think)。
并发数、qps、平均响应时间三者之间关系
来源：http://www.makaidong.com/jackei/
一、软件其他 性能的关注点
我们想想在软件其他 设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角
此文来自: 马开东博客 转载请注明出处 网址： http://www.makaidong.com
色各自关注的性能点是什么，作为一个软件其他 性能测试工程师，我们又该关注什么？
首先，开发软件其他 的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。
对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件其他 性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验 是很好的，当然用户体验 的响应时间包括个人主观因素和客观响应时间，在设计软件其他 时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。
用户关注的是用户操作的相应时间。
其次，我们站在管理员的角度考虑需要关注的性能点。
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、根据公式计算出思考时间
ts=t/r
http://www.vpser.net/opt/webserver-test.html
一、http_load
程序非常小，解压后也不到100k
http_load以并行复用的方式运行，用以测试其他web服务器 的吞吐量与负载。但是它不同于大多数压力测试工
具，它可以以一个单一的进程运行，一般不会把客户机搞死。还可以测试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/secms 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说明每一连接平均传输的数据量289884/49=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 这个选项，即服务器每秒能够响应的查询次数，
用这个指标来衡量性能。似乎比 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 password . -p attribute add basic proxy authentication, the attributes are a colon separated username and password . -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/ 安装： #./configure ; make #make install
使用 siege -c 200 -r 10 -f example.url -c是并发量，-r是重复次数。 url文件就是一个文本，每行都是一个url，它会从里面随机访问的。
example.url内容:
http://www.licess.cn 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/2010/09/09/5873544.aspx
到http://www.acme.com/software/http_load/ 下载http_load ，安装也很简单直接make;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 说明每一连接平均传输的数据量289884/49=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
从上面的运行结果来看，目
此文来自: 马开东博客 转载请注明出处 网址： http://www.makaidong.com
标网站仅仅能够承受每秒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_num; 916 char buf[600]; //根据需要修改，如：char buf[4096] 917 int bytes, r;
重新编译即可得到可发送大请求
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 password . -p attribute add basic proxy authentication, the attributes are a colon separated username and password . //-p proxy-auth-username:password 对一个中转代理提供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) 1998-2002 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: 8188.731 [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 1638 1338.9 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% 7368 100% 7785 (longest request) //整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093 毫秒，60％ 的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒
由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个time per request时间约等于第二个time per request时间乘以并发请求数
3、siege
1)、简介 一款开源的压力测试工具，可以根据配置对一个web站点进行多用户的并发访问，记录每个用户所有请求过 程的相应时间，并在一定数量的并发访问下重复进行。
2)、获取
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 建立这样一个目录就可以继续向下安装的。
4)、使用
命令格式：siege -c 并发量 -r 重复次数 -f urllist文件 urllist格式：
http://www.taoav.com
http://www.tuhaoduo.com
http://www.tiaonv.com
结 果说明： 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 //每次传输所花最短时间
本文来自CSDN 博客，转载请标明出处：http://blog.马开东/lyflower/archive/2010/09/09/5873544.aspx
http://www.ha97.com/4617.html
ps：网站性能压力测试是性能调优过程中必不可少的一环。只有让服务器处在高压情况下才能真正体现出各种设置所暴露的问题。apache中有个自带的，名为ab的程序，可以对apache或其它类型的服务器进行网站访问压力测试。
apachebench命令原理：
ab命令会创建很多的并发访问线程，模拟多个访问者同时对某一url地址进行访问。它的测试目标是基于url的，因此，既可以用来测试apache的负载压力，也可以测试nginx、lighthttp、tomcat、iis等其它其他web服务器 的压力。
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=1234,c2=2,c3=3′ (repeatable)
//-c cookie-name=value 对请求附加一个cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复，用逗号分割。
提示：可以借助session实现原理传递 js essionid参数， 实现保持会话的功能，如
-c ” c1=1234,c2=2,c3=3, js 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 attributes
are a colon separated username and password .
-p attribute add basic proxy authentication, the attributes
are a colon separated username and password .
//-p proxy-auth-username:password 对一个中转代理提供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 http://www.ha97.com/
如果是win系统下，打开cmd命令行窗口，cd到apache安装目录的bin目录下；
-n后面的4000代表总共发出4000个请求；-c后面的1000表示采用1000个并发（模拟1000个人同时访问），后面的网址表示测试的目标url。
稍等一会得到类似如下显示结果：
结果分析：
this is apachebench, version 2.3
copyright 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 requests
completed 800 requests
completed 1200 requests
completed 1600 requests
completed 2000 requests
completed 2400 requests
completed 2800 requests
completed 3200 requests
completed 3600 requests
completed 4000 requests
finished 4000 requestsserver software: apache/2.2.15
server hostname: 192.168.80.157
server port: 80document 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: 0
total transferred: 204586997 bytes
#整个过程中的网络传输量
html transferred: 203479961 bytes
#整个过程中的html内容传输量
requests per second: 337.67 [#/sec] (mean)
#最重要的指标之一，相当于lr中的每秒事务数，后面括号中的mean表示这是一个平均值
time per request: 2961.449 [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 max
connect: 0 483 1773.5 11 9052
processing: 2 556 1459.1 255 11763
waiting: 1 515 1459.8 220 11756
total: 139 1039 2296.6 275 11843
#网络上消耗的时间的分解，各项数据的具体算法还不是很清楚percentage of the requests served within a certain time (ms)
50% 275
66% 298
75% 328
80% 373
90% 3260
95% 9075
98% 9267
99% 11713
100% 11843 (longest request)
# 整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于275毫秒，66％的用户响应时间小于298毫秒，最大 的响应时间小于11843毫秒。对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个time per request时间约等于第二个time per request时间乘以并发请求数。
总结：在远程对其他web服务器 进行压力测试，往往效果不理想（因为网络延时过大），建议使用内网的另一台或者多台服务器通过内网进行测试，这样得出的数据，准确度会高很多。如果只有单独的一台服务器，可以直接本地测试，比远程测试效果要准确。
############################################################
http://www.blogjava.net/neverend/archive/2011/01/25/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.hummingbird-one.com/?tag=web-%e6%80%a7%e8%83%bd-qps-%e7%ad%89%e5%be%85%e6%97%b6%e9%97%b4
http://jjw.javaeye.com/blog/703864
##########################################################################
http://www.makaidong.com/yjf512/archive/2013/03/22/2974842.html
从事服务端开发已经有一些日子了，静下来可以想想和记录些服务端开发的想法了。
服 务端开发，特别是web开发，基本上全是处理http请求的处理。根据具体用途分为两种：web页面开发和api接口开发。web页面开发也完全可以看成 是api接口开发，只是它的两个主要部分，页面和ajax请求，一个是返回html，另外一个可以返回html，也可以返回其他格式的而已。api接口开 发是针对有客户端产品而言的。可能是移动设备，可能是pc应用等。
应用框架一般使用的是lnmp或者lamp，基本的框架就是前端n台web服务机 + cgi访问php + php访问mysql。
php可以看成是c写的一个大型的web框架，它的优势在于解释型，即时修改即时更新。所以线上代码更新维护成本极低，加之其为web开发几乎是专门定制的一些函数，所以适合用于web开发。相较于java开发web服务，动不动就需要重新编译的痛苦就很知足了。
其他web服务器 现在nginx是越来越多使用，nginx比较apache的优势就在于轻便和静态页面的高并发性能。一般拿到设备先需要考虑下单机可承受的qps大概多 少，方法大致就是先只考虑内存，计算同时能开启多少个php-cgi，比如一个4g内存的机器，每个php-fpm大概占用20m内存，所以差不多能开启 200个php-cgi进程（一般会留些空余的），每个进程同一个时间只能跑一个php程序，所以假设每个php程序跑0.1s，1s就能处理10个请 求，所以单机qps大概会是2000。当然，一般不会开启到这么极致的程度，有几个原因：
1 需要考虑到其他进程使用内存的情况
2 考虑到如果一旦全部内存都使用完了，是否启用swap，如果没有的话，那机器是否就立即当机
3 还需要考虑到cpu和带宽的使用情况。cpu对一些比如加解密，视频转码等操作比较耗时，这个时候如果没有使用队列，那么每个请求的时间就会加长。
一般会要求文件服务器和其他web服务器 分开，分开的意思就是使用不同的域名进行拆分。当然其他web服务器 也是可以当做文件服务器的，但是由于文件服务器需要上传文件，而上传文件是一个非常耗时的工作，即php的一个程序需要停留的时间很长，所以需要将它们分开。一则可以为以后扩展文件服务器提供便利，二则不会导致文件服务影响了正常的web服务。
从文件服务器拆分的理由上看，在运营过程中一些比较占用资源或者特别频繁调用的接口是可以或者应该考虑拆分到不同机器上的。
web前端机始终要访问持久化的数据的，mysql的使用是最为频繁的。其实所有的web服务说到底都是对其他数据库 进行增删改查的操作。说到性能，其他数据库 的增删改查操作的性能其实就决定了一切。所以对其他数据库 的建表，索引的使用对一个网站来说尤为重要。觉得最有用的几个mysql的技巧有：
1 覆盖索引。就是想办法让查询操作只查索引而不去查表的索引建立方法。建立合适的索引和能只在索引就能找到数据的查询能提高效率。
2 innodb表最好能使用自增键，提高插入操作的效率。
3 string类型的变量的存储格式，是使用varchar还是char比较好，曾经有个项目表设计从char到varchar之后的其他数据库 大小差别达到70g和20g的大小…
4 建表的时候需要考虑下以后的分库分表，如果是使用分表，什么是分表键？是否需要反向查询表？
5 甚至当考虑到其他数据库 和web机器的机房分布，这个设计就更麻烦了...
mysql的建表环节和需求有很大关系。没有明确的需求，表设计一定是不正确的。
其他数据库 支持有可能还是不足够的，那么首先想到的可能就是缓存了。缓存是使用全局缓存？放在web前端机？需要用什么hash算法？用什么缓 存？memcache？redis？mysql也有自带缓存，如何查询才能更好命中这个缓存？当数据更新的时候，缓存中的数据是否是脏数据？如何更新数 据？
当需要做一个网站的时候，首先要考虑的是用户量有多少？做一个sns网站和做一个运营后台网站完全是两个不同的概念。
首先是在页面压力上，sns网站的qps可能几千上万，而运营后台压力几乎完全可以不用计算。这个就意味着后端的其他数据库 支持不同了。sns网站可能最常调用的会是好友关系和个人信息的接口，这样的接口是不是需要独立出来处理？这样的请求会很多是重复的，是不是考虑使用中间件或者缓存来减轻对其他数据库 的直接压力呢？运营数据一般使用单表就可以解决的。个人觉得运营中统计的需求是最难做的。首先统计并不是任意的统计要求都可以满足，这个需要和产品讨论需求。其次，统计一般需要使用些访问日志之类的，可能涉及到许多shell脚本。
其 实相对于web开发，api开发是属于被动的。意思就是，由于客户端可能是手机产品，可能是pc产品。往往都是有发布和版本的。这个意味着api接口没法 像web那样为所欲为随时更新代码。它更多需要考虑到各个版本之间的兼容问题。兼容问题在很大程度上会变为加法，永远不会是减法。个人感觉，如果毫无节制 地满足需求，随着版本越来越多，你的代码中会越来越多if else，到最后，你的代码就根本无法维护了。然后就会是别人来接手你的工作，踩坑，边骂边重构….api开发是最需要依赖测试的。往往只有测试人员才对 各个版本的小改动，小特性如数家珍。
你可能需要对api调用时间进行统计，这样你才明白你的接口表现如何。
你的代码可能还会用到其他机器上的服务，比如curl一个其他服务，这样的情况，最好考虑下错误处理和日志记录。
对于有金钱交易的接口服务，日志处理更是必不可少。
对于一些内部错误，最好不需要直接抛出显示给用户，所以需要使用的最好是白名单错误机制。
接口的加密方式，一般最少是需要有个签名机制的，考虑到加密方法，大致有几种：对称加密和非对称加密。加密的时候就需要考虑到一些情况了，比如手机客户端的用电量等。
如果是给手机开发 接口，需要考虑流量问题，图片的规格问题。
框架永远是会变的，不说需求的变化，单就用户量的变化，20w用户和1000w用户的框架一定是不一样的。刚开始的时候你不可能根据1000w的用户量来设计框架来给20w人用。所以一个好的服务端框架一定是随着用户量变化会进行几次大的变化的。
…
这篇是想到哪写到哪，写到这里发现写不下去了…总之，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.blog.51cto.com/505887/386852
我们知道压力测试的软件其他 确实很多，诸如微软的wast，惠普的loadrunner以及等等其他的，但这些软件其他 学习起来还是需要花费些时间，在选择上实在头痛，后来在郭欣的那本《构建其他高性能 web站点》上看到了他介绍的这款apache自带的压力测试工具ab，十分喜爱，于是今天终于有机会体验下ab对网站的压力测试。
实验之前我的apache已经安装了，操作系统：ubuntu 10.04 vmware 7.0
1、先查看一下版本信息 ab -v（注意是大写的v）
2、我们也可以使用小写的v查看下ab命令的一些属性 ab -v
3、现在我们就对51cto的网站进行一次压力测试吧，使用命令ab -n1000 -c10 http://www.51cto.com/index.php，其中 -n1000 表示总请求数 -c10表示并发用户数为10 http://www.51cto.com/index.php 表示请求的url，下面是测试的结果，其中我们最关心的三个指标，我已经注释出来了。
4、为了使结果更有对比性，我们将并发用户更改为100个进行压力测试，我这里只将三个指标贴出来。
5、将并发用户改为200个进行测试
6、500个并发用户时的情况
我们来分析下测试的结果，先对比下吞吐率，当并发用户的时候吞吐率最高为190 reqs/s,当并发用户数为200,500 吞吐率下降了，随之用户的等待时间更是明显增加了，已经有2s的等待时间了。这说明性能明显下降了。当然分析这个测试结果并不是说明51cto的网站的并 发用户只能在500左右，因为我是在服务器负荷的情况下就行测试的，这显然不能说明问题。另外我们在生产环境下测试的时候，最好能将测试结果做成报表 ，这样可以非常清晰地对比出问题来，好了，我该准备下，给上面提交一份我们公司网站的测试报告了。
标签：
原文地址：http://www.cnblogs.com/zhengah/p/4334314.html
