7DGroup性能实施项目日记7

九月廿五 壬寅年 虎 庚戌月 丙午日

从昨天的场景执行和结果分析来看，效果有一些。今天我们又换了一个接口，看看有什么新问题。
从我的 RESAR 性能工程的逻辑上来看，现在是在基准场景执行的阶段。在这个阶段就是要把每个接口都单独压到最大tps，并且一定要明确瓶颈点。比如说在登录接口中，递增压力线程直到tps不再上升，然后通过分析压力数据的趋势和全局监控的计数器来判断当前的瓶颈点在哪，给出明确结论。也就是根据 RESAR 性能分析七步法的逻辑。如下：

在这个接口上，可以看到如下压力场景的数据。

tps曲线锯齿比较明显，响应时间也有对应的趋势。根据RESAR性能分析七步法，显然第一步的判断是有瓶颈，而要找到对应的瓶颈点，就得走下面的六步才可以。

通过架构图和代码的调用逻辑，可以明确这个接口涉及的技术组件有gateway、member服务、auth服务、redis、mysql。

用 Skywalking 拆分响应时间。

然后通过全局监控逻辑和定向监控逻辑，可以看到有几个问题。

第一：数据库cpu整体使用率并不高，但也明显有了io wait的情况，这是一个需要优化的瓶颈点。

第二：通过对应用的全局监控和定向监控，可以看到应用的内存初始值过小，ygc还是比较频繁，这是另一个需要优化的瓶颈点。

通过以上图可以看到我们后续的优化方向是很明确的。后面我们会对这些瓶颈点一一执行优化动作。
其实对于性能分析来说，找到这个瓶颈点，比优化这个瓶颈点要难得多。在我们这几天的执行来说，经常看到所有人都能看到所有的数据，但是下一步要干什么就是一头雾水。而这关键的分析环境需要的技术功底就比较多。

我们之所以花这么大的时间和成本来搭建完整的性能项目给7DGroup学员们锻炼，也主要是为了把这个分析逻辑的细节真实地体现出来。

并且所有人都可以看所有技术细节，权限也给到最大。在这样的环境中，没有部门岗位产生的权限壁垒，没有不可见的技术细节，没有因为私心而不愿意做的技术分享，也没有教会学生饿死师傅的担心。

怕的是：不用心。