在云服务上做接口压测心得总结

最近在某云服务上做了一次接口压测，发现了许多需要注意的点，整理一下，备忘。在下非专业测试人员，欢迎指正：

 

一、基准环境准备

准备一套知根知底基准的环境，用于和云服务上的虚机做对比，让自己可以做到心中有数。可以是虚机。注意两套环境尽量保持一样的基本配置，如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、只要通过一定的努力，提高了程序的性能，那就是有效果的，如果追求完美那么时间多半是不够用的。

 

（实战内容有时间再补充吧，完毕）

 

补充，实践得出的真知：

一个系统的吞吐，取决于用到的所有中间件的基准测试得出的吞吐能力的最小值，并且不会达到这个最小值。

得出结论，一定要有证据支撑。

 

2020年10月23日补充

网络延迟在一些同步阻塞场景下，也会对性能造成比较大的影响，现象就是cpu、磁盘、带宽等 都没有达到瓶颈，但是性能却上不去，这种，只能提高并发数来提高利用率。

 

2020年10月24日

java，c和redis

客户端：对于一个连接java每秒能发的请求数量和c发请求的能力不一样

服务端：redis连接数越多性能越低

所以当客户端java向服务端redis发请求时，连接数存在一个最优值，高或者低性能都不是最高点

所以redis-benchmark和jedis压测结果不一致