最近实施了一个针对某开源软件的压测方案。借这次机会，尝试梳理了自己在考虑和实行压力测试方案时，想到的一些内容，作为思考笔记。
Table of Contents
压力测试，之前曾零散地了解过一些基础的测试方法，比如机器硬件的 benchmark，一些微服务的全链路压测等。
但是自己想想，如果尝试挑战自己的方案，问道具体的问题，比如：" iowait "到底是什么？ 仿佛也只能含含糊糊讲不清楚。
借这次机会，尝试系统地梳理了自己考虑和实行压力测试方案时，想到的一些内容。
本篇笔记不会事无巨细，比如介绍某一块 linux 的网络细节知识，但是会记录笔者在做方案时候的一些思考路径，加入和同事交流请教得到的一些建议。
1 了解背景和目的
这次的背景，主要是找到某开源软件的瓶颈所在，并项目评估下一步应该进行的动作。
了解背景和目的可能比较重要，根据不同的目的有不同的颗粒度和观察角度，直接影响了后续的准备和条件设置。
- 本次压测的规模多大？是单物理机极限性能还是集群性能？
- 涉及到微服务全链路还是单软件极限性能？
- 涉及多部门还是本组内部？
- 压测的结果是用于找出自研软件瓶颈，还是技术选型？
- 根据该软件使用的场景，应重点关注哪些指标和能力？
2 环境准备模拟
运行环境准备
本次指定的是单台物理机上的极限性能。在准备承压机器环境时考虑以下的因素(有一些需要和SRE同学沟通确认)
- 网络层面
- 如极限带宽、网卡bond方式等
- 性能层面
- 对机器 cpu、内存、硬盘进行 benchmark，确认没有离谱的环境性能瓶颈。
- 操作系统层面
- 统一基础的高并发优化，比如最大文件打开数、tcp 拥塞控制算法、软终端设置等。
这些方面我都做了统一的 benchmark 和确认，记录在了测试报告的附录中，确保大家 review 时候可以追溯。
还有一点可能常见但容易被忽略，就是确认把机器当做玩具时候，不会影响到线上的实际业务(容易造成血泪教训)。
施压测准备
- 选择合适的施压软件
- 比如如果是业务型，需要高 QPS 的施压
- 而网络性能类，可能更加关注带宽
- 指定合适的请求模拟
- 根据实际需求，构建模拟的请求即可。发现并不是耗费很多精力重现真实数据，就收益越高。但一定可解释、比较合理。
- 关注施压测的性能
- 由于要建立海量的 TCP 链接，也要关注施压测是否达到网络连接或者性能瓶颈
- Tip: 有一些细节如果有疑惑，我尝试花一些时间弄明白原理。我在这里参考了一些建立大量 tcp 的文章，明确了原理和实践，心里会更加有数。 比如 ref : 一台主机上只能保持最多 65535 个 TCP 连接吗？ https://www.zhihu.com/question/361111920/answer/1828767342
- 这次更加详细的一些参考文章我列在了后面
承压测准备
- 被压测的软件持续调优
- 也应该对被压测的软件进行调优，最好是参考线上已有的设置。
3 方案的实施
case 设计
case 设计比较重要，主要是根据软件，控制变量法设计多组 case，来找出瓶颈所在。
日志和性能指标收集
- 应当设置有详尽的机器性能 metrics 和软件的性能日志以供回溯
- 明确性能指标的含义
- 一旦有概念模糊的指标，就可能需要用一些时间去弄明白其中的原理。一个比较好的评判标准，就是自己从各个方面挑战自己一下，看看作为方案制定者，能够对答如流吗？
不断改进
我在进行方案设计时候，是一遍动手搭建实验环境一遍拟定。因为确实有好多问题只有在实际机器上才能发现和想到。
发现之前方案有问题时候及时修正，或者发现有容易修复的配置问题时，也可以一遍压测一遍修正。
4 结论报告
暴露关键性能指标
大家 review 的话，把一些关键的指标和推测的结论明确地展示出来。但同时在别的地方要保留 metrics 和细节以供讨论。
缺陷和问题
根据精力和准确度相互制约，压测会有一些简化的环境和模型在其中。一轮报告可能是有一些缺陷或者不准确的。可以讨论修正，再次安排测试。
5 涉及到的一些技术参考
个人觉得，现代软件工程依托的内容是是海量的，自己若能遵从一定程度的脉络，明确关键概念就已经很好了，不能陷入浩如烟海的细节中。
Linux 优化知识图谱
这个是学习极客时间专栏《 Linux 性能优化》中提供的知识图谱。个人觉得脉络非常清晰，在这次中充当了工具书的作用——哪里不太明确就查哪里。
Linux 性能工具图谱
在终端命令中，适应了使用强大的 Linux 工具直接进行性能分析，对整个系统的认识，颇有帮助。
系统性能相关
- Linux CPU使用率概念 (iowait等)
- What does ksoftirqd do ?
网络相关
- 百看不如一练，测试单机百万连接两种方案的源码
- 一台机器最多能撑多少个TCP连接? 今天掰扯清楚！
- 图解Linux网络包接收过程
推荐《开发内功修炼》专栏，将网络部分讲的非常详细
本文小结
本文为笔者的一次思考笔记，如果能给读者带来启发，会非常荣幸。如果有纰漏之处，也请读者直接指出，笔者新手上路，也会多多学习!
你好，仔细阅读了您的这篇文章，请问文中提到的<span>测试报告的附录在哪呀</span>
@sjy 哦哦，这部分是指对物理机性能摸了个底，放到公司项目的测试报告附录里了。
其实摸了下 CPU、网络、磁盘。
CPU 用公开的 cpu benchmark 脚本，网络主要是内网机器的极限带宽和包转发率，磁盘主要是顺序读写和 4K 随机读写。
@sjy 有了这些指标，再和项目实际性能对比。主要目的是确认一些 OS 层面或者硬件层面的因素，没有影响到自己的测试结果。
如果辛辛苦苦压了好几天，最后发现 OS 某项设置没放开，就尴尬了