原因说明

下面描述的是前段时间协助厦门本地一家上市IT公司做产品技术选型时对他们的技术框架进行性能测试与优化过程记录，因测试过程中涉及数据库产品选型、应用框架诊断分析优化、操作系统监控、硬件配置优化分析、JVM监控优化、SQL语法优化等各类问题的监控分析优化，篇幅比较大，顾本次主要是描述在同样基础软硬件下、同样应用工程包和框架、同样数据量下，针对MYSQL环境下进行单点登录压力测试的结果过程记录。

初始环境配置

测试内容

1、 用户登录，首页查看，退出
2、 某业务交易新增、查询、删除、上传文件
3、 业务审批流程创建、提交、审批、同意等工作流程；

问题诊断分析

LR端监控分析

在压力测试中，首先压力测试，登录首页、退出，10个用户并发10分钟，通过loadrunner控制台发现登录响应时间120秒超时现象，失败率一直在递增，LR结果如下图：

应用资源使用监控分析

因为是使用wind2008系统服务，监控相对比较方面，通过任务管理器监控，发现应用服务器CPU使用不均衡，出现类似单线程死锁现象，其中一个CPU线程使用率大于80%，而另外一个CPU线程使用率非常低，如下图:

这时发现网络带宽使用率也非常高，10用户并发网络IO瓶颈每秒大于100M，如下图：

通过与网管交流，服务器给予配置的网卡是1G，那说明是应用服务端发送数据给客户端展现导致网络带宽使用偏高，最终导致前端120秒超时问题出现，因为是使用虚拟机环境，为了更好的证明是不是应用问题，也加以猜测怀疑是不是刚好有其他原因导致的，这时我停止压力测试发现再没压测情况下网络带宽使用50KB

说明是应用某方面问题引起如上问题，这时也看到操作系统可用物理内存一直持续降低，响应时间也越来越大，为了更准确的查看具体问题原因，查看tomcat应用日志分析发现，应用日志展示内存溢出现象java.lang.OutOfMemoryError: GC overhead limit exceeded，如下图：

通过日志细化分析，发现登录首页，会展现业务相关信息，而且需要全表扫描方式通过MYSQL服务捞取数据结果集，然后传递给应用端进行封装展现给前端，最终出现表现现象是前端lr出现120秒超时，后台应用CPU单线程死锁、网络传输带宽使用率偏高，内存溢出现象，具体抓取分析的日志如下：
java.lang.OutOfMemoryError: GC overhead limit exceeded

at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3669)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3609)

JVM分析

通过压力测试过程发现内存溢出时，监控到的JVM使用如下图：无法正常GC回收导致，内存溢出，也发现了JVM默认配置下有问题，如果配置合理JVM使用虽然会异常，但是还是可以强制GC回收，问题如下图：

根源定位

因登录首页后需要刷新框架，其中最大问题是框架设计中对登录首页会对某一个业务交易的公告信息进行时时刷新展现数据，如果对应业务表数据量有多少，则公告信息就全部展现，如下业务交易图：

而框架中，公告信息展现需要加载到getBulletinList控件下，以目前现有测试数据量，单用户下该控件大需要展现的数据大小17M，导致10个用户并发时网络带宽和java虚拟机出现异常，而且数据库出现类似如下锁表信息：

当然压力测试过程中抓取其他锁表语法，例如用户登录对应的SQL语法，也会导致响应时间超时：

优化方法

1、 通过建立索引方式
2、 修改JVM配置新增新生代大小和强制GC回收机制
3、 因为框架设计问题，公告栏展现只展现最近时间前5笔数据；如果需要看详细信息点击”更多”在触发后台业务交易，进行查看详细信息；

优化后监控

通过优化后，100用户单点登录并发压力测试，应用服务器资源使用率，如下图，CPU使用均衡，均低于30%，网络带宽使用率低于20M，数据库资源使用率也都低于指标范围，

应用JVM回收情况如下：

数据库服务器资源使用情况如下：

LR压力测试结果如下：

总结：

本次压力测试技术选型中的性能测试，涉及交易功能包含，登录退出、管理交易、流程交易，也对软硬件、操作系统参数、应用参数、代码、数据库产品对比、网络配置、浏览器选型等进行性能测试监控诊断分析优化进行对比，如下:

本篇文章成文仓促，从选型的角度看，建议针对各种满足不同功能需求的技术框架进行选型，当面临技术选型时，首先考虑的要对产品架构进行合理的验证评估，例如性能测试，也要根据不同的场景进行验证测试，最终选择一款合适的框架