一次压力测试的小结笔记

最近实施了一个针对某开源软件的压测方案。借这次机会，尝试梳理了自己在考虑和实行压力测试方案时，想到的一些内容，作为思考笔记。

压力测试，之前曾零散地了解过一些基础的测试方法，比如机器硬件的 benchmark，一些微服务的全链路压测等。

但是自己想想，如果尝试挑战自己的方案，问道具体的问题，比如：" iowait "到底是什么？仿佛也只能含含糊糊讲不清楚。

借这次机会，尝试系统地梳理了自己考虑和实行压力测试方案时，想到的一些内容。

本篇笔记不会事无巨细，比如介绍某一块 linux 的网络细节知识，但是会记录笔者在做方案时候的一些思考路径，加入和同事交流请教得到的一些建议。

1 了解背景和目的

这次的背景，主要是找到某开源软件的瓶颈所在，并项目评估下一步应该进行的动作。

了解背景和目的可能比较重要，根据不同的目的有不同的颗粒度和观察角度，直接影响了后续的准备和条件设置。

本次指定的是单台物理机上的极限性能。在准备承压机器环境时考虑以下的因素(有一些需要和SRE同学沟通确认)

这些方面我都做了统一的 benchmark 和确认，记录在了测试报告的附录中，确保大家 review 时候可以追溯。

还有一点可能常见但容易被忽略，就是确认把机器当做玩具时候，不会影响到线上的实际业务(容易造成血泪教训)。

选择合适的施压软件
- 比如如果是业务型，需要高 QPS 的施压
- 而网络性能类，可能更加关注带宽
指定合适的请求模拟
- 根据实际需求，构建模拟的请求即可。发现并不是耗费很多精力重现真实数据，就收益越高。但一定可解释、比较合理。
关注施压测的性能
- 由于要建立海量的 TCP 链接，也要关注施压测是否达到网络连接或者性能瓶颈
- Tip: 有一些细节如果有疑惑，我尝试花一些时间弄明白原理。我在这里参考了一些建立大量 tcp 的文章，明确了原理和实践，心里会更加有数。比如 ref : 一台主机上只能保持最多 65535 个 TCP 连接吗？ https://www.zhihu.com/question/361111920/answer/1828767342
- 这次更加详细的一些参考文章我列在了后面

case 设计比较重要，主要是根据软件，控制变量法设计多组 case，来找出瓶颈所在。

应当设置有详尽的机器性能 metrics 和软件的性能日志以供回溯
明确性能指标的含义
- 一旦有概念模糊的指标，就可能需要用一些时间去弄明白其中的原理。一个比较好的评判标准，就是自己从各个方面挑战自己一下，看看作为方案制定者，能够对答如流吗？

我在进行方案设计时候，是一遍动手搭建实验环境一遍拟定。因为确实有好多问题只有在实际机器上才能发现和想到。
发现之前方案有问题时候及时修正，或者发现有容易修复的配置问题时，也可以一遍压测一遍修正。

大家 review 的话，把一些关键的指标和推测的结论明确地展示出来。但同时在别的地方要保留 metrics 和细节以供讨论。

根据精力和准确度相互制约，压测会有一些简化的环境和模型在其中。一轮报告可能是有一些缺陷或者不准确的。可以讨论修正，再次安排测试。

个人觉得，现代软件工程依托的内容是是海量的，自己若能遵从一定程度的脉络，明确关键概念就已经很好了，不能陷入浩如烟海的细节中。

这个是学习极客时间专栏《 Linux 性能优化》中提供的知识图谱。个人觉得脉络非常清晰，在这次中充当了工具书的作用——哪里不太明确就查哪里。

在终端命令中，适应了使用强大的 Linux 工具直接进行性能分析，对整个系统的认识，颇有帮助。

推荐《开发内功修炼》专栏，将网络部分讲的非常详细

本文为笔者的一次思考笔记，如果能给读者带来启发，会非常荣幸。如果有纰漏之处，也请读者直接指出，笔者新手上路，也会多多学习!