性能问题排查-案例2

此案例是由一个数据表批量更新导致的性能问题。

1，进入性能日志列表

点击延迟数下面的数字链接，进入日志列表界面：

2，观察&过滤日志

点击【oprName】，它会展开出现下面列表：

点击上图中的 + 符号即可过滤，例如：

此时可以看到 stepCount 这一列的数字都比较大。

这个列的数字含意是：一次请求过程中执行了多少次远程调用，显然这个数字应该是越少越好，

这里偏大就很不合理了！

3，查看日志细节，了解执行过程

我们进一步查看日志中的性能详情，请参照图片来操作：

可以看到下图：

基本上全是数据库操作（ExecuteNonQueryAsync），任意选择几条查看下到底在做什么，

4，结论

性能分析：

1. 本次分析的这个请求: 性能不达标，且执行次数占比较多，导致服务的整体性能较差。
2. 请求性能不达标的原因是：在一次请求中执行了太多的UPDATE数据库操作

结合业务场景来分析：

1. 这是一个采集数据的保存场景，每次采集到数据都会更新到数据表
2. 这个场景中，每次采集都会有大量的数据（一个K8S集群中所有POD信息）
3. 这些POD信息并不是一直变化！

优化建议：

1. 为每次采集的数据生成一个HASH值
2. 每次更新前，计算HASH值，与上一次比较，有变化时才更新。
3. 更新数据后保存最近的HASH值