今天在网上看到一篇不错的文章。供自己参考。
1.接受压测任务
真的没有想到sina的要求还是比较严格的,而且是必须通过他们的测试才行
2.理解压力测试需求
手头有一份压力测试的样例文件,对于“服务器每秒处理能力”的结果如何获得没有想法
3.寻找压力测试软件
一开始使用siege测试,但是对于当时的apache服务器,无法测试每秒200次并发的情况,就放弃了,不过后来发现,其实不必测试这么多次的并发,也是可以得到跟sina基本一致的数据。
放弃了siege后,开始使用webbench,不再有200次并发的限制,但是有个问题,返回的结果信息过于简单,只有成功次数和失败次数。
当时使用30000的并发,虽然错误次数增加了,但是没有宕机,而且正确次数也在95%以上,所以认为就算通过了。写了份报告提交给sina工程师E。
4、sina工程师E的反馈
E的报告彻底击倒我了,最复杂的初始化人物接口,在30的并发数下,每秒处理能力只有10次左右。我想,会不会是并发数太小的原因,E将并发提升到50,服务器每秒处理能力在15次左右徘徊,E说可以认为15就是该接口每秒处理次数了,远远低于标准了。E用的测试软件是LoadRunner。
5.LoadRunner
鉴于我当时认为Loadrunner和webbench测试结果相差太大,所以我也决定用loadrunner。下载了8.0的版本,有300M左右,安装好后,机子卡不说,居然把我管理员账号占用了,系统登录的时候,是Loadrunner的账号,还需要密码。我当时就崩溃了,不至于要重装系统吧。后来在网上找到了该默认账号的默认密码,但进入系统启动loadrunner后,对里面如何写测试脚本,没有找到门道。放弃了。后来,另外一名技术人员T也尝试使用Loadrunner,是11的版本,一共有4G,但是有2个模块安装不上,而且还是不知道如何使用,目前还是放弃。
顺道说下,loadrunner强大的分析能力,生成报表能力,根据场景写测试脚本,测试流程的功能的确不是其他开源简单的压力测试软件可以相比的。
6.寻找瓶颈
安装了php的扩展xhprof,可以分析每个页面的所有函数执行时间,很不错。
从中检查出一出重大拖累性能的地方:程序中有一处是解析文件,并且把文件的内容放入数组,耗费了很大的时间,将这部分数据放在NoSql中,效率提升了。
从这里得到了很大的鼓励,继续研究是否还有需要优化的地方。可惜的是,并没有找到更有价值的优化点。
7.webbench+xhprof分析
单个页面如何刷新,都能得到比较理想的速度,但是依然通过不了E的指标。
在这样的情况下,决定使用webbench来做并发,并用xhprof记录每次的执行效率。
测试后发现,生成的1000份报告中,前15%的处理速度是比较理想和接近的,但是中间部分会有一个突然很大的起伏,耗费的时间一下陡增了10倍左右,分析了报告,瓶颈主要卡在PDO_MYSQL,Nosql的处理上。似乎找到了点瓶颈的落点。
8.第一次解决方案
调整apache的最大连接数等参数,调整mysql的最大连接数,测试了一下,基本没有太大的变化。再次开会,压力测试迟迟没有进展,我的压力开始增大。
我跟T说,让总部负责运维的人来帮忙吧。
9.总部运维同事重新部署系统
总部的运维帮我们安装了nginx,php,mysql。由于总部并没有使用过Nosql(TT)的经验,所以php的Nosql(TT)扩展等相关由我们这里来负责。
部署完毕后测试,基本没有太多的变化,只好重新开始思考优化方案。
10.NoSql(TT)和 MYSQL 分流
使用了另外一台服务器,把NOSQL(TT)部署在该台服务器上,该台服务器ping当前服务器为10ms。
结果xhprof的报告更差了,平均比以前慢了10倍,分析代码,NOSQL(TT)的get,put,有数百次,每次都延时10ms,不慢才怪。
MYSQL部署在外部的结果没有太大起色。
11.确认测试数据
根据我一个朋友给的腾讯的压力测试需求,150并发,每个请求200ms以内,我也打算使用150的并发,然后再查看成功次数。
然后运行初始化接口,每秒最多完成20次的请求,跟sina数据基本一致。
12.新的查找瓶颈方案
空代码运行,发现每秒完成在1200次以上,但是执行了我们的代码,效率下降很快,所以认为代码优化的潜力很大。
决定从初始化接口开始,一行一行代码的测试。
13.第一个瓶颈点
增加一个非空的判断,使得每秒处理次数大幅提升,同时使用单例模式,减少开销。
提升了20%的效率。
14.第一个加速点
安装php加速器eaccelerator,速度提升了30%左右。
15.第二个加速点
配置Nosql(tt),使用的方法会在其他的帖子详细说明,提升了5%-10%的速度。其实tt不做任何的配置,他的默认配置下速度也是很快的。
16.第三个提升点
将TT中过大的数据切割成较小的数据,虽然多了get的次数,但是速度却很大的提升,30%-40%应该是有的。
至于多大的数据需要切割,我并没有更详细的测试,我这次切割的数据高达800k,高并发下速度会下降得很厉害,切割成小块不超过200k的数据后,速度提升非常明显。
17.第四个提升点
修改系统内核,增加系统允许的最大访问次数,最大程度发挥TT的效率,这里可以贴出E的参考方案,在50000次并发以上效果明显。
- #!/bin/sh
- sysctl -w net.ipv4.tcp_tw_reuse=1
- sysctl -w net.ipv4.tcp_tw_recycle=1
- sysctl -w net.ipv4.tcp_fin_timeout=10
- sysctl -w net.core.wmem_max=8388608
- sysctl -w net.core.rmem_max=8388608
18.第五个提升点
sina工程师E报告还说,会偶尔出现pdo_mysql连接不上的错误。
于是用程序做了一个分流,把user_id为奇数的数据库查询放到了另外一台服务器上,解决了这个问题。
转载来自: http://crizy.iteye.com/blog/1171410