【吐槽篇之经验<三>】性能问题定位与调优测试总结

        经历了几次xxx项目的性能测试后，系统中子业务的并发数总是无法得到提升，定位原因也一直无从下手，加上几次项目测试经验后，发现自身定位方式存在问题，以前总以为定位程序问题只要交出结果现象就万事大吉了，但结论告诉我，恰恰相反，提供的结果，开发依然无法定位到具体问题所在，于是学会以下定位问题的方法：

1.1定位问题流程图：

问题（1）：  在 100 用户，在进入xxx页面 时，就报： HTTP Status-Code=500 (Internal Server Error) for http://{IP}/ErrorPage.aspx? aspxerrorpath=/ashx/RZRQ/QueryHandler.ashx/

1、问题分析：观察执行场景中，出现频繁请求  QueryHandler.ashx  方法，而且此方法事务出现大量失败，也影响到下单业务请求无法发送。

2、提出猜想：1、是否脚本出问题；2、是否并发数过大，造成程序无法处理过来；3、并发过程中，服务器资源达到瓶颈，造成无法响应请求。

3、验证猜想：

1、从最简单的验证开始，由于正在执行场景，检验服务器资源是否正常是最简单，于是检查了cpu、内存、磁盘IO相关指标，都正常，所以此猜想排除。

2、验证脚本问题：启动Vuser  脚本中日志，回放结果，从Vuser  日志中未出现此方法请求事务失败，所以此猜想排除。

3、验证是否并发数过大，造成程序无法处理过来：首先将  Vuser   脚本中涉及到QueryHandler.ashx方法的请求找出来，发现存在两处，一处是进入融资融券页面后发送的一个请求，另一处是在下单请求前获取最大委托量请求。为了分辨是问题所在，此时采用屏蔽无关脚本请求和隔离某一处  QueryHandler.ashx  请求方式，分别测试一次，最后发现是下单请求前获取最大委托量请求的问题，这时只是定位到脚本中某个方法，而不能直接说是前台问题，由于虚拟交易所是分为前台和后台两套系统，为了更加准确的定位到是前台或后台问题，接下来分三步走，第一步，在前台屏蔽与后台连接的方法，并设定固定值返回给客户端，通过执行场景未发现问题，可以排除不是前台问题；第二步，前台不屏蔽方法，屏蔽后台程序方法，返回固定值给前台和客户端，通过执行场景，也未发现问题，说明客户端发送的请求能成功到达后台（也只说明前台到后台通道没有问题）；第三步，前后台程序不做任何处理，再次执行场景，QueryHandler.ashx/方法出现大量事务失败，最终确定，问题出现在后台提供的方法上。

 

定位问题（2）：某下单业务，在并发数100、80、50时，运行2 到4分钟左右后，部署后台程序的服务器的cpu占用率到达100%左右，甚至服务器有时处于未响应状态，而且在执行场景前，发现问题（1）影响到了此业务，于是要求后台将问题（1）中的方法屏蔽，以免影响定位问题。为了有效的定位造成后台服务器瓶颈问题，首先要确定在执行并发下单业务时，后台服务器中那些进程占用cpu最多，于是远程进入后台服务器，发现后台清算服务进程占用cpu达到100%左右，而且有时处于一种未响应状态，但目前也只知道问题在清算服务上，未能准备定位问题，而造成程序cpu使用率很高原因有很多，加上对程序内部结构不了解，只能通过增大和减少并发数进行多次场景执行，寻找异常现象，通过多次执行场景，最终发现有一种奇怪现象：在并发过程中服务器清算服务进程中线程数很大，而且线程基本上没有释放，在场景结束后，线程数也很大（如下图所示），于是猜测是程序设置线程大小存在问题。为了验证猜想，在开发的指引，发现程序线程池大小为  1000，于是修改线程池大小改为：300左右，再次执行场景，发现清算柜台进程占用cpu达到7%左右，说明本次调优测试成功。