[发明专利]压测过程中的流量调度方法、调度平台和调度系统

说明书

技术领域

本申请涉及互联网技术领域，特别涉及一种压测过程中的流量调度方法、调度平台及调度系统。

背景技术

压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。一个业务线的压测需求通常称为一个压测方案，例如，天猫首页为待压测对象，需要对其压测1000每秒查询数(QPS)，就是一个压测方案。压测方案通常由压测引擎执行，压测引擎可以部署在物理机上，压测引擎上安装的多个应用程序APP可以模拟客户端执行压测方案，即模拟客户端向待压测对象发起访问请求。假设一个压测方案是在1秒内1000个APP模拟客户端向天猫首页发起QPS请求，具体的，压测引擎上的各APP模拟客户端访问天猫首页上的功能链接天猫超市，或，点击天猫首页上的图片链接访问店铺，等等，该一次访问或点击等操作即为一次查询。通常，一个压测方案需要多个压测引擎同时发起QPS请求。

发明内容

但是发明人在研究过程中发现，物理机的性能和资源是有限的，在压测引擎上各APP模拟客户端产生的访问流量过大的时候，可能会出现压测引擎无法正常执行压测方案的情况，此时压测引擎按照压测方案发起的QPS请求将无法匹配该压测方案，即实际发起的QPS请求无法达到在压测方案中预先设置的目标QPS请求的情况。这就会使得压测方案无法真实模拟线上用户请求峰值，在实际中如果线上用户请求在同一个时刻海量增加，将会导致实际中应用服务器由于用户请求过多而崩溃，不仅会给应用服务器带来无法弥补的性能和资源损失，还会影响用户体验。

基于此，本申请提供了一种压测过程中的自动流量调度方案，用以在压测过程中自动对满足流量调度条件的压测引擎上各个APP产生的流量进行调度，从而使得压测过程中各个压测引擎能够正常执行压测方案，真实模拟同一个时刻海量增加用户请求的实际场景，例如大促，从而减少用户请求增加过多给应用服务器带来的性能和资源损耗，并且提升用户体验。

本申请还提供了一种调度平台和调度系统，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本申请公开了一种调度方法，该方法应用于与多个压测引擎相连的调度平台上，所述多个压测引擎执行同一个压测方案；该方法包括：

在所述多个压测引擎执行所述压测方案的过程之后，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；

根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，如果是，则将待调出流量的异常压测引擎上的流量，按照预设调度方案调整至正常压测引擎上。

其中，所述流量调度参数包括：所述压测引擎的每秒查询率、CPU利用率和/或平均响应时间，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，包括：

判断所述压测引擎的实际每秒查询率是否与预先设置的目标每秒查询率匹配；

判断所述CPU利用率是否表示所述压测引擎的健康状态较差；和/或，

判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢。

其中，所述判断所述压测引擎的实际每秒查询率是否与目标每秒查询率匹配，包括：

判断所述压测引擎的目标每秒查询率与实际每秒查询率的差值是否大于预设查询差值。

其中，所述判断所述CPU利用率是否表示所述压测引擎的健康状态较差，包括：

判断所述压测引擎的CPU利用率是否大于预设利用阈值。

其中，所述判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢，包括：

判断所述压测引擎的平均响应时间是否大于预设响应阈值。

其中，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，还包括：

判断待调出流量的压测引擎的个数是否小于所述多个压测引擎的总个数的一半。

其中，所述获取所述多个压测引擎相关的流量调度参数之前，还包括：

判断所述压测方案的连续调度次数是否小于预设次数阈值，如果是，则执行所述获取所述多个压测引擎相关的流量调度参数的步骤。

其中，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度之前，还包括：

判断所述压测引擎的目标每秒查询率是否产生了变化，如果否，则执行所述根据所述压测引擎的性能判断所述多个压测引擎是否需要进行流量调度的步骤。