压力测试终于过了

心情很好，随手记录下

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为奇数的数据库查询放到了另外一台服务器上，解决了这个问题。

19.终于通过了

感谢同事T，Sina工程师E