ab压力测试_逃不开的压力测试

1 压力测试

618将近，看似一切都在有条不稳的进行着。但其实618的备战在5月份就已经打响了(我真真切切感受到的是从这个时候开始的，或许开始的时间比5月更早)。首先最先开始的就是压力测试，每一年的大促不管是618还是双十一，压测都是不可或缺的一部分。今天就记录一下我接触的压力测试。

2 不一样的压测

一般在中小型互联网企业中，压力测试不外乎是使用Jmeter，LoadRunner，AB等等的工具。我对这些工具有一个简单的了解，但是在真实的工作中并没有使用过这些工具，因为公司有自己的一整套标准的压力测试的流程。我们这一次不会去讲这些工具如何使用，而是来说一下通过这次参加618大促的压测总结的一些知识。

3 压测过程

3.1 压测开始

在压力测试真正的开始之前，首先会编写要进行压力测试的脚本。通过脚本去模拟真实的用户请求接口，通过不断的增加这个脚本的执行来达到预期的TPS值。在618压测时，是分两种情况的：第一种是可以拿到服务端JSF接口的jar包的；第二种就是在编写压测脚本的时候拿不到jar包的。在第一种的情况下，在调用接口时，可以直接通过new的方式来完成调用接口，之后可以通过实例化出的对象直接调用方法来完成请求。在第二种情况下，是无法直接调用接口服务的，在这种情况下可以通过dubbo的泛化调用来完成接口和方法的调用。这里贴出一些dubbo的泛化调用的主要代码：

通过spring方式实现：Spring 配置申明 generic="true"：

在 Java 代码获取 barService 并开始泛化调用：

GenericService barService = (GenericService) applicationContext.getBean("barService");Object result = barService.$invoke("sayHello", new String[] { "java.lang.String" }, new Object[] { "World" });

以上就是在压测前期需要准备的，接下来就可以开始压测了。

3.2 压测进行中

在压测进行中时，之后的工作主要是一个体力活了。在刚刚开始时先给一个初始值的并发值，然后在依次的向上添加并发数，一直达到压测开始之前设定的目标值，然后观测一段时间。比如你在压测开始之前设定的目标值是1W的TPS，那么你就需要在压测的过程中，慢慢的向这个值去靠拢。同时需要关注TPS波动变化，可以通过TPS变化来检测压测的接口是否有问题。TPS波动越大，接口就表示有问题，这时候服务该降级的就降级，该熔断的就熔断；TPS越平稳，接口出问题的概率越小。当压测的TPS值达到我们预期时，我们跑一段时间没有太大的波动的话，压测就可以告一段落了。

3.3 压测结束

当压测结束时，需要第一件事做的就是记录重要的节点信息。可以把在压测过程中出现的相关问题接口记录一下，比如是哪个接口在压测过程中，引起的TPS的抖动，那么就需要把这个接口记录下来，方便之后去优化。接着就可以去整理压测报告了，报告里面需要体现的点有：测试是否通过， 这也是第一点需要交代的，接着就可以把在压测过程中出现的问题接口，或者发现的的问题都描述一下，最后就可以放一些压测时候的截图，例如TPS的截图，TP99的等等。到这里我们的压测就可以结束了。

4. 总结

以上就是我对压力测试的一些简单的总结，或许有说的不对的地方，也希望大家可以给出建议，我们可以一起交流和学习。对于我来说，真的有太多太多需要学习的地方了，但是每段时间都有简单的收获也是不错的。大家一起加油吧！