压力测试的一点思考

最后工作中的项目，接近上线了，做了个完整的压力测试过程，对于压力测试，整个项目下来，有些自己的理解，这里简单总结如下：

压测的目的

1、检查系统是否要求业务需求，拿到系统的一些性能指标。

一般情况下，例如峰值是1W/s的系统，压测的时候，需要能扛上2W/s基本就能满足要求（特殊业务可能另作评估）。并且输出压测报告，拿到一个对系统的量化指标，做到一切心中有数。

2、发现系统存在的问题。

很多情况下，普通的案例测试，无法发现系统的问题，能够在压测的环节中发现出来。例如：内存泄漏、系统的并发问题，系统的性能瓶颈等。

在这个阶段，尽量先克服其他的障碍，目的是先尽可能多的发现问题（可以不阻碍系统压测的问题，都先放着，否则项目时间会被拖得很长）。

系统调优

1、以系统性能目标为准，划定优化边界。

调优是一个没有终点的过程，作为架构者，需要自己心中有一把称，权衡哪些问题必须优先在项目周期来到之前解决，有些看似也是性能问题，但并不影响系统如期上限，则往后排期解决。

2、按优先级顺序解决性能问题，抓大放小。

先能过压测过程，找到系统性能瓶颈所在，CPU、IO、网络、内存等。需要有比较好的理论基础和工程素养去预估问题的大小及解决时间，优先解决性价比较高的问题。结合项目期限，尽可能在上线之前达到性能目标。

压测指标

1、QPS

这个是系统的每秒请求数，这个可以通过并发来提升（可用多线程方式）。

2、并发数

3、耗时

压测工具从发包开始，到收到回复的时间，就是该笔请求的耗时。

4、CPU利用率

5、内存占用（主要关注被压测服务的内存占用和总的机器内存的变化情况）

注意：

QPS必须与耗时相关联，否则没有实际意义。

例如：例如某登录服务，产品层面要求不能让用户等待超时3秒钟。

该登录系统测试时QPS可以压到1K/s，但用户耗时已经长到5S才返回，这样的QPS值，对业务已经没有意义。所以不能脱离耗时谈QPS。

并发数，这里可以用来模拟实际的用户给到系统压力。例如1个并发，压100QPS，与10个并发，每个并发压10QPS，给到系统的压力可能不同，这与具体系统的内部实现相关，要根据具体的业务场景及用户来设计方案。

压测工具

尽量选择现有的开源方案进行二次开发，尽量避免重复造轮子的浪费。如果说CPP的生态圈中没有现成的工具使用，那可以看看JVM生态，或者新兴的GO生态中，有没成熟的工具使用。自己在这个问题上，犯了个小错误。自己花了几天时间写了个简单的C++的工具来使用。另一个同事，使用成熟的jmeter，写了1百行左右的代理，并通过插件的形式，同样完成了一个压测工具的搭建。

1、如果在学习研究上，自己写工具来使用，这没有问题，能促进能力的提升。

2、如果是在工程上，则不建议这种做法。尽可能选择业界成熟的方案来做二次开发，有两个好处：

1）工作量降低很多，通用的需求，前人已经帮你做好，你直接使用即可，只需要自己实现个性化需求。

2）可靠性。自己短时间内写出来的工具的可靠性，肯定不如前人长时间打磨出来的，使用过程中因为工具的不稳定导致去查错，这就非常浪费时间了。