第一部分, 测试执行
先看一图,再看下文
这个当然就是压力过程中带宽的使用率了,我们的带宽是1Gbps的,合计传输速率为128MB/s,也正因为这个就让我越来越疑惑了,不过通过压力过程中的各项数据我又不得不相信。
在看看测试页面的大小和请求,如下图所示:
这是通过httpwatch检测得出来的,页面传输内容的大小为652154Byte,请求数为149次,也就是说加载一次页面就大概需要请求这么多次请求,传输这么大的内容,当然这里剔除缓存机制来分析的。
场景设计:
1、并发用户200
2、每20秒加载10个用户
3、全部用户加载完成之后,持续运行10分钟
监控目标:TPS、响应时间、点击率、吞吐率、内存、CPU和网络带宽
测试分析结果如下图:
这里的可以得出平均点击率为11952.139次/s,而吞吐率为73178737byte,大约为73MB/s,TPS:720/s,这里的错误后面再说。
这里的响应时间很显然没有上去,说明压力没有传到页面上,而上面的错误也同时可以证实,报错基本都是请求被拒绝,也就说后面没有请求导致页面没有压力,响应时间就无效了。
通过监控得到系统资源占用率数据有:
CPU:25~30%
内存:20%
网络带宽:70~95%
通过Httpwatch在压力过程监控的页面响应时间为:6.454s
通过结合虚拟用户、点击率、吞吐率和响应时间的曲线图分析得出如下总结:
当虚拟用户加载到150的时候,点击率和吞吐率此时处于峰值,且网络带宽达到90%以上,当虚拟用户继续加载的时候,点击率和吞吐率均都开始下降,此时场景运行开始报错,提示信息为服务器连接被拒绝。通过分析,处于峰值只有网络带宽,为90%以上,而对比此处的吞吐率值恰为95MB/s左右,1Gbps的网络带宽传输速率为128MB/s,从而表明由于吞吐量过大,占用了大量的带宽资源,导致后续的虚拟用户无法得到服务器的资源,而致使请求被拒绝。从最后的页面响应时间来看,系统的压力并没有被承接到页面上,而是由于过大的吞吐量吞噬了网络带宽,导致最终无法有效地完成测试任务。
第二部分,测试分析
如上的结果确实是证实了网络带宽不够用,抱着这个不大相信的疑问,我在群里跟大家讨论了一番,当然大家的给出结论也都是一致,也有建议修改系统的参数,释放所有的带宽等;还有就是分析页面,当然这个我个人认为是比较切实的路径,毕竟1Gbps的带宽,如果再扩从的话也不大现实,所以还是要靠优化程序着手。
我又继续通过httpwatch工具对其他门户网站首页进行检测,发现页面容量差不多,但是从请求上来讲,腾讯和同花顺的首页请求都只有80左右,而我们的却有149个请求,这里的请求数就直接决定于点击率的多少,从这里我们就可以发觉,并不是对所有的压力测试来说,每秒钟的点击率越高,对应的吞吐率越大就说明系统的性能越好,必须相对请求数而言来进行分析。从另一个层面上来说点击率越高是说明程序效率好,但是从本身来讲,如果一个页面本身的请求就很多,那最后的点击率必然会大,大到最后的结果就是页面内容累计容量就越大,导致传输带宽的不断放大,当然就带宽不够用了。如果一定程序上降低了单个页面的请求数量,那页面的执行效率必然会越高,而需要结合整体页面的容量大小来衡量。
最后,我给开发提出的建议,还是需要对程序、页面等进行优化,优化硬件还有待考量,优化建议如下:
1、降低页面的请求次数
2、优化页面中各个元素的容量大小,结合Page Speed和YSlow工具进行优化测试
3、多方面结合缓存机制
不知道以上的分析结果是否准确,但让我从性能分析的思路上又走出了一个绝地,不要放过每一个细节,也许那就是拐点。