性能测试调优过程

1、对魔镜系统的三个场景流程进行性能测试。

场景1：选择一个已有的项目并打开直接进入到仪表盘--进入到分析台---拖拽度量和维度---依次选择不同的图表类型----保存最后一个图表 ----删除图表---再回到分析台

测试的步骤

1、录制脚本，采用loadrunner12录制脚本。：因为系统只支持chrome浏览器，而只有lr12支持chrome浏览器，lr12有免费的50并发用户的liscense，要想测试更多并发，要么多台机器并发要么更换成更低版本的脚本后，再从lr11版本进行场景压力测试。

1.1 数据准备：因为系统是单点登录，因此要做并发需要参数化不同的用户，

                   a:准备100个登录账号，公司运行jemeter脚本生成的100个用户，

                   b:为100个用户各创建1个相同名称的项目，同时要求这些项目使用的数据源相同，这样拖拽的维度和度量就相同，系统运行自动化功能脚本的方式，为这100个用户创建了100个项目

                   c:通过数据库查询这100个账号下的项目的projectID 和 boardID(仪表盘)，跟这些信息相关的还是userID而不是userName，以及chartID。

                  

2、增强脚本:参数化脚本，username,userID、projectID、boardID以及登陆后的token;

                  a:本来系统不需要测试删除图表的性能，但是还要必须删除呢，因为同一个账号下面的图表，如果不生成就会越来越多，而保存图表的过程还包含了打开仪表盘的过程，因此每保存一次图表就要删除一次，这样才能保证环境统一

                  b:要删除图表因此还需要chartID，因此在生成chartID时候要做关联。

3、先回放脚本：检测参数化的结果是否正确，可以设定运行时设置的日志，用于查看参数化的值，

4、再看多个迭代  脚本运行情况：只能看到一个用户的多次迭代情况，不能看出并发时候的迭代情况。

5、再看多个用户跑一段时间的场景情况：可以看到并发时候的迭代情况

6、真正的运行场景：

           a:用户的递增时间也很重要，以及运行时间也很重要，根据市场部的场景是供学生使用，一般一堂课就是45分钟，因此运行时间是45分钟；

7、场景监控

     a:服务器资源监控:阿里云服务器有自己的监控平台，可以找到账号和密码，进入云监控，可以监控到数据服务和应用服务的硬件信息，包括内存和cpu等之类的，

     b:网络监控：本机的网络是否已经达到瓶颈，查看任务管理器

                     本机的网络是否有带宽限制，可以查看路由器的设置，比如在192.168.1.1上进行设置和查看，上传和下载的速度是否已经达到上限，从而

     c:响应时间监控，通过loadrunner监控。

8、查看分析结果

       a:结果分析得出：保存图表响应时间过长，经过查看网络细分图，得出保存图表长的瓶颈是服务器响应时间过长。

       b:使用的内存一直上升，性能结束后也没有下降，有严重的内存泄漏现象

       c:帮助反馈的视频加载

9、调优

        a：数据库索引的调优

        b:连接池配置的调优
        c:代码的调优
         其中数据库索引调优效果比较明显

 

        调优过程：

        （1）第一轮测试过程中出现过几次服务器自动关机重新的现象，原因就是tomcat占用内存太高，导致系统根据自己的机制吧tomcat进程给杀掉，导致系统崩掉了，

                 

简单解释就是  linux存在一个机制   定时的对系统运行的进程进行评分  

你又打不过我 9:39:40

评分机制中内存占用的是一个因素 

你又打不过我 9:39:58

然后 吧评分最低的kill 掉保证系统稳定 

你又打不过我 9:40:18

然后你测试的时候 导致tomcat 暂用的系统内存的 4/3 

你又打不过我 9:40:26

然后就被系统kill 了

      （2）给系统服务器的硬件升级，翻倍后升级成2台  4核8G的配置，原来内存只有4G，话说jvm虚拟机就占3G,怀疑是内存太小导致内存回收机制不能正确的执行，导致了内存泄漏；

 

　　　　　硬件升级后系统不会在很短的时间内就崩溃了，但是内存泄漏问题仍然存在；响应时间稍微有一点变化，在100用户左右时才有明显的变化，

　　（3）提升agent的带宽，原来有5M带宽限制，后来改成不限速，通过对比结果发现TP的响应时间并没有明显的提升，查找原因得出，脚本中有下载视频的操作，因此提升的带宽全部优化到了下载视频上，下载视频占用了很大的带宽，通过跟开发沟通，确定“帮助反馈”的视频是打开页面时自动下载视频，是同步的模式，因此需要调优“帮助反馈的视频”加载方式，改成异步加载，

 

　　（4）系统改成异步加载后，再次进行性能测试，发现响应时间有了提高，但是内存泄漏还未解决，

 

　　（5）解决内存泄漏问题，即优化代码

　　（6）提升保存图表的响应时候：开发代码在保存图表的时候做了一个图表的排序工作，优化后把图表的排序去掉了，同时增加了很多数据库索引

      （7）其中开发用数据库自带的工具，查出了有两条语句耗时很长，

       （8）大大查看了一些数据库语句是嵌套查询， 比如A语句里面嵌套了B语句，A语句循环10次，B语句循环10次，这样嵌套下来要查询100次，势必要增加时间。

 

通过以上的优化，响应时间和内存泄漏问题都有了很大提升。