背景

随着客户业务越来越多基于K8s部署，在工作过程也经常遇到压测性能对比。引起性能劣化的因素很多，操作系统（CPU争抢、缓存频繁回收、TCP/IP）、存储、网络、关联服务性能、API流控等等，单归根结底是某些因素影响了进程的处理速度。
容器的本质就是被cgroups限制、被namespace隔离的进程，容器平台的主要工作是管理节点、应用、服务的生命周期，除了弹性速度外（扩容节点速度、纳管节点速度、调度速度、拉取镜像速度），大部分压测场景下性能劣化表现与K8s或者容器本身并无关系。
虽然个人主要技术模块在K8s范围，在工作过程有时会和一些计算、网络性能专家一起处理一些压测相关问题，有幸从他们那学到一招半式。

思路

一般我们收到的问题描述为“在压测过程，客户业务的指标劣与友商”，压测性能相关问题一般比较复杂，干扰的信息非常多，在处理过程也可能会求助到不同模块的专家，需要将相关信息固化下来：

1. 明确多大压力情况下，什么业务的什么指标劣与友商，比如“在500并发压力下，我方环境客户fp业务平均时延为1445ms，友商环境为557ms”

2. 固化出来我方和友商环境业务流量走向图，在图中能清楚的表达出：
   1）压测端：压测方法、工具、压测环境；
   2）被压测端网络通路：压测端和被压测端网络，被压测端访问网络通道（如入口ELB、EIP）、访问网络通道规格（ELB规格、EIP带宽），被压测端入口网关组件等，以及此通路中涉及的计算、网络能性能规格；
   3）被压测端本身：limit配置、镜像、yaml配置、业务相关日志、容器所在节点信息（规格、操作系统版本、容器网络模型）
   4）被压测端依赖服务：被依赖服务清单（数据库、中间件等）、规格以及其网络位置。
   

3. 基于上图，先确认我方和友商环境是否相同
   1）上图相关位置我方和友商环境服务规格对比，判断基础环境是否一致
   2）业务本身yaml资源对比，判断部署文件是否一致
   3）在镜像tag相同情况下，对应的进程包是否相同（真的遇到过tag一样，jar包不一样或者配置不一样的情况）

4. 基于上图，排除压测链路中网络和转发层瓶颈
   1）通过查看入口ELB、EIP相关指标，ELB重点关注新建链接数，EIP主要看带宽数，确认是否有瓶颈
   2）查看业务入口网关服务，看网关服务CPU\Mem或者其他相关业务指标，确认是否有瓶颈
   3）查看出口SNAT、EIP相关指标，确认是否有瓶颈
   4）查看关联服务，比如图中的友商云服务库指标，确认是否有瓶颈
   

5. 大致圈定怀疑点，获取压测方法，通过阶梯压力测试找到性能劣化拐点
   1）如上图，通过排除干扰项后，大致可以锁定是业务本身有问题，需要了解该业务压测的API主要的处理逻辑、和那些服务（比如数据库、OBS）有交互、业务日志（有些日志会打印访问XX的时延，这个可能是有用信息）
   2）一般客户都是直接上很大压力，然后发现指标有差距，这种情况下很多操作系统信息对定位有干扰，一般建议通过不断降低压力的方式，找到性能劣化的拐点压力，在拐点压力下的相关指标可能更明显的暴露问题。在此过程中需要不断压测，为了防止影响客户工作，获取方法和授信还是很有必要的

处理过程

好了，总算要到perf了~
通过上述的排除，现在问题聚焦在：在500并发压力下，我方环境客户fp业务平均时延为1445ms，友商环境为557ms。此时双方环境容器CPU利用率均在95%，内存利用率60%左右，但是我方环境业务日志显示访问数据库的时延高。

1. 压测过程中，在容器内抓取访问云数据库3306端口数据包，追踪一条tcp流（客户业务使用线程池）发现业务访问mysql的报文，存在较多等待（等0.2s左右）再发的情况，结合一个URL接口会访问4次数据库，导致整体时延偏高。排除公网网络质量、机器性能差异等问题后，锁定原因：数据包发包慢导致业务整体时延高，结合压测过程中容器CPU利用率超过95%现象，怀疑为CPU时间片抢占有关。（wireshare还是很NB的，wireshark delta time可以看到每个报的发包间隔）
   

2. 通过阶梯压力测试，发现在不同低压情况下，部署在我方容器上的业务CPU利用率高于友商，在排除网络中断等可能引起CPU抢占的因素后，基本可以确认与代码实现有关
   
   vmstat 1 --wide命令看system in，和有商环境系统没有大的差别
   

3. 使用perf命令查看业务进程调用
   perf record -p "pid"在压测开始前执行该命令，等待收集数据，命令执行后即可开始压测
   perf report压测后等待几分钟，执行ctrl C停止perf record，然后执行perf report即可查看火焰图
   
   查看容器内进程热点，发现我方容器环境中的进程大量CPU被libsuncc.so椭圆计算使用（主要用于HTTPS/TLS握手），结合业务会使用https访问obs，进一步定位可能是使用https短链接访问obs。在容器内查看443链接数，压测过程中观察到我方容器中有1w多个https链接，而友商环境中只有少量ESTABLISHED链接；在我方容器中抓包obs 443端口报文，进一步明确我方环境容器业务代码访问OBS使用https短连接，友商使用https长链接，导致压测过程中，大量CPU被https tls握手消耗，造成性能劣化。

解决方式：客户开发同事侧查看OBS SDK的代码发现，对接我方obs部分逻辑每次上传文件都会创建一个新的client，与友商的使用逻辑不同，优化后重新500并发压测结果略优于友商。