# 使用JMeter压测表单不通过，平均耗时36秒
# 背景
客户环境：
信创：东方通中间件
信创：达梦数据库
版本：老版本升级到V8.2SP1再转信创
客户上线前需要进行一轮压力测试，以确保性能稳定。本次直接使用致远标准的压测工具JMeter和致远的脚本，并发40，JVM堆内存32G，压测表单场景不通过，平均耗时36秒：
# 问题分析
首先排除压测工具问题，检查压测的并发配置：并发仅40，配置正常。
然后使用系统管理员登录后台-系统监控，一边压测一边导出Thread Dump，检查线程是否存在缓慢点。
经过多个Thread Dump对比分析，发现大量线程都卡在AffairDaoImpl.getAllAffairIdByAppAndObjectId，再根据堆栈调用发现根本原因都是卡在达梦数据库查询上。
根据Thread Dump初步结论：AffairDaoImpl.getAllAffairIdByAppAndObjectId这个程序里执行的达梦SQL查询存在性能瓶颈。
基于以上分析，将问题重点放在达梦数据库上。达梦数据库慢可能有多种原因，我们优先从产品自身出发寻找问题：如果产品中缺失索引会导致查询缓慢。
下一步，在客户环境部署环境检查工具envchecktool，此工具能扫描出服务器的不合理配置，以及数据库缺失的索引。
经过环境检查工具扫描，达梦数据库下确实缺失索引，按照工具的提示，将索引加入到达梦数据库，通过查看缺失的索引，可以看到确实有几条索引是与本次缓慢点Ctp_affair有关：
以上完成后，再一次执行压测，平均耗时由36秒降低到13秒，添加索引让问题明显好转。但这个压测结果依然不达标：我们需要让平均耗时减少到3秒以内才算正常。
再次压测，同时达梦数据库技术一起配合导出缓慢SQL，可以看到慢SQL还是Ctp_Affair。
这种情况，需要取其中一条慢SQL，进行explain，分析SQL是否走了索引以及走了有效的索引。
经过进一步的分析，初步结论是：SQL走了索引，但并没有走到最优的索引上。再进一步检查Ctp_Affair表，可以发现表里面有很多8.2SP1不用的索引，就是因为这些多余的索引干扰了数据库的决策。
最终解决方案：
1、先删除Ctp_affair表的所有索引 2、再使用环境检查工具扫描数据库，此时会导出Ctp_affair缺失的所有索引，依次执行一下即可。
使用别的解决方案也行，总之要把多余的索引全部去掉。
索引重建后，重新压测，所有请求平均都在1秒以内，压测通过：
# 问题总结
致远压测脚本是经过几十上百家压测客户确认的，不可能只有这家有问题，压测遇到问题，首先是怀疑环境配置参数调优问题。
压测发现某一个请求缓慢（大于10秒），优先用Thread Dump分析具体慢在哪里，一般是数据库索引问题。
然后用致远的环境检查工具，扫描客户环境和数据库，如果提示缺失索引，就将缺失的索引打到数据库里（不用重启OA）。
一般缺失索引补充后，问题就能解决。
如果看到结果有明显好转，但还是没达标，则再次怀疑“是不是索引多了”，V8.0之前的版本确实存在大量冗余的索引，性能表现也很差，8.1之后产品砍掉了2/3的索引，性能明显得以提升。
扩展阅读：
索引多了之后，不同数据库对使用什么索引策略是不同的，一般Oracle这类数据库对索引的引用是最好的，他们会想办法用最优的索引。而现在很多国产数据库达不到这种能力，所以只能想办法舍弃一部分无意义的索引，这本身也是减负的一种策略。产品自8.1开始就开始索引“瘦身”，其后版本对索引的利用已经非常高效，所以只要索引不缺不多，标准产品性能问题就不多。
