第一部分， 测试执行

先看一图，再看下文

这个当然就是压力过程中带宽的使用率了，我们的带宽是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、多方面结合缓存机制

不知道以上的分析结果是否准确，但让我从性能分析的思路上又走出了一个绝地，不要放过每一个细节，也许那就是拐点。