最近在某云服务上做了一次接口压测，发现了许多需要注意的点，整理一下，备忘。在下非专业测试人员，欢迎指正：
一、基准环境准备
准备一套知根知底基准的环境，用于和云服务上的虚机做对比，让自己可以做到心中有数。可以是虚机。注意两套环境尽量保持一样的基本配置，如cpu性能、内存大小。
二、测试工具准备
压测应该从基准测试开始，分三个维度展开。
硬件基准测试：主要包括CPU性能、内存读写性能、磁盘读写性能、网络读写性能和带宽，可选的工具如sysbench、fio等
中间件基准测试：如redis、kafka、mysql等，此类中间件网上基本可以通过关键字【中间件名 benchmark】搜到对应的工具
框架和业务程序压测：框架即所用到的研发框架，程序代码剥离了业务处理后的部分。这里我们主要是http方式访问的接口，用到的主要是jmeter、Apache Benchmark、wrk
其中前两个基准测试主要用来调整硬件环境，发现可能存在的环境问题；框架压测可以用来发现研发框架的一些潜在性能问题。
三、测试方法和注意事项
1、关注服务端：压测是为了找出瓶颈，这个瓶颈可以是cpu的性能（计算）、网络和磁盘（IO）性能等环境上的，也可以是程序的业务逻辑上的。不论如何，压测时一定要将服务端的硬件使用情况监控起来
2、关注客户端：压测时注意客户端的资源如cpu、带宽等是否已经到了上限，如果到了上限应该及时提升配置，或者做客户端集群（jmeter集群需要大量的带宽用来同步每个agent的压测结果，需要格外注意），最后，还要特别留意你的客户端脚本性能有没有问题。
3、关注程序业务逻辑：对于业务程序，首先需要梳理接口的整体逻辑，比如在什么情况下进行了几次IO
4.1、善用排除法为结论背书：排除法也是压测过程中一个重要的手段，如果基本推断到某个地方非常影响性能，可以通过一些手段跳过这个地方的执行，看看性能是否能上来，以此证明你的结论。
4.2、为你的想法背书，而非想当然：
比如，对于网络——如果你认为你压测过程中使用的是HTTP长连接（keepalive），那么你关注服务端和客户端的各种状态的TCP连接数，确定真的是长连接；
比如，如果你认为硬件越多性能越高，那一定要通过压测证明一下，如，同时A压B，C压D，两个压测结果的和是不是单独A压B的两倍
另外，有一些东西是公论则可以不必去费功夫，因为已经有很多人在很多文章中为你背书了——比如kafka的磁盘顺序写等。
5、确保压测环境不被干扰：在云服务上压测，请确定你的服务器资源是独享型，否则压测基本没有什么意义。
6、压测报告务必详细：压测报告不只是给别人看的，更是你自己的工作证明，要详细的罗列用到的硬件，什么环境，压测过程中各个指标的状态，在各种参数情况下程序的吞吐量，压测报告直接反应了一个人的能力，因为你能力越强，你看到的关键参数越多。
打个比方，从前我只关心cpu和内存，所以我做的压测报告里会有这些数据；后来我了解了HTTP长短连接的区别、网络等知识，报告内容有所增加；再后来我发现磁盘也会成为某些程序的瓶颈，磁盘IO也成了压测报告中的内容……
四、一些主观观点
1、压测以及压测结果分析非常考验一个人的综合能力，包括知识面、分析问题的能力、对整体架构的掌握程度以及对用到的各个中间件的原理的掌握等，绝非简单跑个脚本就完事。
2、我相信在压测这个事上，不管一个人的能力多么强都是不够强的，知识多么多都是不够用的，一定要量力而为。
3、只要通过一定的努力，提高了程序的性能，那就是有效果的，如果追求完美那么时间多半是不够用的。
（实战内容有时间再补充吧，完毕）
补充，实践得出的真知：
一个系统的吞吐，取决于用到的所有中间件的基准测试得出的吞吐能力的最小值，并且不会达到这个最小值。
得出结论，一定要有证据支撑。