通过监控得到系统资源占用率数据有：

　　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、多方面结合缓存机制

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