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