CN116860657B - 压测控制处理方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种压测控制处理方法、装置、设备和存储介质。所述方法包括：获取检测到的压测处理请求对应的压测对象和各初始压测参数，基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，根据确定发包时间确定逻辑确定对应压测模式的发包时间间隔。根据与压测对象对应的配置信息进行参数初始化处理，获得初始化后的各运行参数，根据初始化后的各运行参数触发发包协程，按照所确定出的发包时间间隔在预设压测周期内向压测对象进行压测发包处理，并获取与压测对象对应的压测处理结果。采用本方法能够按照所确定出的实际的压测模式的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理，提升压测发包处理效率。

Description

压测控制处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机处理技术领域，特别是涉及一种压测控制处理方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

随着计算机处理技术的发展，以及各类服务器或***等在不同应用程序或平台的广泛应用，为保障应用程序或平台的稳定运行，为海量使用对象提供所需目标服务，需要针对服务器或***等，进行模拟压测，以获得对应的压测性能数据，从而可根据压测性能数据，完善服务器或***所提供的服务业务，实现服务性能提升。

传统技术中，通常采用基于已有的PTS平台（即Performance Testing Service，理解为分布式压测平台）、或已有的locust平台（即分布式用户负载测试平台），来模拟海量使用对象的真实业务场景，对服务器或***进行压测的方式，来获得服务器或***在性能、容量和稳定性等方面的压测性能数据。

然而，传统上基于PTS平台、或locust平台进行压测的方式，通常会预先设置固定的发包速率，并在压测过程采用预设的固定发包速率进行压测发包处理，因此无法满足不同的压测场景的压测发包速率需求，仍然存在压测发包处理效率低下的问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提升压测发包处理效率的压测控制处理方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种压测控制处理方法。所述方法包括：

若检测到压测处理请求，获取所述压测处理请求对应的压测对象、和各初始压测参数；

基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔；

获取与所述压测对象对应的配置信息，并基于所述配置信息进行参数初始化处理，获得初始化后的各运行参数；

根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理；

获取与所述压测对象对应的压测处理结果。

第二方面，本申请还提供了一种压测控制处理装置。所述装置包括：

初始压测参数获取模块，用于若检测到压测处理请求，获取所述压测处理请求对应的压测对象、和各初始压测参数；

发包时间间隔确定模块，用于基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔；

参数初始化模块，用于获取与所述压测对象对应的配置信息，并基于所述配置信息进行参数初始化处理，获得初始化后的各运行参数；

压测发包处理模块，用于根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理；

压测处理结果获得模块，用于获取与所述压测对象对应的压测处理结果。

第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

若检测到压测处理请求，获取所述压测处理请求对应的压测对象、和各初始压测参数；

基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔；

获取与所述压测对象对应的配置信息，并基于所述配置信息进行参数初始化处理，获得初始化后的各运行参数；

根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理；

获取与所述压测对象对应的压测处理结果。

第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

若检测到压测处理请求，获取所述压测处理请求对应的压测对象、和各初始压测参数；

基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔；

获取与所述压测对象对应的配置信息，并基于所述配置信息进行参数初始化处理，获得初始化后的各运行参数；

根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理；

获取与所述压测对象对应的压测处理结果。

第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：

若检测到压测处理请求，获取所述压测处理请求对应的压测对象、和各初始压测参数；

基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔；

获取与所述压测对象对应的配置信息，并基于所述配置信息进行参数初始化处理，获得初始化后的各运行参数；

根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理；

获取与所述压测对象对应的压测处理结果。

上述压测控制处理方法、装置、计算机设备、存储介质和计算机程序产品中，在检测到压测处理请求时，获取压测处理请求对应的压测对象和各初始压测参数，以基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，以根据发包时间确定逻辑确定与不同压测模式对应的发包时间间隔。进一步地，通过获取与压测对象对应的配置信息，并基于配置信息进行参数初始化处理以获得初始化后的各运行参数，从而可根据初始化后的各运行参数触发发包协程，并按照所确定出的当前实际的压测模式的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理，提升了压测处理过程中的压测发包处理效率，而进一步通过获取与压测对象对应的压测处理结果，可准确获知各压测对象的服务性能。

附图说明

图1为一个实施例中压测控制处理方法的应用环境图；

图2为一个实施例中压测控制处理方法的流程示意图；

图3为一个实施例中与压测处理请求对应的各初始压测参数的界面示意图；

图4为一个实施例中确定与压测模式对应的发包时间间隔的流程示意图；

图5为一个实施例中与第一压测模式对应的发包时间间隔确定过程示意图；

图6为另一个实施例中确定与压测模式对应的发包时间间隔的流程示意图；

图7为一个实施例中与第二压测模式对应的发包时间间隔确定过程示意图；

图8为一个实施例中确定第二压测模式下的预期总请求数的流程示意图；

图9为一个实施例中在预设压测周期内向压测对象进行压测发包处理的流程示意图；

图10为一个实施例单个发包协程对应的协程执行过程示意图；

图11为另一个实施例中压测控制处理方法的流程示意图；

图12为再一个实施例中压测控制处理方法的流程示意图；

图13为又一个实施例中压测控制处理方法的流程示意图；

图14为一个实施例中压测控制处理方法的完整流程示意图；

图15为一个实施例中压测控制处理装置的结构框图；

图16为一个实施例中压测控制处理***的架构示意图；

图17为一个实施例中耗时变化场景下压测控制处理***自适应调整并发数的示意图；

图18为一个实施例中固定耗时场景下压测控制处理***的启动并发数示意图；

图19为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请实施例提供的压测控制处理方法，具体涉及计算机处理技术，可应用于云技术、人工智能、智慧交通、网络媒体以及辅助驾驶等各种场景，可具体应用于如图1所示的应用环境中。其中，终端102通过网络与压测服务器104进行通信。数据存储***可以存储压测服务器104需要处理的数据。数据存储***可以单独设置，可以集成在压测服务器104上，也可以放在云上或其他网络播控服务器上。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备、便携式可穿戴设备以及飞行器等，物联网设备可为智能音箱、智能电视、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。压测服务器104可以是独立的物理播控服务器，也可以是多个物理播控服务器构成的播控服务器集群，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云播控服务器，终端102以及压测服务器104可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不对此进行限制。

其中，终端102和压测服务器104均可单独用于执行本申请实施例中提供的压测控制处理方法，终端102和压测服务器104也可以协同执行本申请实施例提供的压测控制处理方法。举例来说，以终端102和压测服务器104协同执行本申请实施例提供的压测控制处理方法为例，若压测服务器104检测到基于终端102触发的压测处理请求，则获取压测处理请求对应的压测对象、和各初始压测参数，并基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，意根据发包时间确定逻辑确定与对应压测模式的发包时间间隔。进一步地，压测服务器104通过获取与压测对象对应的配置信息，并基于配置信息进行参数初始化处理，获得初始化后的各运行参数，以根据初始化后的各运行参数触发发包协程，从而可按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行压测发包处理，来获取与压测对象对应的压测处理结果。其中，获得的压测处理结果还可反馈至终端102进行展示，以供开发人员或测试人员查看相应的压测处理结果。其中，压测对象、各初始压测参数、压测模式、发包时间确定逻辑、以及与压测对象对应的配置信息等数据，可存储在压测服务器104的云端存储中、或数据存储***中、或终端102的本地存储中，当需要进行压测控制处理时，可从压测服务器104、或数据存储***、或终端102中获取。

在一个实施例中，如图2所示，提供了一种压测控制处理方法，以该方法应用于图1中的压测服务器104为例进行说明，包括以下步骤：

步骤S202，若检测到压测处理请求，获取压测处理请求对应的压测对象、和各初始压测参数。

其中，压测处理请求表示压测服务器104检测到的基于终端102针对应用服务器、应用***或应用平台等压测对象，所触发的压力测试处理请求，可以理解为在压测服务器104检测到使用对象或开发人员等，基于终端102触发的压测处理请求时，压测服务器104可通过模拟使用对象触发海量请求目标服务的方式，对应用服务器、应用***或应用平台等进行压力测试，获得相应应用服务器、应用***或应用平台的压测性能数据，比如应用服务器或应用***等的服务内存占用率、以及可同时提供目标服务的最大并发请求数等性能数据。

初始压测参数表示与压测处理请求对应的输入参数，具体包括输入的爬坡时间、压测时间、预设压测周期、初始发包速率、以及目标发包速率等数据。其中，爬坡时间可以理解为压测处理过程中的预热时间，也可以理解为匀加速时间，在爬坡时间内压测处理过程中的发包速率不断提升，而压测时间可以理解为压测过程的当前持续时间。初始发包速率可以理解为开始压测处理时的最小发包速率，可根据实际需求进行调整和设置，而目标发包速率表示预先设置的发包速率，即压测处理过程中需要达到的稳定发包速率或最大发包速率。

具体地，通过检测针对服务器、应用***或应用平台等压测对象所触发的压测处理请求，若检测到压测处理请求，则获取压测处理请求对应的压测对象，即具体是服务器、或应用***、或应用平台等压测对象，并获取压测处理请求携带的各输入参数，包括爬坡时间、压测时间、预设压测周期、初始发包速率、以及目标发包速率等参数。

步骤S204，基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据发包时间确定逻辑确定对应压测模式的发包时间间隔。

其中，通过对初始压测参数中的爬坡时间是否为空进行判定，来确定当前的压测模式。具体来说，若确定爬坡时间为空，即并未设置匀加速阶段时，表明当前为第一压测模式，而若确定爬坡时间不为空，即设置有匀加速阶段时，表明当前为第二压测模式。

第一压测模式未设置相应的匀加速阶段，压测处理过程中的发包速率即为初始发包速率，可以理解为秒杀模式，其适应于积分兑换、优惠券发布、现金券发布等场景下的压测处理，可根据积分兑换、优惠券发布、现金券发布等场景的服务需求，持续进行发包压测处理。而第二压测模式设置有匀加速阶段，压测过程中发包速率不断增加，从初始发包速率增加至目标发包速率后，稳定在目标发包速率进行压测发包处理，可以理解为爬坡模式，其适应于***预热、服务定量分析等场景下的压测处理，可根据***预热、服务定量分析等场景下的服务需求，在爬坡时间段内加速进行压测发包处理，并在爬坡时间结束后稳定在目标发包速率进行压测发包处理。

具体地，若确定爬坡时间为空，确定匹配的压测模式为第一压测模式，并根据与第一压测模式匹配的第一发包时间确定逻辑，确定第一压测模式对应的发包时间间隔。相反地，若确定爬坡时间不为空，则确定匹配的压测模式为第二压测模式，则根据与第二压测模式匹配的第二发包时间确定逻辑，确定与第二压测模式对应的发包时间间隔。

进一步地，在压测模式为第一压测模式时，通过获取与第一压测模式匹配的第一发包时间确定逻辑，并根据第一发包时间确定逻辑确定第一压测模式下的预期总请求数，通过获取压测过程中的当前实际总请求数，在确定当前实际总请求数不小于预期总请求数时，则进一步确定出第一压测模式下的单个请求耗时，以基于根据当前实际总请求数、第一压测模式下的单个请求耗时以及当前压测时长，确定与第一压测模式对应的发包时间间隔。

同样地，在压测模式为第二压测模式时，通过获取与第二压测模式匹配的第二发包时间确定逻辑，并而根据第二发包时间确定逻辑确定第二压测模式下的预期总请求数，通过获取压测过程中的当前实际总请求数，若确定当前实际总请求数不小于预期总请求数，则进一步确定第二压测模式下的单个请求耗时，以根据当前实际总请求数、预期总请求数以及第二压测模式下的单个请求耗时，确定与第二压测模式对应的发包时间间隔。

在一个实施例中，如图3所示，提供了一种与压测处理请求对应的各初始压测参数的界面示意图，参照图3中的（a）可知，当前压测对应的压测框架为RPS框架（即Request PerSecond 吞吐率压测框架，用于精准控制每秒发出的流量，有效保护服务，常用于***定量分析），初始压测参数具体包括初始发包速率（即初始RPS，图3中的（a）中显示为1笔）、目标发包速率（即目标RPS，图3中的（a）显示为20笔）、爬坡时间（即预热时间，图3中的（a）中显示为10秒）、以及压测时间（即预热后持续压测时间，图3中的（a）中显示为100秒）等。

其中，参照图3中的（a）可知，初始压测参数还可包括指定次数（图3中的（a）中显示为0笔，0笔表示不限制，即达到预设压测周期时确定满足压测处理结束条件。其中，若设置有指定次数，则表明压测处理过程中累计的请求数达到所设置的具体指定次数时，需结束当前压测处理操作）、以及流量分布（图3中的（a）显示为XX地域、流量占比%，以及新增地域，即可针对不同的地域设置相应的压测流量占比）。

进一步地，参照图3中的（b）可知，当前RPS框架下的压测模式的爬坡时间（即预热时间）不为空，属于第二压测模式，即设置有匀加速阶段（具体加速时长即预热时间为10秒），经过匀加速后再维持匀速阶段，即通过从初始RPS即0笔，匀加速10秒后，达到目标RPS即20笔后，维持在目标RPS直至达到当前压测处理操作对应的预设压测周期（图3中未示出），并在达到预设压测周期时结束当前压测处理操作。

步骤S206，获取与压测对象对应的配置信息，并基于配置信息进行参数初始化处理，获得初始化后的各运行参数。

具体地，通过获取与压测对象对应的配置信息，比如获取与服务器对应的配置信息，包括服务器机型、机型对应的最大并发用户数区间、以及支持的压测框架，以根据最大并发用户数区间、以及支持的压测框架，进行参数初始化处理，获得初始化后的各运行参数。

其中，根据最大并发用户数区间，初始化得到的各运行参数具体包括初始并发用户数即初始并发请求数、以及最大并发用户数即并发请求数阈值。而根据支持的压测框架，比如RPS压测框架（即Request Per Second 压测框架），初始化得到的各运行参数则包括压测起始时间和预设压测周期，其中，压测起始时间表示压测处理操作的起始时间，预设压测周期则表示当前压测处理操作的最大压测时长，在达到该压测时长时需结束当前压测处理操作。

在一个实施例中，根据支持的压测框架，初始化得到的各运行参数，还包括与并发请求数阈值对应的协程数阈值、状态信号量、请求计数值以及协程组状态。其中，协程数阈值表示预先初始化设置的可触发或调用的最大发包协程数量，状态信号量对应阻塞型的信号通道的信号量（比如ticks信号通道，即用于同步状态的信号量的信号通道），请求计数值和请求计数器对应，用于表示当前累计的请求次数，初始化时通常将请求计数值置为0，协程组状态表示各发包协程的状态（包括空闲、使用中、以及故障等不同状态），初始化时通常将各发包协程的状态设置为空闲状态。

步骤S208，根据初始化后的各运行参数触发发包协程，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行压测发包处理。

具体地，根据初始化后的各运行参数比如初始并发请求数，触发与初始并发请求数为相同数量的发包协程（具体是状态为空闲状态的各发包协程），并根据压测起始时间和当前时间点，确定当前压测处理时间，即根据压测起始时间和实际检测到的当前时间点，确定出压测处理过程的持续时间。

进一步地，在确定当前压测处理时间小于预设压测周期，即在确定压测处理过程的持续时间，未达到当前压测处理操作的最大压测时长时，根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。其中，在确定压测处理过程的持续时间，达到当前压测处理操作的最大压测时长（即预设压测周期）时，结束当前压测处理操作。

其中，休眠控速函数用于对当前的压测处理操作进行启停控制，即在未达到下一次发包时间间隔时，则通过根据发包协程调用休眠控速函数暂停发包操作，在达到下一次发包实际间隔时，则重新执行发包操作，以达到按照发包时间间隔向压测对象进行定速压测发包处理的目的，可保障压测处理过程中的发包速率、以及发包时间间隔，避免大量请求同时出现或长时间未出现请求的情况，减少服务器资源浪费。

具体来说，休眠控速函数可以是sleep（）函数，sleep（）函数用于使计算机程序（或进程、任务、线程等）进入休眠，使其在一段时间内处于非活动状态，当函数设定的计时器到期，或者接收到信号、程序发生中断都会导致程序继续执行。具体到本申请实施例中，sleep（）函数用于实时检测当前时间是否达到发包时间间隔，即通过sleep（）函数设置的计时器进行时间统计，判断统计得到的时间是否达到下一次发包时间间隔。其中，若未达到下一次发包时间间隔，则根据发包协程调用sleep（）函数暂停发包操作，在达到下一次发包实际间隔时，再重新触发执行发包操作，以达到按照发包时间间隔向压测对象进行定速压测发包处理的目的。

步骤S210，获取与压测对象对应的压测处理结果。

具体地，在向压测对象进行压测发包处理后，进一步获取与压测对象对应的压测处理结果，即获得该压测对象的压测性能数据，包括服务器或应用***等的服务内存占用率、以及可同时提供目标服务的最大并发请求数等性能数据。

上述压测控制处理方法中，在检测到压测处理请求时，获取压测处理请求对应的压测对象和各初始压测参数，并基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，以根据发包时间确定逻辑确定对应压测模式的发包时间间隔。进一步地，通过获取与压测对象对应的配置信息，并基于配置信息进行参数初始化处理以获得初始化后的各运行参数，从而可根据初始化后的各运行参数触发发包协程，并按照所确定出的当前实际的压测模式的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理，提升了压测发包处理效率，而进一步通过获取与压测对象对应的压测处理结果，可准确获知各压测对象的服务性能。

在一个实施例中，如图4所示，确定与压测模式对应的发包时间间隔的步骤，即基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据发包时间确定逻辑确定与压测模式对应的发包时间间隔的步骤，具体包括：

步骤S402，若确定爬坡时间为空，确定与当前匹配的压测模式为第一压测模式。

具体地，初始压测参数包括爬坡时间、压测时间、初始发包速率、以及目标发包速率等，若确定爬坡时间为空，即并未设置匀加速阶段时，表明当前为第一压测模式。

步骤S404，获取与第一压测模式匹配的第一发包时间确定逻辑，并根据第一发包时间确定逻辑确定第一压测模式下的预期总请求数。

其中，第一压测模式由于并未设置匀加速阶段，则第一压测模式可映射为匀速直线运动，可理解为秒杀模式，则传统上通常采用计算当前压测时长以及初始发包率之间的乘积，来确定出第一压测模式下的预期总请求数的方式。其中，若当前实际总请求数小于计算出的预期总请求数，则表明当前的发包速率已经低于预设的目标发包速率，无需控速，需立即进行下一个请求。

然而，传统的计算方式中，在接口耗时突增再降的场景（即耗时抖动场景）下，由于接口耗时突增导致压测对象瞬时无法支持目标发包速率，导致出现当前实际所需的发包速率超过目标发包速率的情况。进而为了避免出现当前实际所需的发包速率超过目标发包速率的情况，导致所确定出的预期总请求数不准确的问题，通过滑动获取上一秒实际总请求数，并根据第一发包时间确定逻辑，基于初始发包速率、以及上一秒实际总请求数，确定第一压测模式下的预期总请求数。

具体来说，通过滑动获取上一秒实际总请求数即before Hits1，并根据第一发包时间确定逻辑，基于初始发包速率即RPS1、以及上一秒实际总请求数即before Hits1，进行求和，获得第一压测模式下的预期总请求数即expected Hits1。

其中，第一压测模式下的预期总请求数expected Hits1，具体采用以下公式（1）确定得到：

expected Hits1=before Hits1+RPS1 （公式1）

其中，expected Hits1即第一压测模式下的预期总请求数，before Hits1即上一秒实际总请求数，RPS1即初始发包速率。

步骤S406，获取压测过程中的当前实际总请求数，若当前实际总请求数不小于预期总请求数，确定第一压测模式下的单个请求耗时。

具体地，通过获取压测过程中的当前实际总请求数即Hits1，并将当前实际总请求数Hits1和第一压测模式下的预期总请求数expected Hits1进行比对，在当前实际总请求数Hits1不小于预期总请求数expected Hits1时，基于初始发包速率RPS1和预设单位时间，确定第一压测模式下的单个请求耗时。

其中，单个请求耗时即interval1，具体是通过计算预设单位时间和初始发包速率RPS1之间的比值计算得到。其中，预设单位时间具体可以是1秒（通过1e9纳秒进行表示），则第一压测模式下的单个请求耗时具体采用以下公式（2）确定得到：

（公式2）

其中，interval1即第一压测模式下的单个请求耗时，1e9即预设单位时间，RPS1即初始发包速率。

步骤S408，根据当前实际总请求数、第一压测模式下的单个请求耗时以及当前压测时长，确定与第一压测模式对应的发包时间间隔。

具体地，根据当前实际总请求数Hits1和第一压测模式下的单个请求耗时interval1，确定下一次发包预期时间delta1，并基于下一次发包预期时间delta1、以及当前压测时长elapsed，确定与第一压测模式对应的发包时间间隔P1。

其中，具体采用以下公式（3）确定下一次发包预期时间delta 1：

delta1=（Hits1+1）* interval1（公式3）

其中，delta1即下一次发包预期时间，Hits1即当前实际总请求数，interval1即第一压测模式下的单个请求耗时。

进一步地，具体采用以下公式（4）确定与第一压测模式对应的发包时间间隔P1：

P1= delta1-elapsed（公式4）

其中，P1即第一压测模式对应的发包时间间隔，delta1即下一次发包预期时间，elapsed即当前压测时长。

在一个实施例中，如图5所示，提供了一种与第一压测模式对应的发包时间间隔确定过程，参照图5中的（a）可知，第一压测模式未设置匀加速阶段，可映射为匀速直线运动，即在整个预设压测周期（即period）内，发包速率未发生变化，维持为初始发包速率（即RPS1）。

进一步地，参照图5中的（b）可知，在第一压测模式下，通过计算第一压测模式下的预期总请求数即计算expected Hits1，并判断当前实际总请求数Hits1是否小于第一压测模式下的预期总请求数expected Hits1。其中，若Hits1＜expected Hits1，则加速追赶不进行控速，即等待时间wait为0。

相反地，参照图5中的（b）可知，若Hits1不小于expected Hits1时，则确定第一压测模式下的单个请求耗时interval1，并根据当前实际总请求数Hits1和第一压测模式下的单个请求耗时interval1，确定下一次发包预期时间delta1，通过公式（3）即“delta1=（Hits1+1）* interval1”，计算下一次发包预期时间delta1，并进一步基于下一次发包预期时间delta1、以及当前压测时长elapsed，确定与第一压测模式对应的发包时间间隔P1，具体是通过公式（4）即“P1= delta1-elapsed”，计算第一压测模式对应的发包时间间隔P1。

本实施例中，若确定爬坡时间为空，则确定与当前匹配的压测模式为第一压测模式，并获取与第一压测模式匹配的第一发包时间确定逻辑，以根据第一发包时间确定逻辑确定第一压测模式下的预期总请求数。进一步地，通过获取压测过程中的当前实际总请求数，若当前实际总请求数不小于预期总请求数，确定第一压测模式下的单个请求耗时，以根据当前实际总请求数、第一压测模式下的单个请求耗时以及当前压测时长，确定与第一压测模式对应的发包时间间隔，从而实现了可按照与当前实际确定出的压测模式匹配的发包时间确定逻辑，准确确定出相应的发包时间间隔，以在预设压测周期内向压测对象按照所确定出的发包时间间隔进行定速压测发包处理，提升压测发包处理效率。

在一个实施例中，如图6所示，确定与压测模式对应的发包时间间隔的步骤，即基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据发包时间确定逻辑确定对应压测模式的发包时间间隔的步骤，具体包括：

步骤S602，若确定爬坡时间不为空，确定与当前匹配的压测模式为第二压测模式。

具体地，初始压测参数包括爬坡时间、压测时间、初始发包速率、以及目标发包速率等，若确定爬坡时间不为空，即设置有匀加速阶段时，表明当前为第二压测模式。

步骤S604，获取与第二压测模式匹配的第二发包时间确定逻辑，并根据第二发包时间确定路逻辑确定第二压测模式下的预期总请求数。

其中，由于第二压测模式设置有匀加速阶段，则第二压测模式可以映射为匀加速运动+匀速直线运动的结合，可理解为爬坡模式。传统上，通常需分别计算匀加速时间段即爬坡时间内的预期请求总数S1，以及匀速时间段内的预期请求总数S2。

具体来说，匀加速时间段即爬坡时间内的预期请求总数S1= V0*t+1/2*a*T²，其中，V0即第二压测模式下的初始发包速率，t即为第二压测模式下的爬坡时间，a即为匀加速时间段的加速度，T为匀速直线运动时间即爬坡后的压测持续时间，其中，加速度a=(V-V0)/t，V表示稳定发包速率即爬坡后的匀速直线运动阶段中的发包速率。同样地，匀速时间段内的预期请求总数S2=S1+ V*(T-t)，其中，S1即匀加速时间段即爬坡时间内的预期请求总数，V 即爬坡后的匀速直线运动阶段中的发包速率，T为匀速直线运动时间即爬坡后的压测持续时间，t为第二压测模式下的爬坡时间。

然而，在第二压测模式下，由于传统的计算方式也同样存在由于当前实际所需的发包速率超过目标发包速率的情况，导致所确定出的预期总请求数不准确的问题，进而改为采用滑动获取上一秒实际总请求数，以基于当前发包速率、以及上一秒实际请求总数，来确定出第二压测模式下的预期总请求数的方式，克服在接口耗时突增再降的场景下所确定出的预期总请求数不准确的问题。

进一步地，通过确定出与爬坡时间对应的第一当前发包速率、以及与持续压测时间对应的第二当前发包速率，并滑动获取在爬坡时间内时的第一上一秒实际总请求数、以及在持续压测时间内的第二上一秒实际总请求数，以根据第一当前发包速率、第一上一秒实际总请求数，确定在爬坡时间内的第一预期请求数，以及根据第二当前发包速率、第二上一秒实际总请求数，确定在持续压测时间内的第二预期请求数。

步骤S606，获取压测过程中的当前实际总请求数，若当前实际总请求数不小于预期总请求数，确定第二压测模式下的单个请求耗时。

具体地，通过获取压测过程中第二压测模式下的当前实际总请求数，并将当前实际总请求数和第二压测模式下的预期总请求数进行比对，在当前实际总请求数不小于预期总请求数时，基于当前发包速率和预设单位时间，确定第二压测模式下的单个请求耗时。

进一步地，当前发包速率包括与爬坡时间对应的第一当前发包速率、以及持续压测时间对应的第二当前发包速率，进而具体是基于与爬坡时间对应的第一当前发包速率、以及预设单位时间，确定第二压测模式下与爬坡时间对应的第一子单个请求耗时，以及根据与持续压测时间对应的第二当前发包速率、以及预设单位时间，确定第二压测模式下与持续压测时间对应的第二子单个请求耗时。

其中，具体采用以下公式（5），确定与爬坡时间对应的第一子单个请求耗时interval21，以及采用公式（6），确定与持续压测时间对应的第二子单个请求耗时interval22：

（公式5）

（公式6）

其中，interval21即与爬坡时间对应的第一子单个请求耗时，interval22即与持续压测时间对应的第二子单个请求耗时，预设单位时间具体可以是1秒（通过1e9纳秒进行表示），V1即与爬坡时间对应的第一当前发包速率，V2即与持续压测时间对应的第二当前发包速率。

步骤S608，根据当前实际总请求数、预期总请求数以及第二压测模式下的单个请求耗时，确定与第二压测模式对应的发包时间间隔。

具体地，根据当前实际总请求数以及第一预期请求数，确定第一发包次数差值，并根据第一发包次数差值和第一子单个请求耗时，确定第二压测模式下与爬坡时间对应的第一子发包时间间隔，或根据当前实际总请求数以及第二预期请求数，确定第二发包次数差值，并根据第二发包次数差值和第二子单个请求耗时，确定第二压测模式下与持续压测时间对应的第二子发包时间间隔。

其中，具体采用以下公式（7）确定第一发包次数差值 delta21、以及根据以下公式（8）确定第二发包数差值delta22：

delta21=（Hits21+1）- expected Hits21（公式7）

delta22=（Hits22+1）- expected Hits22（公式8）

其中，delta21即第一发包次数差值，delta22即第二发包数差值，Hits21即在爬坡时间内时的第一上一秒实际总请求数，expected Hits21即在爬坡时间内的第一预期请求数，Hits22即在持续压测时间内的第二上一秒实际总请求数，expected Hits22即在持续压测时间内的第二预期请求数。

进一步地，采用以下公式（9）确定第一子发包时间间隔P21，以及采用以下公式（10）确定第二子发包时间间隔P22：

P21= delta21* interval21（公式9）

P22= delta22* interval22（公式10）

其中，P21即第一子发包时间间隔，P22即第二子发包时间间隔，delta21即第一发包次数差值，delta22即第二发包数差值，interval21即与爬坡时间对应的第一子单个请求耗时，interval22即与持续压测时间对应的第二子单个请求耗时。

在一个实施例中，如图7所示，提供了一种与第二压测模式对应的发包时间间隔确定过程，参照图7中的（a）可知，第二压测模式设置有爬坡时间，可映射为匀加速运动+匀速直线运动的结合，即在整个预测周期（即period）内，先在爬坡时间内匀加速运动，其中，爬坡时间内的加速度为a，在通过匀加速运动达到目标发包速率后，维持目标发包速率进行匀速直线运动，直至达到预设预测周期时，结束当前压测处理操作。

进一步地，参照图7中的（b）可知，在第二压测模式下，通过计算第二压测模式下的预期总请求数即计算expected Hits2（具体包括在爬坡时间内的第一预期请求数expectedHits21、以及在持续压测时间内的第二预期请求数expected Hits22），并判断当前实际总请求数Hits2（包括在爬坡时间内时的第一上一秒实际总请求数Hits21，以及在持续压测时间内的第二上一秒实际总请求数Hits22），是否小于第二压测模式下的预期总请求数expected Hits2。其中，若Hits2＜expected Hits2，则加速追赶不进行控速，即等待时间wait为0。

相反地，参照图7中的（b）可知，若Hits2不小于expected Hits2，则计算当前发包速率（具体包括与爬坡时间对应的第一当前发包速率V1、以及与持续压测时间对应的第二当前发包速率V2），以根据当前发包速率和预设单位时间，确定与第二压测模式对应的单个请求耗时interval2（具体包括与爬坡时间对应的第一子单个请求耗时interval21、以及与持续压测时间对应的第二子单个请求耗时interval22）。

进一步地，根据当前实际总请求数Hits2、预期总请求数expected Hits2，确定发包次数差值delta2，即delta2=(Hits2+1)-expected Hits2（具体包括根据第一上一秒实际总请求数Hits21、和第一预期请求数expected Hits21，确定的第一发包次数差值delta21，以及根据第二上一秒实际总请求数Hits22、和第二预期请求数expected Hits22，确定的第二发包数差值delta22），从而根据发包次数差值和第二压测模式对应的单个请求耗时，确定第二压测模式下的第二发包时间间隔P2，即P2=interval2*delta2（具体包括根据第一发包次数差值delta21、和第一子单个请求耗时interval21，确定的第一子发包时间间隔P21，以及根据第二发包数差值delta22、和第二子单个请求耗时interval22，确定的第二子发包时间间隔P22）。

本实施例中，若确定爬坡时间不为空，则确定与当前匹配的压测模式为第二压测模式，通过获取与第二压测模式匹配的第二发包时间确定逻辑，以根据第二发包时间确定逻辑确定第二压测模式下的预期总请求数。进一步地，通过获取压测过程中的当前实际总请求数，若当前实际总请求数不小于预期总请求数，则确定第二压测模式下的单个请求耗时，以根据当前实际总请求数、预期总请求数以及第二压测模式下的单个请求耗时，确定与第二压测模式对应的发包时间间隔，从而实现了可按照与当前实际确定出的压测模式匹配的发包时间确定逻辑，准确确定出相应的发包时间间隔，以在预设压测周期内按照所确定出的发包时间间隔，向压测对象进行定速压测发包处理，提升压测发包处理效率。

在一个实施例中，如图8所示，确定第二压测模式下的预期总请求数的步骤，即根据第二发包时间确定逻辑确定第二压测模式下的预期总请求数的步骤，具体包括：

步骤S802，根据第二发包时间确定逻辑，基于第二压测模式下的初始发包速率、以及爬坡时间，确定与爬坡时间对应的第一当前发包速率。

具体地，通过获取第二压测模式下的初始发包速率、以及输入的爬坡时间，确定匀加速时间段即爬坡时间内的第一当前发包速率。

其中，具体采用以下公式（11），确定爬坡时间内的第一当前发包速率V1：

V1=V0+at（公式11）

其中，V1即第一当前发包速率，V0即第二压测模式下的初始发包速率，a即爬坡时间内的加速度，t即爬坡时间。

步骤S804，根据第二发包时间确定逻辑，确定与第二压测模式下的持续压测时间对应的第二当前发包速率。

具体地，通过获取匀加速运动结束时的当前发包速率，并将匀加速运动结束时的当前发包速率，确定为与第二压测模式下的持续压测时间对应的第二当前发包速率V2。

步骤S806，滑动获取在爬坡时间内时的第一上一秒实际总请求数、以及在持续压测时间内的第二上一秒实际总请求数。

具体地，在第二压测模式下，由于传统的计算方式也同样存在由于当前实际所需的发包速率超过目标发包速率的情况，导致所确定出的预期总请求数不准确的问题，进而改为采用滑动获取上一秒实际总请求数，以基于当前发包速率、以及上一秒实际请求总数，来确定出第二压测模式下的预期总请求数的方式，克服在接口耗时突增再降的场景下所确定出的预期总请求数不准确的问题。

其中，第二压测模式下的上一秒实际总请求数，具体包括在爬坡时间内时的第一上一秒实际总请求数、以及在持续压测时间内的第二上一秒实际总请求数。

步骤S808，根据第一当前发包速率、第一上一秒实际总请求数，确定在爬坡时间内的第一预期请求数，以及根据第二当前发包速率、第二上一秒实际总请求数，确定在持续压测时间内的第二预期请求数。

具体地，基于第一当前发包速率、以及第一上一秒实际总请求数，进行求和，获得在爬坡时间内的第一预期请求数。同样地，基于第二当前发包速率、以及第二上一秒实际总请求数，进行求和，获得在持续压测时间内的第二预期请求数。

其中，具体采用以下公式（12）确定在爬坡时间内的第一预期请求数expectedHits21，以及根据以下公式（13）确定在持续压测时间内的第二预期请求数expectedHits22：

expected Hits21=before Hits21+V1 （公式12）

expected Hits22=before Hits22+V2 （公式13）

其中，expected Hits21即在爬坡时间内的第一预期请求数，expected Hits22即在持续压测时间内的第二预期请求数，before Hits21即在爬坡时间内时的第一上一秒实际总请求数，before Hits22即在持续压测时间内的第二上一秒实际总请求数，V1即爬坡时间内的第一当前发包速率，V2即持续压测时间对应的第二当前发包速率。

本实施例中，根据第二发包时间确定逻辑，基于第二压测模式下的初始发包速率、以及爬坡时间，确定与爬坡时间对应的第一当前发包速率，以及根据第二发包时间确定逻辑，确定与第二压测模式下的持续压测时间对应的第二当前发包速率。进一步地，通过滑动获取在爬坡时间内时的第一上一秒实际总请求数、以及在持续压测时间内的第二上一秒实际总请求数，以根据第一当前发包速率、第一上一秒实际总请求数，确定在爬坡时间内的第一预期请求数，以及根据第二当前发包速率、第二上一秒实际总请求数，确定在持续压测时间内的第二预期请求数，实现了可根据第二压测模式下的初始发包速率、爬坡时间以及持续压测时间等，分别确定出匀加速以及匀速时间段内的不同预期请求数，从而准确确定出第二压测模式下的预期总请求数，减少压测处理过程中的误差数据，提升压测控制处理效率。

在一个实施例中，如图9所示，在预设压测周期内向压测对象进行压测发包处理的步骤，即根据初始化后的各运行参数触发发包协程，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行压测发包处理的步骤，具体包括：

步骤S902，根据初始并发请求数触发对应数量的发包协程，并根据压测起始时间和当前时间点，确定当前压测处理时间。

具体地，根据初始化后的初始并发请求数，触发与初始并发请求数相同数量的发包协程，其中初始并发请求数可根据实际需求或应用场景进行设置或调整，不局限于某个或某些具体取值。同时，还需获取当前时间点，以基于压测起始时间和当前时间点，确定出当前压测处理时间，即确定出自压测起始至当前时间点时，当前压测处理过程的持续时间。

步骤S904，若确定当前压测处理时间小于预设压测周期，则根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。

具体地，通过获取预设压测周期即当前压测处理操作的最大压测时长，并将当前压测处理时间和预设压测周期进行比对。其中，在确定当前压测处理时间小于预设压测周期，即在确定压测处理过程的持续时间，未达到当前压测处理操作的最大压测时长时，根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。其中，在确定压测处理过程的持续时间，达到当前压测处理操作的最大压测时长（即预设压测周期）时，结束当前压测处理操作。

其中，休眠控速函数用于对当前的压测处理操作进行启停控制，即在未达到下一次发包时间间隔时，则通过根据发包协程调用休眠控速函数暂停发包操作，在达到下一次发包实际间隔时，则重新执行发包操作，以达到按照发包时间间隔向压测对象进行定速压测发包处理的目的，可保障压测处理过程中的发包速率、以及发包时间间隔，避免大量请求同时出现或长时间未出现请求的情况，减少服务器资源浪费。

具体来说，休眠控速函数可以是sleep（）函数，用于实时检测当前时间是否达到发包时间间隔，即通过sleep（）函数设置的计时器进行时间统计，判断统计得到的时间是否达到下一次发包时间间隔。其中，若未达到下一次发包时间间隔，则通过根据发包协程调用sleep（）函数暂停发包操作，在达到下一次发包实际间隔时，则重新触发执行发包操作，以达到按照发包时间间隔向压测对象进行定速压测发包处理的目的。

在一个实施例中，与发包协程对应的协程执行方式，具体包括：

通过发包协程接收状态信号量反馈的请求指令下发状态信息；若确定请求指令下发状态信息为请求指令下发成功，调用并执行发包函数按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理；若确定请求指令下发状态信息为请求指令下发失败，持续阻塞直至确定请求指令下发成功。

具体地，通过发包协程不断尝试接收状态信号量反馈的请求指令下发状态信息，若状态信息接收成功，则判断请求指令下发状态信息是否为请求指令下发成功。其中，若状态信息接收失败，即并未获得状态信号量反馈的请求指令下发状态信息，则该发包协程退出执行。

进一步地，若状态信息接收成功，且确定请求指令下发状态信息为请求指令下发成功，则调用并执行发包函数按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。

其中，发包时间间隔具体包括与第一压测模式对应的发包时间间隔、以及与第二压测模式对应的发包时间间隔，则调用并执行发包函数按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理时，具体是根据压测模式的不同，按照与不同压测模式匹配的发包时间间隔，比如在确定压测模式为第一压测模式时，按照与第一压测模式对应的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。

同样地，在确定压测模式为第二压测模式时，则按照与第二压测模式对应的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。其中，第二压测模式下的发包时间间隔，具体包括与爬坡时间对应的第一子发包时间间隔、以及与持续压测时间对应的第二子发包时间间隔，则可以理解为在第二压测模式下的爬坡时间内，按照第一子发包时间间隔，向压测对象进行定速压测发包处理，而在第二压测模式下的持续压测时间内，则按照第二子发包时间间隔，向压测对象进行定速压测发包处理。

相反地，若确定状态信息接收成功，但请求指令下发状态信息为请求指令下发失败，则持续阻塞直至确定请求指令下发成功。其中，具体是持续阻塞，停止压测发包处理，直至确定请求指令下发状态信息为请求指令下发成功时，才按照相应的发包时间间隔，向压测对象进行定速压测发包处理。

在一个实施例中，如图10所示，提供了一种单个发包协程对应的协程执行过程示意，参照图10可知，针对单个发包协程而言，发包协程通过不断尝试接收状态信号量（即ticks信号量）反馈的请求指令下发状态信息，若状态信息接收成功，则判断请求指令下发状态信息是否为请求指令下发成功。其中，若状态信息接收失败，即并未获得状态信号量反馈的请求指令下发状态信息，则该取消该发包协程。

进一步地，若确定状态信号量（即ticks信号量）反馈的状态信息接收成功，且确定请求指令下发状态信息为请求指令下发成功，则调用并执行发包函数（即Attack_N函数），按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。

其中，若确定状态信息接收成功，但请求指令下发状态信息为请求指令下发失败，则持续阻塞直至确定请求指令下发成功。其中，具体是持续阻塞，停止压测发包处理，重复获取状态信息的操作，直至确定请求指令下发状态信息为请求指令下发成功时，才按照相应的发包时间间隔，向压测对象进行定速压测发包处理。

本实施例中，根据初始并发请求数触发对应数量的发包协程，并根据压测起始时间和当前时间点，确定当前压测处理时间。若确定当前压测处理时间小于预设压测周期，则通过根据发包协程调用休眠控速函数，可达到按照所确定出的发包时间间隔，不断调整发包速率，在预设压测周期内向压测对象进行定速压测发包处理的效果，避免采用单一的发包速率或单一的发包方式，减少服务资源的消耗，并提升压测处理过程中的处理效率。

在一个实施例中，如图11所示，提供了一种压测控制处理方法，在根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理时，该方法还包括：

步骤S1102，获取当前发包协程数量，并将当前发包协程数量和协程数阈值进行比对。

具体地，通过在压测处理过程中，获取当前发包协程数量，并将当前发包协程数量和协程数阈值进行比对，以判断前发包协程数量是否达到协程数阈值。

步骤S1104，若当前发包协程数量小于协程数阈值，基于状态信号量进行请求指令下发处理。

其中，将当前发包协程数量和协程数阈值进行比对后，若确定当前发包协程数量小于协程数阈值，则表明当前并未达到压测对象所支撑的最大协程数，该压测对象还可支持新增其他发包协程，用以向使用对象提供目标服务。

具体地，若当前发包协程数量小于协程数阈值，即当前并未达到压测对象所支撑的最大协程数时，则基于状态信号量进行请求指令下发处理。其中，发包协程可用于消费ticks信号（即状态信号量），若确定对状态信号量进行请求指令下发处理为下发成功，即存在可用于消费ticks信号的其他发包协程，则表明可以触发该些发包协程用以进行压测发包处理。

步骤S1106，若请求指令下发成功，更新请求计数值。

具体地，若确定对状态信号量进行请求指令下发处理为下发成功，即存在可用于消费ticks信号的空闲发包协程，可以触发该些空闲发包协程，用以进行压测发包处理，则请求指令下发成功一次，表明存在一个可用于进行压测发包处理处理的空闲发包协程，进而可通过更新请求计数器的请求计数值，确定当前已处理的历史请求数。

步骤S1108，若请求指令下发失败，触发新的发包协程，新的发包协程用于执行新增的压测处理请求。

具体地，若确定对状态信号量进行请求指令下发处理为下发失败，则表明当前的各发包协程均处于使用中，未检测到空闲状态的发包协程，进而需要触发新的发包协程，用以执行新的压测处理请求和进行压测发包处理。

步骤S1110，若当前发包协程数量达到协程数阈值，基于状态信号量进行请求指令下发处理。

其中，将当前发包协程数量和协程数阈值进行比对后，若确定当前发包协程数量达到协程数阈值，则表明当前已达到压测对象所支撑的最大协程数，该压测对象无法支持新增其他发包协程的操作。

具体地，若当前发包协程数量达到协程数阈值，同样需基于状态信号量进行请求指令下发处理，以确定当前是否存在可用于消费ticks信号的空闲发包协程。

步骤S1112，若请求指令下发成功，更新请求计数值。

具体地，在当前发包协程数量达到协程数阈值时，若确定对状态信号量进行请求指令下发处理为下发成功，即存在可用于消费ticks信号的空闲发包协程，可以触发该些空闲发包协程，用以进行压测发包处理，则请求指令下发成功一次，表明存在一个可用于进行压测发包处理处理的空闲发包协程，进而可通过更新请求计数器的请求计数值，确定当前已处理的历史请求数。

步骤S1114，若请求指令下发失败，持续阻塞直至请求指令下发成功。

具体地，在当前发包协程数量达到协程数阈值时，若请求指令下发失败，则表明当前的各发包协程均处于使用中，未检测到空闲状态的发包协程，而由于当前发包协程数量已经达到协程数阈值，即无法再新增其他发包协程，进而采用持续阻塞的方式，直至请求指令下发成功，即通过持续阻塞，停止压测发包处理操作，直至请求指令下发成功，确定当前存在空闲发包协程时，才触发该些空闲发包协程，用以进行压测发包处理。

上述压测控制处理方法中，通过获取当前发包协程数量，并将当前发包协程数量和协程数阈值进行比对，若当前发包协程数量小于协程数阈值，基于状态信号量进行请求指令下发处理。其中，若请求指令下发成功，更新请求计数值，而若请求指令下发失败，触发新的发包协程；新的发包协程用于执行新增的压测处理请求。进一步地，若当前发包协程数量达到协程数阈值，同样基于状态信号量进行请求指令下发处理。其中，若请求指令下发成功，则更新请求计数值，而若请求指令下发失败，则持续阻塞直至请求指令下发成功，实现了根据当前发包协程数量以及协程数阈值，实现对并发处理请求数以及发包协程数的自适应调整，避免出现发包协程长时间空闲导致资源浪费、以及压测处理请求长时间得不到响应的问题，提升服务资源利用率、以及压测处理请求的处理效率。

在一个实施例中，如图12所示，提供了一种压测控制处理方法，具体包括：

A、初始化各运行参数

具体地，在启动压测控制处理时，初始化各运行参数，具体包括：A1、设置压测起始时间和初始化请求计数器值；A2、设置最小协程以及协程数阈值；A3、初始化状态信号量。

B、动态协程调度

其中，通过对协程组状态进行初始化，并启动最小协程，以基于协程组实现动态调度。其中，由于在耗时持续增长场景下，容易导致并发请求数增长过快，短时间增加很多无用并发，带来内存耗尽的风险，可采用PID算法（即涉及比例（proportional）、积分（integral）以及微分（derivative）等方向，用于维持稳定的控制算法）进行负反馈调整，动态调整各协程中并发请求增长速率，防止并发请求数过快增长，避免出现服务器内存耗尽风险导致无法及时提供目标服务的问题。

具体地，动态协程调度过程包括：B1、判断持续压测时间是否达到预设压测周期；B2、若确定持续压测时间未达到预设压测周期，则调用定速器进行延时计算，确定不同压测模式下的发包时间间隔；B3、根据发包协程调用休眠控速函数，按照发包时间间隔对压测对象进行定速压测发包处理；B4、判断当前发包协程数量是否达到协程数阈值；B5、若当前发包协程数量达到协程数阈值，基于状态信号量进行请求指令下发处理；B6、若请求指令下发成功，更新请求计数值（即请求计数值+1）；B7、若请求指令下发失败，持续阻塞直至请求指令下发成功；B8、若当前发包协程数量小于协程数阈值，基于状态信号量进行请求指令下发处理；B9、若请求指令下发成功，更新请求计数值（即请求计数值+1）；B10、若请求指令下发失败，触发新的发包协程（即启动协程+1）。

上述压测控制处理方法中，通过在启动压测控制处理时，初始化各运行参数，并对协程组状态进行初始化，启动最小协程，以基于协程组实现动态调度，在动态协程调度过程中，通过在确定持续压测时间未达到预设压测周期时，调用定速器进行延时计算，确定不同压测模式下的发包时间间隔，以根据发包协程调用休眠控速函数，按照发包时间间隔对压测对象进行定速压测发包处理。其中，在确定当前发包协程数量达到协程数阈值时，基于状态信号量进行请求指令下发处理，若请求指令下发成功，更新请求计数值，而若请求指令下发失败，持续阻塞直至请求指令下发成功。进一步地，若确定当前发包协程数量小于协程数阈值，同样基于状态信号量进行请求指令下发处理，若请求指令下发成功，更新请求计数值，而若请求指令下发失败，触发新的发包协程，实现了根据当前发包协程数量以及协程数阈值，对并发处理请求数以及发包协程数的自适应调整，避免出现发包协程长时间空闲导致资源浪费、以及压测处理请求长时间得不到响应的问题，提升服务资源利用率、以及压测处理请求的处理效率。

在一个实施例中，如图13所示，提供了一种压测控制处理方法，具体包括以下部分：

1、用例开发

具体地，用例开发部分具体包括：用例开发、用例构建、压测机部署、以及机型部署等处理步骤，用例开发和用例构建表示开发构建得到用于向压测对象发送的压测用例（具体可以是数据包用例），压测机部署理解为部署配置得到作为向压测对象进行压测控制处理的压测服务器，压测对象部署表示对压测对象（比如服务器、应用***或者应平台等）进行配置和部署。

2、压测场景设置

具体地，压测场景具体包括单场景压测和场景混合编排，单场景压测理解为一个压测用例发压场景，适应于服务请求数量较少的简单业务，而场景混合编排可以将多个不同的压测用例编排在一起，每个用例可以建立多个分组，每个分组可以分别控制压测机的地域、量级、数据、配置、以及分类统计等信息，场景混合编排通常用于模拟线上真实业务流量分布，并精准控制不同地域的用例流量，提升压测控制处理效率。

3、压测模式匹配

其中，RPS压测框架（即Request Per Second 压测框架）下通常装载有第一压测模式、以及第二压测模式，不同压测模式下的发包时间间隔不同。其中，第一压测模式具体可以是秒杀模式，第二压测模式具体可以是爬坡模式。

具体地，根据初始压测参数确定匹配的压测模式，其中，初始压测参数包括初始发包速率、目标发包速率、爬坡时间、以及压测时间等，若确定爬坡时间为空，即并未设置匀加速阶段时，表明当前为第一压测模式，而若确定爬坡时间不为空，即设置有匀加速阶段时，表明当前为第二压测模式。

进一步地，第一压测模式未设置相应的匀加速阶段，压测处理过程中的发包速率即为初始发包速率，适应于积分兑换、优惠券发布、现金券发布等场景下的压测处理。而第二压测模式设置有匀加速阶段，压测过程中发包速率不断增加，从初始发包速率增加至目标发包速率后，稳定在目标发包速率进行压测发包处理，适应于***预热、服务定量分析等场景下的压测处理。

4、压测发包处理

具体地，利用定速器、以及tick信号同步器实现RPS压测发包，其中，定速器用于确定出与不同压测模式对应的发包时间间隔，而tick信号同步器（即状态信号同步器）用于同步各状态信号量，即通过对状态信号量进行请求指令下发处理，若下发成功则请求计数增加，若下发阻塞则说明发包协程处于使用中，即可通过各状态信号量确定当前是否有空闲发包协程，以触发该些空闲发包协程用于进行压测发包处理。

进一步地，若确定当前压测处理时间小于预设压测周期，则根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。

相反地，若确定当前压测处理时间达到预设压测周期，则结束当前压测控制处理流程。

上述压测控制处理方法，可根据进行压测处理时输入的各初始压测参数确定当前的压测模式，并根据初始化后的各运行参数触发发包协程，在实际的压测模式下，按照所确定出的相应压测模式的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理，避免服务资源浪费，提升了压测发包处理效率。

在一个实施例中，如图14所示，提供了一种压测控制处理方法，具体包括以下步骤：

步骤S1401，若检测到压测处理请求，获取压测处理请求对应的压测对象、和各初始压测参数。

其中，压测处理请求表示压测服务器104检测到的基于终端102触发的针对应用服务器、应用***或应用平台等压测对象的压力测试处理请求，可以理解为在压测服务器104检测到使用对象或开发人员等，基于终端102触发的压测处理请求时，压测服务器104可通过模拟使用对象触发海量请求目标服务的方式，对应用服务器、应用***或应用平台等进行压力测试，获得相应应用服务器、应用***或应用平台的压测性能数据，比如应用服务器或应用***等的服务内存占用率、以及可同时提供目标服务的最大并发请求数等性能数据。

初始压测参数表示与压测处理请求对应的输入参数，具体包括输入的爬坡时间、压测时间、预设压测周期、初始发包速率、以及目标发包速率等数据。其中，爬坡时间可以理解为压测处理过程中的预热时间，也可以理解为匀加速时间，在爬坡时间内压测处理过程中的发包速率不断提升，而压测时间可以理解为压测过程的当前持续时间。初始发包速率可以理解为开始压测处理时的最小发包速率，可根据实际需求进行调整和设置，而目标发包速率表示预先设置的发包速率，即压测处理过程中需要达到的稳定发包速率或最大发包速率。

具体地，通过检测基于终端针对应用服务器、应用***或应用平台等压测对象所触发的压测处理请求，若检测到压测处理请求，则获取压测处理请求对应的压测对象，即具体是应用服务器、或应用***、或应用平台等压测对象，并获取压测处理请求携带的各输入参数，包括爬坡时间、压测时间、预设压测周期、初始发包速率、以及目标发包速率等参数。

步骤S1402，判断初始压测参数中的爬坡时间是否为空。

步骤S1403，若确定初始压测参数中的爬坡时间为空，确定与当前匹配的压测模式为第一压测模式。

其中，初始压测参数包括爬坡时间、压测时间、初始发包速率、以及目标发包速率等，若确定爬坡时间为空，即并未设置匀加速阶段时，表明当前为第一压测模式，压测处理过程中的发包速率即为初始发包速率，具体可以理解为秒杀模式，其适应于积分兑换、优惠券发布、现金券发布等场景下的压测处理。

具体地，通过判断爬坡时间是否为空，来确定相应的压测模式。其中，若确定爬坡时间为空，确定匹配的压测模式为第一压测模式，并根据与第一压测模式匹配的第一发包时间确定逻辑，确定第一压测模式对应的发包时间间隔。

步骤S1404，获取与第一压测模式匹配的第一发包时间确定逻辑，滑动获取上一秒实际总请求数，并根据第一发包时间确定逻辑，基于初始发包速率、以及上一秒实际总请求数，确定第一压测模式下的预期总请求数。

其中，第一压测模式由于并未设置匀加速阶段，则第一压测模式可映射为匀速直线运动，则传统上通常采用计算当前压测时长以及初始发包率之间的乘积，来确定出第一压测模式下的预期总请求数的方式。其中，若当前实际总请求数小于计算出的预期总请求数，则表明当前的发包速率已经低于预设的目标发包速率，无需控速，需立即进行下一个请求。

然而，传统的计算方式中，在接口耗时突增再降的场景（即耗时抖动场景）下，由于接口耗时突增导致压测对象瞬时无法支持目标发包速率，导致出现当前实际所需的发包速率超过目标发包速率的情况。进而为了避免出现当前实际所需的发包速率超过目标发包速率的情况，导致所确定出的预期总请求数不准确的问题，通过滑动获取上一秒实际总请求数，并根据第一发包时间确定逻辑，基于初始发包速率、以及上一秒实际总请求数，确定第一压测模式下的预期总请求数。

具体来说，通过滑动获取上一秒实际总请求数，并根据第一发包时间确定逻辑，基于初始发包速率、以及上一秒实际总请求数，进行求和，获得第一压测模式下的预期总请求数。

步骤S1405，获取压测过程中的当前实际总请求数，若当前实际总请求数不小于预期总请求数，基于初始发包速率和预设单位时间，确定第一压测模式下的单个请求耗时。

具体地，通过获取压测过程中的当前实际总请求数，并将当前实际总请求数和第一压测模式下的预期总请求数进行比对，在当前实际总请求数不小于预期总请求数时，基于初始发包速率和预设单位时间，确定第一压测模式下的单个请求耗时。其中，单个请求耗时具体是通过计算预设单位时间和初始发包速率之间的比值计算得到。

步骤S1406，根据当前实际总请求数和第一压测模式下的单个请求耗时，确定下一次发包预期时间。

步骤S1407，基于下一次发包预期时间、以及当前压测时长，确定与第一压测模式对应的发包时间间隔。

具体地，根据当前实际总请求数和第一压测模式下的单个请求耗时，进行求和处理，确定下一次发包预期时间，并基于下一次发包预期时间、以及当前压测时长，进行求差处理，确定与第一压测模式对应的发包时间间隔。

执行步骤S1402后执行步骤S1408，若确定爬坡时间不为空，确定与当前匹配的压测模式为第二压测模式。

具体地，若确定爬坡时间不为空，即设置有匀加速阶段时，表明当前为第二压测模式，在压测过程中发包速率不断增加，从初始发包速率增加至目标发包速率后，稳定在目标发包速率进行压测发包处理，具体可以理解为爬坡模式，其适应于***预热、服务定量分析等场景下的压测处理。

步骤S1409，获取与第二压测模式匹配的第二发包时间确定逻辑，并根据第二发包时间确定逻辑，基于第二压测模式下的初始发包速率、以及爬坡时间，确定与爬坡时间对应的第一当前发包速率。

具体地，通过获取第二压测模式下的初始发包速率、以及输入的爬坡时间，确定匀加速时间段即爬坡时间内的第一当前发包速率。

步骤S1410，根据第二发包时间确定逻辑，确定与第二压测模式下的持续压测时间对应的第二当前发包速率。

具体地，通过获取匀加速运动结束时的当前发包速率，并将匀加速运动结束时的当前发包速率，确定为与第二压测模式下的持续压测时间对应的第二当前发包速率。

步骤S1411，滑动获取在爬坡时间内时的第一上一秒实际总请求数、以及在持续压测时间内的第二上一秒实际总请求数。

其中，由于第二压测模式为爬坡模式，设置有匀加速阶段，则第二压测模式可以映射为匀加速运动+匀速直线运动的结合。传统上，通常需分别计算匀加速时间段即爬坡时间内的预期请求总数S1，以及匀速时间段内的预期请求总数S2。

具体来说，匀加速时间段即爬坡时间内的预期请求总数S1= V0*t+1/2*a*T²，其中，V0即第二压测模式下的初始发包速率，t即为第二压测模式下的爬坡时间，a即为匀加速时间段的加速度，T为匀速直线运动时间即爬坡后的压测持续时间，其中，加速度a=(V-V0)/t，V表示稳定发包速率即爬坡后的匀速直线运动阶段中的发包速率。同样地，匀速时间段内的预期请求总数S2=S1+ V*(T-t)，其中，S1即匀加速时间段即爬坡时间内的预期请求总数，V 即爬坡后的匀速直线运动阶段中的发包速率，T为匀速直线运动时间即爬坡后的压测持续时间，t为第二压测模式下的爬坡时间。

然而，在第二压测模式下，由于传统的计算方式也同样存在由于当前实际所需的发包速率超过目标发包速率的情况，导致所确定出的预期总请求数不准确的问题，进而改为采用滑动获取上一秒实际总请求数，以基于当前发包速率、以及上一秒实际请求总数，来确定出第二压测模式下的预期总请求数的方式，克服在接口耗时突增再降的场景下所确定出的预期总请求数不准确的问题。

其中，第二压测模式下的上一秒实际总请求数，具体包括在爬坡时间内时的第一上一秒实际总请求数、以及在持续压测时间内的第二上一秒实际总请求数。

步骤S1412，根据第一当前发包速率、第一上一秒实际总请求数，确定在爬坡时间内的第一预期请求数，以及根据第二当前发包速率、第二上一秒实际总请求数，确定在持续压测时间内的第二预期请求数。

具体地，基于第一当前发包速率、以及第一上一秒实际总请求数，进行求和，获得在爬坡时间内的第一预期请求数。同样地，基于第二当前发包速率、以及第二上一秒实际总请求数，进行求和，获得在持续压测时间内的第二预期请求数。

步骤S1413，基于与爬坡时间对应的第一当前发包速率、以及预设单位时间，确定第二压测模式下与爬坡时间对应的第一子单个请求耗时，或根据与持续压测时间对应的第二当前发包速率、以及预设单位时间，确定第二压测模式下与持续压测时间对应的第二子单个请求耗时。

具体地，当前发包速率包括与爬坡时间对应的第一当前发包速率、以及持续压测时间对应的第二当前发包速率，进而具体是基于与爬坡时间对应的第一当前发包速率、以及预设单位时间，确定第二压测模式下与爬坡时间对应的第一子单个请求耗时，以及根据与持续压测时间对应的第二当前发包速率、以及预设单位时间，确定第二压测模式下与持续压测时间对应的第二子单个请求耗时。其中，预设单位时间具体可以是1秒（通过1e9纳秒进行表示）。

步骤S1414，根据当前实际总请求数以及第一预期请求数，确定第一发包次数差值，并根据第一发包次数差值和第一子单个请求耗时，确定第二压测模式下与爬坡时间对应的第一子发包时间间隔，或根据当前实际总请求数以及第二预期请求数，确定第二发包次数差值，并根据第二发包次数差值和第二子单个请求耗时，确定第二压测模式下与持续压测时间对应的第二子发包时间间隔。

具体地，根据当前实际总请求数以及第一预期请求数，进行求和，确定第一发包次数差值，并计算第一发包次数差值和第一子单个请求耗时之间的乘积，获得第二压测模式下与爬坡时间对应的第一子发包时间间隔，或根据当前实际总请求数以及第二预期请求数，进行求和，确定第二发包次数差值，并计算第二发包次数差值和第二子单个请求耗时之间的乘积，获得第二压测模式下与持续压测时间对应的第二子发包时间间隔。

步骤S1415，根据初始并发请求数触发对应数量的发包协程，并根据压测起始时间和当前时间点，确定当前压测处理时间。

具体地，根据初始化后的各运行参数比如初始并发请求数，触发与初始并发请求数为相同数量的发包协程（具体是状态为空闲状态的各发包协程），并根据压测起始时间和当前时间点，确定当前压测处理时间，即根据压测起始时间和实际检测到的当前时间点，确定出压测处理过程的持续时间。

步骤S1416，若确定当前压测处理时间小于预设压测周期，则根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。

具体地，在确定当前压测处理时间小于预设压测周期，即在确定压测处理过程的持续时间，未达到当前压测处理操作的最大压测时长时，根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。其中，在确定压测处理过程的持续时间，达到当前压测处理操作的最大压测时长（即预设压测周期）时，结束当前压测处理操作。

其中，休眠控速函数用于对当前的压测处理操作进行启停控制，即在未达到下一次发包时间间隔时，则通过根据发包协程调用休眠控速函数暂停发包操作，在达到下一次发包实际间隔时，则重新执行发包操作，以达到按照发包时间间隔向压测对象进行定速压测发包处理的目的，可保障压测处理过程中的发包速率、以及发包时间间隔，避免大量请求同时出现或长时间未出现请求的情况，减少服务器资源浪费。

进一步地，休眠控速函数可以是sleep（）函数，用于实时检测当前时间是否达到发包时间间隔，即通过sleep（）函数设置的计时器进行时间统计，判断统计得到的时间是否达到下一次发包时间间隔。其中，若未达到下一次发包时间间隔，则通过根据发包协程调用sleep（）函数暂停发包操作，在达到下一次发包实际间隔时，则重新触发执行发包操作，以达到按照发包时间间隔向压测对象进行定速压测发包处理的目的。

步骤S1417，获取当前发包协程数量，并将当前发包协程数量和协程数阈值进行比对。

具体地，通过在压测处理过程中，获取当前发包协程数量，并将当前发包协程数量和协程数阈值进行比对，以判断前发包协程数量是否达到协程数阈值。

步骤S1418，若当前发包协程数量小于协程数阈值，基于状态信号量进行请求指令下发处理。

其中，将当前发包协程数量和协程数阈值进行比对后，若确定当前发包协程数量小于协程数阈值，则表明当前并未达到压测对象所支撑的最大协程数，该压测对象还可支持新增其他发包协程，用以向使用对象提供目标服务。

具体地，若当前发包协程数量小于协程数阈值，即当前并未达到压测对象所支撑的最大协程数时，则基于状态信号量进行请求指令下发处理。其中，发包协程可用于消费ticks信号（即状态信号量），若确定对状态信号量进行请求指令下发处理为下发成功，即存在可用于消费ticks信号的其他发包协程，则表明可以触发该些发包协程用以进行压测发包处理。

步骤S1419，若请求指令下发成功，更新请求计数值，若请求指令下发失败，触发新的发包协程。

具体地，若确定对状态信号量进行请求指令下发处理为下发成功，即存在可用于消费ticks信号的空闲发包协程，可以触发该些空闲发包协程，用以进行压测发包处理，则请求指令下发成功一次，表明存在一个可用于进行压测发包处理处理的空闲发包协程，进而可通过更新请求计数器的请求计数值，确定当前已处理的历史请求数。

进一步地，若确定对状态信号量进行请求指令下发处理为下发失败，则表明当前的各发包协程均处于使用中，未检测到空闲状态的发包协程，进而需要触发新的发包协程，用以执行新的压测处理请求和进行压测发包处理。

执行步骤S1417后执行步骤S1420，若当前发包协程数量达到协程数阈值，基于状态信号量进行请求指令下发处理。

其中，将当前发包协程数量和协程数阈值进行比对后，若确定当前发包协程数量达到协程数阈值，则表明当前已达到压测对象所支撑的最大协程数，该压测对象无法支持新增其他发包协程的操作。

具体地，若当前发包协程数量达到协程数阈值，同样需基于状态信号量进行请求指令下发处理，以确定当前是否存在可用于消费ticks信号的空闲发包协程。

步骤S1421，若请求指令下发成功，更新请求计数值，若请求指令下发失败，持续阻塞直至请求指令下发成功。

具体地，在当前发包协程数量达到协程数阈值时，若确定对状态信号量进行请求指令下发处理为下发成功，即存在可用于消费ticks信号的空闲发包协程，可以触发该些空闲发包协程，用以进行压测发包处理，则请求指令下发成功一次，表明存在一个可用于进行压测发包处理处理的空闲发包协程，进而可通过更新请求计数器的请求计数值，确定当前已处理的历史请求数。

进一步地，在当前发包协程数量达到协程数阈值时，若请求指令下发失败，则表明当前的各发包协程均处于使用中，未检测到空闲状态的发包协程，而由于当前发包协程数量已经达到协程数阈值，即无法再新增其他发包协程，进而采用持续阻塞的方式，直至请求指令下发成功，即通过持续阻塞，停止压测发包处理操作，直至请求指令下发成功，确定当前存在空闲发包协程时，才触发该些空闲发包协程，用以进行压测发包处理。

上述压测控制处理方法中，在检测到压测处理请求时，获取压测处理请求对应的压测对象和各初始压测参数，并基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，以根据发包时间确定逻辑确定对应压测模式的发包时间间隔。进一步地，通过获取与压测对象对应的配置信息，并基于配置信息进行参数初始化处理以获得初始化后的各运行参数，从而可根据初始化后的各运行参数触发发包协程，并按照所确定出的当前实际的压测模式对应的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理，提升了压测发包处理效率，而进一步通过获取与压测对象对应的压测处理结果，可准确获知各压测对象的服务性能。

应该理解的是，虽然如上的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的压测控制处理方法的压测控制处理装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个压测控制处理装置实施例中的具体限定可以参见上文中对于压测控制处理方法的限定，在此不再赘述。

在一个实施例中，如图15所示，提供了一种压测控制处理装置，包括：初始压测参数获取模块1502、发包时间间隔确定模块1504、参数初始化模块1506、压测发包处理模块1508、以及压测处理结果获得模块1510，其中：

初始压测参数获取模块1502，用于若检测到压测处理请求，获取压测处理请求对应的压测对象、和各初始压测参数；

发包时间间隔确定模块1504，用于基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据发包时间确定逻辑确定对应压测模式的发包时间间隔；

参数初始化模块1506，用于获取与压测对象对应的配置信息，并基于配置信息进行参数初始化处理，获得初始化后的各运行参数；

压测发包处理模块1508，用于根据初始化后的各运行参数触发发包协程，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行压测发包处理；

压测处理结果获得模块1510，用于获取与压测对象对应的压测处理结果。

上述压测控制处理装置中，在检测到压测处理请求时，获取压测处理请求对应的压测对象和各初始压测参数，并基于初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，以根据发包时间确定逻辑确定对应压测模式的发包时间间隔。进一步地，通过获取与压测对象对应的配置信息，并基于配置信息进行参数初始化处理以获得初始化后的各运行参数，从而可根据初始化后的各运行参数触发发包协程，并按照所确定出的当前实际的压测模式的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理，提升了压测处理过程中的压测发包处理效率，而进一步通过获取与压测对象对应的压测处理结果，可准确获知各压测对象的服务性能。

在一个实施例中，发包时间间隔确定模块，还用于：若确定爬坡时间为空，确定与当前匹配的压测模式为第一压测模式；获取与第一压测模式匹配的第一发包时间确定逻辑，并根据第一发包时间确定逻辑确定第一压测模式下的预期总请求数；获取压测过程中的当前实际总请求数，若当前实际总请求数不小于预期总请求数，确定第一压测模式下的单个请求耗时；根据当前实际总请求数、第一压测模式下的单个请求耗时以及当前压测时长，确定与第一压测模式对应的发包时间间隔。

在一个实施例中，发包时间间隔确定模块，还用于：滑动获取上一秒实际总请求数；根据第一发包时间确定逻辑，基于初始发包速率、以及上一秒实际总请求数，确定第一压测模式下的预期总请求数。

在一个实施例中，发包时间间隔确定模块，还用于：基于初始发包速率和预设单位时间，确定第一压测模式下的单个请求耗时；根据当前实际总请求数和第一压测模式下的单个请求耗时，确定下一次发包预期时间；基于下一次发包预期时间、以及当前压测时长，确定与第一压测模式对应的发包时间间隔。

在一个实施例中，发包时间间隔确定模块，还用于：若确定爬坡时间不为空，确定与当前匹配的压测模式为第二压测模式；获取与第二压测模式匹配的第二发包时间确定逻辑，并根据第二发包时间确定逻辑确定第二压测模式下的预期总请求数；获取压测过程中的当前实际总请求数，若当前实际总请求数不小于预期总请求数，确定第二压测模式下的单个请求耗时；根据当前实际总请求数、预期总请求数以及第二压测模式下的单个请求耗时，确定与第二压测模式对应的发包时间间隔。

在一个实施例中，发包时间间隔确定模块，还用于：根据第二发包时间确定逻辑，基于第二压测模式下的初始发包速率、以及爬坡时间，确定与爬坡时间对应的第一当前发包速率；根据第二发包时间确定逻辑，确定与第二压测模式下的持续压测时间对应的第二当前发包速率；滑动获取在爬坡时间内时的第一上一秒实际总请求数、以及在持续压测时间内的第二上一秒实际总请求数；根据第一当前发包速率、第一上一秒实际总请求数，确定在爬坡时间内的第一预期请求数，以及根据第二当前发包速率、第二上一秒实际总请求数，确定在持续压测时间内的第二预期请求数。

在一个实施例中，发包时间间隔确定模块，还用于：基于与爬坡时间对应的第一当前发包速率、以及预设单位时间，确定第二压测模式下与爬坡时间对应的第一子单个请求耗时；根据与持续压测时间对应的第二当前发包速率、以及预设单位时间，确定第二压测模式下与持续压测时间对应的第二子单个请求耗时。

在一个实施例中，发包时间间隔确定模块，还用于：根据当前实际总请求数以及第一预期请求数，确定第一发包次数差值，并根据第一发包次数差值和第一子单个请求耗时，确定第二压测模式下与爬坡时间对应的第一子发包时间间隔；或根据当前实际总请求数以及第二预期请求数，确定第二发包次数差值，并根据第二发包次数差值和第二子单个请求耗时，确定第二压测模式下与持续压测时间对应的第二子发包时间间隔。

在一个实施例中，压测发包处理模块，还用于：根据初始并发请求数触发对应数量的发包协程，并根据压测起始时间和当前时间点，确定当前压测处理时间；若确定当前压测处理时间小于预设压测周期，则根据发包协程调用休眠控速函数，按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理。

在一个实施例中，压测发包处理模块，还用于：获取当前发包协程数量，并将当前发包协程数量和协程数阈值进行比对；若当前发包协程数量小于协程数阈值，基于状态信号量进行请求指令下发处理；若请求指令下发成功，更新请求计数值；若请求指令下发失败，触发新的发包协程；新的发包协程用于执行新增的压测处理请求。

在一个实施例中，压测发包处理模块，还用于：若当前发包协程数量达到协程数阈值，基于状态信号量进行请求指令下发处理；若请求指令下发成功，更新请求计数值；若请求指令下发失败，持续阻塞直至请求指令下发成功。

在一个实施例中，压测发包处理模块，还用于：通过发包协程接收状态信号量反馈的请求指令下发状态信息；若确定请求指令下发状态信息为请求指令下发成功，调用并执行发包函数按照所确定出的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理；若确定请求指令下发状态信息为请求指令下发失败，持续阻塞直至确定请求指令下发成功。

上述压测控制处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，如图16所示，提供了一种压测控制处理***，具体包括基础模块1602、定速器模块1604、压测框架1606、性能数据收集模块1608以及性能数据输出模块1610，其中：

基础模块1602，具体包括：命令行参数解析模块（即command模块）、业务测试用例编写模块（即Task模块）、压测日志记录模块（即Log模块）、压测参数配置模块（即Parameter模块）。

其中，命令行参数解析模块用于解析输入的命令行以获取各输入参数，包括输入的初始发包速率、目标发包速率、爬坡时间、压测时间以及预设压测周期等，业务测试用例编写模块用于开发构建对压测对象进行压测发包处理的各测试用例，压测日志记录模块用于对压测处理过程、压测处理结果等进行记录和存储，压测参数配置模块用于对压测处理过程中的各运行参数进行配置和初始化，包括对初始并发用户数即初始并发请求数、最大并发用户数即并发请求数阈值、与并发请求数阈值对应的协程数阈值、状态信号量、请求计数值以及协程组状态等运行参数进行配置和初始化处理。

定速器模块1604，具体包括：Constand Pacer即秒杀模式定速器、以及LinerPacer即爬坡模式定速器。其中，秒杀模式定速器对应第一压测模式，具体用于确定出第一压测模式下的发包时间间隔，并调用休眠控速函数，按照确定出的发包时间间隔，在预设压测周期内向压测对象进行压测发包处理。同样地，爬坡模式定速器对应第二压测模式，用于确定出第二压测模式下的发包时间间隔，并调用休眠控速函数，按照确定出的发包时间间隔，在预设压测周期内向压测对象进行压测发包处理。

压测框架1606具体为吞吐率压测框架，该压测框架下设置有秒杀模式即第一压测模式、以及爬坡模式即第二压测模式。

性能数据收集模块1608，具体包括request metrics模块（即所有性能数据收集模块）、latency metrics模块（即所有接口的时间数据收集模块）。其中，request metrics模块包括entry metrics模块（即收集单个接口的所有性能数据的模块）、以及error metrics模块（即收集单个接口的错误数据的模块），且latency metrics模块被entry metrics模块引用，即entry metrics模块可从latency metrics模块获取所需的单个接口的所有性能数据。

性能数据输出模块1610，具体包括console output模块（即通过控制台输出性能数据的输出模块）、Ctsdb output模块（即将性能数据输出至时序数据库中的输出模块）、以及Csv output模块（即将性能数据以Csv格式即逗号分隔值格式输出的输出模块）。

在一个实施例中，如图17所示，提供了一种耗时变化场景下压测控制处理***自适应调整并发数的示意图，具体是以用例耗时（即图17中的虚线）和并发请求数（即图17中的实线）为坐标轴，构建压测控制处理***根据用例耗时的变化，来动态调整并发请求数的示意图。

具体地，参照图17可知，压测控制处理***在进行压测控制处理过程中，在耗时变化场景下，可根据用例耗时的变化即压测时间的消耗，可自适应调整并发数，同时保持目标并发请求数，在耗时降低时，不会再继续增加并发请求数。

也就是说，相比利用传统的PTS平台（即Performance Testing Service，理解为分布式压测平台）、或locust平台（即分布式用户负载测试平台）进行压测控制处理时，需要人为设置并发请求数，采用的是传统的漏桶限流算法进行发包速率控制，既无法动态调整并发请求数，也不能适应不同的压测场景（比如耗时变化场景、固定耗时场景等），本申请实施例中的压测控制处理方法，可通过确定出不同的压测模式下的发包时间间隔，并在实际压测模式下按照所确定出的发包时间间隔，动态调整发包速率即可动态调整并发请求数，可减少服务资源浪费，提升压测发包处理效率。

在一个实施例中，如图18所示，提供了一种固定耗时场景下压测控制处理***的启动并发数示意图，具体是以用例耗时（即图18中的虚线）和并发请求数（即图18中的实线）为坐标轴，构建压测控制处理***在固定耗时场景下设置的启动并发数的示意图。

具体地，参照图18可知，在固定耗时场景（即用例耗时变化较小）的场景下，压测控制处理***根据不同的压测模式，确定相应压测模式下的发包时间间隔，达到相应的目标发包速率，从而确地出最佳启动并发请求数，避免服务资源的浪费。

也就是说，相比传统的PTS平台、或locust平台进行压测控制处理时，按照固定的换算比例确定统一的并发请求数，而不能确定出当前固定耗时场景下的最佳并发请求数，本申请实施例中的压测控制处理方法，可按照不同压测模式的发包时间间隔，动态调整发包速率即可动态调整并发请求数，可减少服务资源浪费，提升压测发包处理效率。

在一个实施例中，基于以下表1（即本申请实施例的压测控制处理方法的性能数据表）、和表2（即传统上基于locust平台的压测处理方法的性能数据表），对压测处理过程的性能数据进行比对说明：

表1本申请实施例的压测控制处理方法的性能数据表

表2 传统上基于locust平台的压测处理方法的性能数据表

其中，参照表1和表2可知，本申请实施例的压测控制处理方法的资源占用率，低于传统的基于locust平台的压测处理方法，且并发能力成倍提升。举例来说，比如并发数都是100时，本申请实施例的压测控制处理方法的RPS（即每秒请求数）为141000，locust的RPS为27100，通过计算两个RPS的比值，即得到本申请实施例压测控制处理方法的并发能力，为的基于locust平台的压测处理方法的6倍。

具体地，参照表1和表2可知，具体设置有两个cpu维度，一个是压测机的CPU消耗，一个是被压服务的CPU消耗。其中，并发数为100时，本申请实施例的压测控制处理方法下，压测机的CPU消耗低（即78%），被压服务的CPU消耗高（即82%），表明本申请实施例中的压测控制处理方法的发压能力高，性能好。而传统的基于locust平台的压测处理方法下，并发数为100时，其压测机的CPU消耗高（即99%），但是被压服务的CPU消耗低（即21%），表明传统的相应基于locust平台的压测处理方法的发压能力低，性能差。

上述压测控制处理***中，通过设置不同的压测模式，并根据不同压测模式对应的定速器，确定与不同压测模式对应的发包时间间隔，从而按照当前实际的压测模式对应的发包时间间隔，在预设压测周期内向压测对象进行定速压测发包处理，提升了压测发包处理效率。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图19所示。该计算机设备包括处理器、存储器、输入/输出接口(Input/Output，简称I/O）和通信接口。其中，处理器、存储器和输入/输出接口通过***总线连接，通信接口通过输入/输出接口连接到***总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作***、计算机程序和数据库。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用于存储压测对象、初始压测参数、压测模式、发包时间确定逻辑、发包时间间隔、配置信息、初始化后的各运行参数、发包协程以及压测处理结果等数据。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种压测控制处理方法。

本领域技术人员可以理解，图19中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-OnlyMemory，ROM）、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器（ReRAM）、磁变存储器（Magnetoresistive Random Access Memory，MRAM）、铁电存储器（Ferroelectric Random Access Memory，FRAM）、相变存储器（Phase Change Memory，PCM）、石墨烯存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic RandomAccess Memory，DRAM）等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (24)

1.一种压测控制处理方法，其特征在于，所述方法包括：

若检测到压测处理请求，获取所述压测处理请求对应的压测对象、和各初始压测参数；

基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔；所述初始压测参数包括爬坡时间、初始发包速率和目标发包速率；所述压测模式包括爬坡时间为空的第一压测模式、和爬坡时间不为空的第二压测模式；其中，在所述第二压测模式下，在爬坡时间内加速进行压测发包处理，从初始发包速率增加至目标发包速率，并在爬坡时间结束后稳定在目标发包速率进行压测发包处理；

获取与所述压测对象对应的配置信息，并基于所述配置信息进行参数初始化处理，获得初始化后的各运行参数；

根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理；

获取与所述压测对象对应的压测处理结果；

所述基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔，包括：

若确定所述爬坡时间不为空，确定与当前匹配的压测模式为第二压测模式；获取与所述第二压测模式匹配的第二发包时间确定逻辑，并根据所述第二发包时间确定逻辑确定所述第二压测模式下的预期总请求数；获取压测过程中的当前实际总请求数，若所述当前实际总请求数不小于所述预期总请求数，确定所述第二压测模式下的单个请求耗时；根据所述当前实际总请求数、所述预期总请求数以及所述第二压测模式下的单个请求耗时，确定与所述第二压测模式对应的发包时间间隔。

2.根据权利要求1所述的方法，其特征在于，所述初始压测参数还包括当前压测时长；所述基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔，包括：

若确定所述爬坡时间为空，确定与当前匹配的压测模式为第一压测模式；

获取与所述第一压测模式匹配的第一发包时间确定逻辑，并根据所述第一发包时间确定逻辑确定所述第一压测模式下的预期总请求数；

获取压测过程中的当前实际总请求数，若所述当前实际总请求数不小于所述预期总请求数，确定所述第一压测模式下的单个请求耗时；

根据所述当前实际总请求数、所述第一压测模式下的单个请求耗时以及所述当前压测时长，确定与所述第一压测模式对应的发包时间间隔。

3.根据权利要求2所述的方法，其特征在于，根据所述第一发包时间确定逻辑确定所述第一压测模式下的预期总请求数，包括：

滑动获取上一秒实际总请求数；

根据所述第一发包时间确定逻辑，基于所述初始发包速率、以及所述上一秒实际总请求数，确定所述第一压测模式下的预期总请求数。

4.根据权利要求2所述的方法，其特征在于，确定所述第一压测模式下的单个请求耗时的方式，包括：基于所述初始发包速率和预设单位时间，确定所述第一压测模式下的单个请求耗时；

根据所述当前实际总请求数、所述单个请求耗时以及当前压测时长，确定与所述第一压测模式对应的发包时间间隔，包括：

根据所述当前实际总请求数和所述第一压测模式下的单个请求耗时，确定下一次发包预期时间；

基于所述下一次发包预期时间、以及当前压测时长，确定与所述第一压测模式对应的发包时间间隔。

5.根据权利要求1所述的方法，其特征在于，所述初始压测参数还包括第二压测模式下的持续压测时间；所述第二压测模式下的预期总请求数，包括第一预期请求数和第二预期请求数；根据所述第二发包时间确定逻辑确定所述第二压测模式下的预期总请求数，包括：

根据所述第二发包时间确定逻辑，基于所述第二压测模式下的初始发包速率、以及所述爬坡时间，确定与所述爬坡时间对应的第一当前发包速率；

根据所述第二发包时间确定逻辑，确定与所述第二压测模式下的持续压测时间对应的第二当前发包速率；

滑动获取在所述爬坡时间内时的第一上一秒实际总请求数、以及在所述持续压测时间内的第二上一秒实际总请求数；

根据所述第一当前发包速率、所述第一上一秒实际总请求数，确定在所述爬坡时间内的第一预期请求数，以及根据所述第二当前发包速率、所述第二上一秒实际总请求数，确定在所述持续压测时间内的第二预期请求数。

6.根据权利要求5所述的方法，其特征在于，确定所述第二压测模式下的单个请求耗时的方式，包括：

基于与所述爬坡时间对应的第一当前发包速率、以及预设单位时间，确定所述第二压测模式下与所述爬坡时间对应的第一子单个请求耗时；

根据与所述持续压测时间对应的第二当前发包速率、以及所述预设单位时间，确定所述第二压测模式下与所述持续压测时间对应的第二子单个请求耗时。

7.根据权利要求6所述的方法，其特征在于，所述第二压测模式对应的发包时间间隔包括第一子发包时间间隔、第二子发包时间间隔；所述根据所述当前实际总请求数、所述预期总请求数以及所述单个请求耗时，确定与所述第二压测模式对应的发包时间间隔，包括：

根据所述当前实际总请求数以及所述第一预期请求数，确定第一发包次数差值，并根据所述第一发包次数差值和所述第一子单个请求耗时，确定所述第二压测模式下与所述爬坡时间对应的第一子发包时间间隔；

或

根据所述当前实际总请求数以及所述第二预期请求数，确定第二发包次数差值，并根据所述第二发包次数差值和所述第二子单个请求耗时，确定所述第二压测模式下与所述持续压测时间对应的第二子发包时间间隔。

8.根据权利要求1至7任意一项所述的方法，其特征在于，所述初始化后的各运行参数包括：初始并发请求数、并发请求数阈值、压测起始时间、以及预设压测周期；

所述根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理，包括：

根据所述初始并发请求数触发对应数量的发包协程，并根据所述压测起始时间和当前时间点，确定当前压测处理时间；

若确定所述当前压测处理时间小于所述预设压测周期，则根据所述发包协程调用休眠控速函数，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行定速压测发包处理。

9.根据权利要求8所述的方法，其特征在于，所述初始化后的各运行参数还包括：与所述并发请求数阈值对应的协程数阈值、状态信号量以及请求计数值；在所述根据所述发包协程调用休眠控速函数，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行定速压测发包处理时，还包括：

获取当前发包协程数量，并将所述当前发包协程数量和所述协程数阈值进行比对；

若所述当前发包协程数量小于所述协程数阈值，基于所述状态信号量进行请求指令下发处理；

若所述请求指令下发成功，更新所述请求计数值；

若所述请求指令下发失败，触发新的发包协程；所述新的发包协程用于执行新增的压测处理请求。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

若所述当前发包协程数量达到所述协程数阈值，基于所述状态信号量进行请求指令下发处理；

若所述请求指令下发成功，更新所述请求计数值；

若所述请求指令下发失败，持续阻塞直至所述请求指令下发成功。

11.根据权利要求9所述的方法，其特征在于，与所述发包协程对应的协程执行方式，包括：

通过所述发包协程接收所述状态信号量反馈的请求指令下发状态信息；

若确定所述请求指令下发状态信息为请求指令下发成功，调用并执行发包函数按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行定速压测发包处理；

若确定所述请求指令下发状态信息为请求指令下发失败，持续阻塞直至确定请求指令下发成功。

12.一种压测控制处理装置，其特征在于，所述装置包括：

初始压测参数获取模块，用于若检测到压测处理请求，获取所述压测处理请求对应的压测对象、和各初始压测参数；

发包时间间隔确定模块，用于基于所述初始压测参数确定与不同压测模式匹配的发包时间确定逻辑，并根据所述发包时间确定逻辑确定对应所述压测模式的发包时间间隔；所述初始压测参数包括爬坡时间、初始发包速率和目标发包速率；所述压测模式包括爬坡时间为空的第一压测模式、和爬坡时间不为空的第二压测模式；其中，在所述第二压测模式下，在爬坡时间内加速进行压测发包处理，从初始发包速率增加至目标发包速率，并在爬坡时间结束后稳定在目标发包速率进行压测发包处理；

参数初始化模块，用于获取与所述压测对象对应的配置信息，并基于所述配置信息进行参数初始化处理，获得初始化后的各运行参数；

压测发包处理模块，用于根据初始化后的各运行参数触发发包协程，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行压测发包处理；

压测处理结果获得模块，用于获取与所述压测对象对应的压测处理结果；

所述发包时间间隔确定模块，还用于：若确定所述爬坡时间不为空，确定与当前匹配的压测模式为第二压测模式；获取与所述第二压测模式匹配的第二发包时间确定逻辑，并根据所述第二发包时间确定逻辑确定所述第二压测模式下的预期总请求数；获取压测过程中的当前实际总请求数，若所述当前实际总请求数不小于所述预期总请求数，确定所述第二压测模式下的单个请求耗时；根据所述当前实际总请求数、所述预期总请求数以及所述第二压测模式下的单个请求耗时，确定与所述第二压测模式对应的发包时间间隔。

13.根据权利要求12所述的装置，其特征在于，所述发包时间间隔确定模块，还用于：

若确定所述爬坡时间为空，确定与当前匹配的压测模式为第一压测模式；获取与所述第一压测模式匹配的第一发包时间确定逻辑，并根据所述第一发包时间确定逻辑确定所述第一压测模式下的预期总请求数；获取压测过程中的当前实际总请求数，若所述当前实际总请求数不小于所述预期总请求数，确定所述第一压测模式下的单个请求耗时；根据所述当前实际总请求数、所述第一压测模式下的单个请求耗时以及当前压测时长，确定与所述第一压测模式对应的发包时间间隔。

14.根据权利要求13所述的装置，其特征在于，所述发包时间间隔确定模块，还用于：

滑动获取上一秒实际总请求数；根据所述第一发包时间确定逻辑，基于所述初始发包速率、以及所述上一秒实际总请求数，确定所述第一压测模式下的预期总请求数。

15.根据权利要求13所述的装置，其特征在于，所述发包时间间隔确定模块，还用于：

基于所述初始发包速率和预设单位时间，确定所述第一压测模式下的单个请求耗时；根据所述当前实际总请求数和所述第一压测模式下的单个请求耗时，确定下一次发包预期时间；基于所述下一次发包预期时间、以及当前压测时长，确定与所述第一压测模式对应的发包时间间隔。

16.根据权利要求13所述的装置，其特征在于，所述发包时间间隔确定模块，还用于：

根据所述第二发包时间确定逻辑，基于所述第二压测模式下的初始发包速率、以及所述爬坡时间，确定与所述爬坡时间对应的第一当前发包速率；根据所述第二发包时间确定逻辑，确定与所述第二压测模式下的持续压测时间对应的第二当前发包速率；滑动获取在所述爬坡时间内时的第一上一秒实际总请求数、以及在所述持续压测时间内的第二上一秒实际总请求数；根据所述第一当前发包速率、所述第一上一秒实际总请求数，确定在所述爬坡时间内的第一预期请求数，以及根据所述第二当前发包速率、所述第二上一秒实际总请求数，确定在所述持续压测时间内的第二预期请求数。

17.根据权利要求16所述的装置，其特征在于，所述发包时间间隔确定模块，还用于：

基于与所述爬坡时间对应的第一当前发包速率、以及预设单位时间，确定所述第二压测模式下与所述爬坡时间对应的第一子单个请求耗时；根据与所述持续压测时间对应的第二当前发包速率、以及所述预设单位时间，确定所述第二压测模式下与所述持续压测时间对应的第二子单个请求耗时。

18.根据权利要求17所述的装置，其特征在于，所述发包时间间隔确定模块，还用于：

根据所述当前实际总请求数以及所述第一预期请求数，确定第一发包次数差值，并根据所述第一发包次数差值和所述第一子单个请求耗时，确定所述第二压测模式下与所述爬坡时间对应的第一子发包时间间隔；或根据所述当前实际总请求数以及所述第二预期请求数，确定第二发包次数差值，并根据所述第二发包次数差值和所述第二子单个请求耗时，确定所述第二压测模式下与所述持续压测时间对应的第二子发包时间间隔。

19.根据权利要求12至18任意一项所述的装置，其特征在于，所述压测发包处理模块，还用于：

根据初始并发请求数触发对应数量的发包协程，并根据压测起始时间和当前时间点，确定当前压测处理时间；若确定所述当前压测处理时间小于所述预设压测周期，则根据所述发包协程调用休眠控速函数，按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行定速压测发包处理。

20.根据权利要求19所述的装置，其特征在于，所述压测发包处理模块，还用于：

获取当前发包协程数量，并将所述当前发包协程数量和协程数阈值进行比对；若所述当前发包协程数量小于所述协程数阈值，基于状态信号量进行请求指令下发处理；若所述请求指令下发成功，更新请求计数值；若所述请求指令下发失败，触发新的发包协程；所述新的发包协程用于执行新增的压测处理请求。

21.根据权利要求20所述的装置，其特征在于，所述压测发包处理模块，还用于：

若所述当前发包协程数量达到所述协程数阈值，基于所述状态信号量进行请求指令下发处理；若所述请求指令下发成功，更新所述请求计数值；若所述请求指令下发失败，持续阻塞直至所述请求指令下发成功。

22.根据权利要求20所述的装置，其特征在于，所述压测发包处理模块，还用于：

通过所述发包协程接收所述状态信号量反馈的请求指令下发状态信息；若确定所述请求指令下发状态信息为请求指令下发成功，调用并执行发包函数按照所确定出的所述发包时间间隔，在预设压测周期内向所述压测对象进行定速压测发包处理；若确定所述请求指令下发状态信息为请求指令下发失败，持续阻塞直至确定请求指令下发成功。

23.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至11中任一项所述的方法的步骤。

24.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至11中任一项所述的方法的步骤。