性能瓶颈定位案例    《转载》

被测系统介绍

　　被测系统为B/S结构，J2EE架构，应用服务器为Tomcat，数据库为Oracle 10g。系统的使用对象为公司的内部人员，网络环境为100兆局域网。

　　性能瓶颈描述

　　客户反映访问页面时反应慢，并且出现部分请求失败的现象。

　　通过对单用户的网络带宽计算，排除网络瓶颈。

　　解决思路

　　在应用服务器Tomcat植入dynaTrace Agent，Agent能7X24实时收集应用服务器的所有的Log，包括最终客户端向Tomcat发送的Web Requests、Tomcat向DB请求的SQL语 句、DB执行完SQL语句的返回数据、Tomcat向最终客户端发送的返回数据。dynaTrace Server智能分析dynaTrace Collector收集到的所有Agent捕获的Log。通过dynaTrace Client实时查看监控信息，对被测系统进行性能瓶颈定位并分析。详细的测试环境部署图如下：

　　解决过程

　　1）通过Error快速定位瓶颈

　　对实时监控收集的Log进行分析。首先查看其事务流图Transaction Flow。如图2。Failed Transactions显示失败的事务及失败事务数占总事务数的百分比。图2显示存在失败的事务867个，占总事务数的3.17%。

　　对出现失败的事务进行分析，首先查看失败事务提示的Error Log，如图3。说明存在4XX 、5XX Error，也有重要程序内部Log，具体Error见图4、图5、图6。

　 　将收集的Error Log提交bug给开发人员。HTTP Response Code的Error详情可以协助开发人员快速定位并修复有问题的URL。Important Loggings可以帮助开发人员快速定位程序出现问题的原因。如图6显示创建Socket 连接失败，并提示确认相关Server已开启或相关组件已正常运行。

　　2）快速定位瓶颈原因

　　在性能索引图表快速锁定响应时间长的性能索引。如图7，事务响应时间最长的性能索引为/IOST/as.do，响应时间为40004.86ms。

　　分析性能索引的方法执行情况，可快速看到执行过程中出现了Exception。如图8。

　　定位到出现Exception的源码，如图9。

　　针对响应时间最长的性能索 /IOST/as.do进行分析。钻取性能索引/IOST/as.do 的Web Request，定位其相关的URL，如图10。URL为http://172.16.200.61:8080/IOST/as.do，在浏览器上访问 URL报404错误，如图11。

　　进一步分析404 Error的原因，钻取性能索引/IOST/as.do的Error，定位到一个JRedis API的Socket连接失败，如图12。

　　效果

　　JRedis为缓存服务器。Web前台将根据一定规则，从数据库直接获取需浏览或查询的信息进行显示，为了规避当前 系统请求负担引发事务处理失败的情形，引入Redis缓存服务器，使系统请求入口点统一从缓存进行处理，以达到快速访问和确保事务成功的双重目的。引入缓 存服务器大幅度地提高了系统处理客户请求的能力,解决了系统处理网络I/O操作的瓶颈问题。不但提高系统可扩展性，而且有利于提高系统吞吐率。

　　更多解决方案》》http://www.51testing.cn/

　　dynaTrace工具》》http://www.51testing.cn/product_service/dynatrace.html

版权声明：本文为51Testing软件测试网原创，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。