性能测试经典案例解析——政务查询系统

各位好，我是 

@道普云

一站式云测试SaaS平台。一个在软件测试道路上不断折腾十余年的萌新。

欢迎关注我的主页

@道普云

文章内容具有一定门槛，建议先赞再收藏慢慢学习，有不懂的问题欢迎私聊我。

希望这篇文章对想提高软件测试水平的你有所帮助。

---

政务查询系统的用户量相对来说是比较小的，但是它的复杂性和对实时性的要求是比较高的，我们以一个主要提供单位信息业务复杂查询功能的系统为例。

在测试过程中主要发现某查询业务在生产环境响应时间过长，超过20秒，但是在测试环境响应时间却较快，只有3秒左右。相关数据表也已经建立了索引。而且生产环境配置比测试环境高，按理说生产环境配置更高它应该更快。针对这个问题，我们要找出为什么在生产环境中慢？

接下来我们就通过时间分布分析、环境差异分析、数据库监控分析、SQL执行分析这几个方面去进行分析。

时间分布分析

业务响应时间主要消耗在SQL执行时间。

生产环境SQL执行时间在26秒。

测试环境SQL执行时间在3秒以内。

环境监控比对分析

生产环境数据量59万，使用CentOS、Oracle 12c Rac，硬件配置较高。

测试环境数据量176万，使用Windows server 2016、Oracle 12c 单节点，硬件配置较低。

服务器资源在正常范围内。

数据库监控分析（AWR）

Oracle实例处理器、内存资源指标正常。

Oracle实例中没有明显的等待事件。

存在问题的SQL语句执行计划COST在生产环境、测试环境存在巨大差异。

SQL语句执行分析（1）

SQL语句执行分析（2）

生产环境SQL语句中排序相关操作由于没有经过索引，造成IO过高。

Oracle实例中排序相关参数Sort_Area_Size、workarea_size_policy配置存在问题。

通过去除SQL语句中的排序操作，SQL执行时间大幅度提升。

通过性能问题综合分析我们得到的诊断结果是：定位索引失效原因。

通过与开发、运维人员沟通，了解到该表是通过数据迁移在生产环境进行创建。

在数据迁移过程中，表的rowid发生变化，造成索引失效。

解决方法：

通过新建表空间重新导入数据表、重建索引解决。

Alter index index_name rebuild tablespace tbs_name;

Alter index pk_name rebuild tablespace tbs_name;