我是阿里云弹性计算性能测试负责人西邪。

我从 2018 年开始组建阿里云弹性计算的性能测试团队，从要一周完成一组性能测试，到只需 1 分钟就可以触发一组全自动性能测试，到最后结果整理一键搞定，内部命名为开天斧。

现在开天斧已经承担整个弹性计算所有的性能测试工作：新技术、新设备、新规格等等，保证了线上的性能稳定性。在性能测试的同时，还要负责解决客户的性能问题。期间还负责了“变形金刚”这个项目，把物理机的底层资源管理产品化了，使得现在线上千变万化的规格，只需一个模板就可以简单实现。

这里就先跟大家分享下这 3 年在性能测试上的一些收获。

什么是性能测试？

性能测试不同于功能测试，功能测试验证的是某个功能是否完成，性能测试验证的是某个性能是否达到。

验证性能就需要很多性能“标尺”，如衡量 CPU 性能：通过 SPEC CPU，UnixBench 等；衡量网络性能用 netperf，iperf，sockperf 等等；衡量存储性能最好用的是 fio，衡量内存带宽性能则是 stream。

上述说的都 micro Benchmark，通常如果某块做的不好，就可以直接提缺陷给相关的团队去优化；而客户实际感知的是真实业务场景，那就需要去模拟客户的场景，比如客户经常使用的是 nginx，redis，MySQL 等，通过实际的场景测试，来验证当前服务器的优劣。通过做好性能测试，才能建立自己的底气，做好性能分析，才能知道哪里薄弱，从而往哪里发力！

性能测试要做哪些？

性能的重要性无需多言，我就直接略过了。一个服务器有 5 大块：CPU、内存、存储、网络、OS。对，就是验证这些模块的性能，上面也简单介绍了下该用哪些工具进行性能测试。但是对于性能测试而言，如果仅仅是一个测试，那太简单了，实际上还需要考虑很多。

性能主要可以看以下几个方面：

1. 用什么工具来验证？性能测试的完备性如何保证？如何快速持续构建性能测试，手工跑就直接废了，工程化如何构建？
2. 性能测试怎么设计？如何针对性去设计？性能测试其实是去测试一个预期。
3. 出来的性能数据怎么分析，重点关注哪个？
4. 性能有差异？为什么有差异？虚拟化问题，物理机问题，OS 问题，Benchmark 问题？还是...
5. 如何去分析异常性能数据？这个问题一般是通用业务团队的架构师才能解。

可能光谈问题还是抽象了点，我再具体举几个例子。

先谈与 CPU 相关：

● Intel、AMD、ARM 差异？指令差异

● CPU 不同代数差异

● CPU 主频、基频、睿频、P0-n、P0-1

● CPU 是否 PIN 住

● 超线程开关：底层开关、OS 开关

● NUMA 架构：membind、interleave...

● 电源策略: performance、powersave、C-State 联系

● TDP: 睿频不符预期时看下 TDP 是否限制住了，很有用！

● L3 Cache 大小

● 内存带宽、内存时延

● OS：内核版本、CPU 漏洞开关

● CPU 微码

● 软件：glibc 版本等

● 不同版本、特殊编译器：AOCC、icc

上面的这些都是 CPU 需要具备的基础知识，甚至还需要深入底层去看问题，比如看底层 CPU 的 PMU 相关的一些东西。同样其他模块知识也是必不可少的。

除了知识具备外，每个模块测试完备性也很重要，比如分析网络性能数据，重点看下面这些性能：

● 网络带宽：多流、单流

● 网络 PPS：多流、单流

● 网络 session 连接数

● 网络新建连接数

● 网络时延

● 网络长连接、网络短连接性能

● 网络并发性能：上述性能在多个机器的情况下，并发效果能否延续

● 网络性能稳定性：网络压力变大（pps 变大或者带宽变大或者 session 数变大），时延的稳定性

● 网络丢包率、重传率

网络性能数据出来后，那这些数据又怎么看呢？下图是一个常见分位图：

绝大多数情况，在分析定义一个数据的时候，不能单单看 min、average、max，倒是分位数性能数据非常重要，还有波动率。

如果这些问题你都能很好回答，想必你就是一位功力深厚的大侠了。

为什么性能测试没那么简单？

性能测试如果仅仅是一个测试，还算简单。当然复杂的测试也很复杂，比如干扰测试（模拟吵闹邻居）。但总的测试而言，就是一个工程自动化，效率提升的手段。

那难在哪里？

难在上节的话题能否执行到位。比如内存时延，在 Intel 的 CPU，整机情况下是 2 个NUMA NODE，底层是 2 个 CPU，那么需要考虑当前 Node 的内存时延，以及跨 Node 的内存时延。知道这些后，那么后面应用表现出来的现象才可能有相关解释。

举个例子，把一个性能测试步骤分解开来，如下：

这里只有一个环节：test 环节，需要的功力浅。这存在一个误解，很多人以为性能测试就是 “test” 这一环节，当然不是！

breakdown，design，analyse，如果不是一个经验丰富的性能工程师，怎么可能 breakdown，desgin，甚至 analyse。

举个例子：Intel Cascadelake CPU 性能测试。breakdown 的时候，你需要很多背景知识，这些背景知识会决定你后面的性能分析预期。

1. 与 Skylake CPU 的区别：主频设置，CPU 代数差异等。
2. 虚拟化方案：是否 PIN 住，是否跨 Socket。
3. 底层技术适配：网络存储有无优化。
4. 实例形态：有哪些规格，CPU 如何绑定。

等等......

接下来是性能测试，在测试一个系列的性能测试时，需要一套完整的性能测试方案，做个全方面的对比。这块业界只有 SPEC CPU，SPEC JBB，UnixBench 等一套成熟的 CPU 性能测试，但是没有完备服务器性能测试方案，这使得客户上云变得很迷茫，怎么全面衡量云服务器的性能呢？这些都需要积累丰富，并形成一个完整体系。

等到性能测试结束，就需要去做性能分析，之前讲了如何看网络性能数据，但有时也会有些奇怪的数据需要去解释。

举个实际例子：比如网络单流的性能测试。有时候会发现波动很厉害，起先以为是网络性能不稳定，后经过实际排查，发现有概率发生中断的 CPU 与网络进程所在 CPU 在同一个核的时候，性能就会非常差，通过 taskset 硬性隔离开，中断和网络测试进程分别在不同的 CPU 上，网络单流性能就上去了且稳定。

所以，性能测试难就难在知识储备够不够厚、能否充分理解业务性能、性能设计以及最终的性能分析，以及对于数据结果预期的确定等，这些都非一朝一夕之功！

那有什么破解之法呢？我认为主要有三点：

好学：如果把一个业务系统从上到下去分析，每一个都可以发展开来：业务架构、OS、一门语言、底层虚拟化、CPU 微架构都是值得学习。推荐《性能之巅》这本书，可以领你入门。

勤：每一个 Case 都是一次机会，值得好好去研究。

钻研：肯定会遇到问题，遇到问题不抛弃不放弃，发扬 Geek 精神！

性能测试人员需要具备的基本技能

文章最后，再分享下我认为性能测试人员应该具备的基本技能。

计算机体系知识：计算机组成原理、操作系统、编译原理、计算机网络、软件测试、Linux 内核分析... 大学的课程都需要了。不但要有书本知识，还能结合实际问题进行分析。

架构思维：任何一个需求，问题，都需要站在一个很高的位置去审视问题，去思考如何设计；特别是客户的问题，当前架构是否合理，出现这个问题有哪些方向。

自动化测试：如何把这些手工的测试自动化，是解放生产力必须的，同时才能轻松去完成线上巡检。针对特殊问题，还需要具备构建特殊的测试案例能力。

分析技巧：应该熟练掌握各种性能分析的工具：top、vmstat、mpstat、pidstat、iostat、sar、火焰图等，高阶如 BPF 技巧。

实际工作经验：这个在设计 Case 的时候太重要了，他知道什么要什么不要！

钻研精神：一个系统涉及的领域方方面面，从上层业务到底层实现，会遇到很多很多未知，需要潜心研究。

这可能有点虚，特别是架构思维，只有接触过很多很多的 Case，才能有些体悟。所以一般来说一个刚毕业的应届生是很难做好性能测试的。

举个例子：一般来说呢，会有很多的 micro Benchmark，比如测试网络 PPS、网络带宽等等，那这些对用户的实际影响是什么呢？很自然地想到，把用户的 Case 搬过来，这么简单的一句话，实际很难：用户的 Case 为什么要这么设计？每个 Case 背后是有业务架构师做了设计的。

用户的 Case 该怎么测试？客户实际是怎么压测的？服务器的压力应该定在哪里？那请问一个从没有从事过实际业务需求的人怎么知道这个是合理的？如果有这么一帮人在设计用户的 Case 性能测试是不是很搞笑。所以如果要做真实的案例性能测试，必须是有一线作战经验的同学，他知道怎么样的压力是最合适的，他知道这个服务器性能是否够，是不是要提升。

总结

综上，性能测试没那么简单，性能测试不单单是一个测试，他的要求远远高于一名测试人员，他是一名性能架构师，更是一名全能手！

最后，请记住一个好的性能工程师是喂出来的，他要经历千锤百炼，方有锐剑出鞘！共勉。