CN116450483A - 一种确定软件分配的负载的方法、装置、服务器及介质 - Google Patents

Abstract

本申请公开了一种确定软件分配的负载的方法、装置、服务器及介质，涉及测试领域。在该方法中按照大于1的预设步长增加并发量，得到增加后的并发量下的性能数据；在性能数据不满足预设要求时，根据新的当前并发量和新的当前并发量的上一个当前并发量对并发量进行收敛，确定出目标并发量，根据目标并发量为软件分配负载。可见，通过该方法确定出为软件分配的负载；此外，相比于依次增加并发量并获取各并发量下的性能数据确定为软件分配的负载的方法，本申请的方法大大减少了需要获取的并发量下的性能数据的数量，从而提高了获取软件的最优负载时的效率。此外，本申请还提供一种确定软件分配的负载的装置、服务器以及介质，效果同上。

Description

一种确定软件分配的负载的方法、装置、服务器及介质

技术领域

本申请涉及测试领域，特别是涉及一种确定软件分配的负载的方法、装置、服务器及介质。

背景技术

Apache JMeter是Apache组织基于Java开发的压力测试工具，用于对软件服务做压力测试。JMeter多用于Web应用测试，可对服务器、网络或对象模拟巨大的负载，在不同压力类别下测试它们的强度和分析整体性能。JMeter提供了命令行方式支持性能测试并提供了服务响应时长、成功率、每秒交易量等性能数据。

如何基于JMeter测试工具获取软件所能承载的最大负载是本领域人员亟需解决的技术问题。

发明内容

本申请的目的是提供一种确定软件分配的负载的方法，用于获取软件所能承载的最大负载。

为解决上述技术问题，本申请提供一种确定软件分配的负载的方法，包括：

控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，所述预设步长大于1；

通过JMeter获取在所述新的当前并发量下所述软件的当前性能数据；其中，性能数据至少包括所述服务响应性能数据及资源性能数据之一；

判断所述当前性能数据是否满足对应的预设要求；

若是，则返回所述控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量的步骤；

若否，则根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量；根据所述目标并发量为所述软件分配负载；其中，所述目标并发量为性能数据满足所述预设要求的并发量。

优选地，所述预设步长呈倍数递增。

优选地，所述根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量包括：

获取所述新的当前并发量和所述新的当前并发量的上一个当前并发量的当前中间并发量；

判断所述当前中间并发量下的性能数据是否满足所述预设要求；

若是，则确定所述当前中间并发量为所述目标并发量；

若否，则获取所述当前中间并发量与所述新的当前并发量的上一个当前并发量的中间并发量，并作为新的当前中间并发量；返回所述判断所述当前中间并发量下的性能数据是否满足所述预设要求的步骤。

优选地，所述服务响应性能数据至少包括响应成功率、平均响应时长；在所述性能数据为所述服务响应性能数据的情况下，所述判断所述服务响应性能数据是否满足对应的预设要求包括：

获取所述服务响应性能数据中的所述响应成功率以及所述平均响应时长；

判断所述响应成功率大于或等于响应成功率阈值以及所述平均响应时长是否小于或等于平均响应时长阈值；

在所述响应成功率大于或等于所述响应成功率阈值，且所述平均响应时长小于或等于所述平均响应时长阈值的情况下，返回所述控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量的步骤；

在所述响应成功率小于所述响应成功率阈值，或所述平均响应时长大于所述平均影响时长阈值的情况下，进入所述根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量的步骤。

优选地，在所述根据所述目标并发量为所述软件分配负载之前，所述方法还包括：

以docker容器为监控目标，监控所述服务的资源性能数据；其中，所述资源性能数据至少包括CPU利用率、内存占用率、GPU利用率、显存占用率之一；

获取任务的ID；其中，所述任务的ID根据所述当前服务和所述当前服务的并发量确定；

根据所述任务的ID对各所述任务对应的所述服务响应性能数据、所述资源性能数据进行归档。

优选地，所述根据所述任务的ID对各所述任务对应的所述服务响应性能数据、所述资源性能数据进行归档包括：

分别获取预设时长内各所述任务对应的所述服务响应性能数据均值、所述资源性能数据均值；

根据所述任务的ID对各所述任务对应的所述服务响应性能数据均值、所述资源性能数据均值进行归档。

优选地，在所述根据所述任务的ID对各所述任务对应的所述服务响应性能数据、所述资源性能数据进行归档之后，所述方法还包括：

根据当前任务的ID获取所述当前任务对应的归档信息；

解析所述当前任务对应的所述归档信息；

根据解析后的所述归档信息确定所述当前任务的性能数据。

为了解决上述技术问题，本申请还提供一种确定软件分配的负载的装置，包括：

控制模块，用于控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，所述预设步长大于1；

获取模块，用于通过JMeter获取在所述新的当前并发量下所述软件的当前性能数据；其中，性能数据至少包括所述服务响应性能数据及资源性能数据之一；

判断模块，用于判断所述当前性能数据是否满足对应的预设要求；若是，则触发所述控制模块，若否，则触发确定模块；

所述确定模块，用于根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量；根据所述目标并发量为所述软件分配负载；其中，所述目标并发量为性能数据满足所述预设要求的并发量。

为了解决上述技术问题，本申请还提供一种服务器，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现上述的确定软件分配的负载的方法的步骤。

为了解决上述技术问题，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的确定软件分配的负载的方法的步骤。

本申请所提供的一种确定软件分配的负载的方法，包括：控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，预设步长大于1；通过JMeter获取在新的当前并发量下软件的当前性能数据；其中，性能数据至少包括服务响应性能数据及资源性能数据之一；判断当前性能数据是否满足对应的预设要求；若是，则返回控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量的步骤；若否，则根据新的当前并发量和新的当前并发量的上一个当前并发量确定目标并发量；根据目标并发量为软件分配负载；其中，目标并发量为性能数据满足预设要求的并发量。由此可见，通过该方法确定出了为软件分配的最优的负载；此外，在确定为软件分配的负载时，按照大于1的预设步长增加并发量，得到增加后的并发量下的性能数据；在性能数据不满足预设要求的情况下，根据新的当前并发量和新的当前并发量的上一个当前并发量对并发量进行收敛，最终确定出目标并发量，根据目标并发量为软件分配负载。相比于依次增加并发量并获取各并发量下的性能数据确定为软件分配的目标并发量的方法，本申请的方法中大大减少了需要获取的并发量下的性能数据的数量，从而提高了获取服务的最优负载的效率。

此外，本申请还提供一种确定软件分配的负载的装置、服务器以及计算机可读存储介质，与上述提到的确定软件分配的负载的方法具有相同或相对应的技术特征，效果同上。

附图说明

为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种确定软件分配的负载的方法的流程图；

图2为本申请的一实施例提供的确定软件分配的负载的装置的结构图；

图3为本申请另一实施例提供的服务器的结构图；

图4为本申请实施例提供的一种自动化的JMeter压测方法的流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本申请保护范围。

本申请的核心是提供一种确定软件分配的负载的方法，用于获取软件所能承载的最大负载。

Apache JMeter是Apache组织基于Java开发的压力测试工具，用于对软件做压力测试。JMeter多用于Web应用测试，可对服务器、网络或对象模拟巨大的负载，在不同压力类别下测试它们的强度和分析整体性能。JMeter提供了命令行方式支持性能测试并提供了服务响应时长、成功率、每秒交易量等性能数据。为了得到软件最优性能下的所能承载的最大的负载，本申请提出一种确定应用分配的负载的方法。

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。图1为本申请实施例提供的一种确定软件分配的负载的方法的流程图，如图1所示，该方法包括：

S10：控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，预设步长大于1；

S11：通过JMeter获取在新的当前并发量下软件的当前性能数据；

S12：判断当前性能数据是否满足对应的预设要求；若是，则返回步骤S10；若否，则进入步骤S13；

S13：根据新的当前并发量和新的当前并发量的上一个当前并发量确定目标并发量；根据目标并发量为软件分配负载；其中，目标并发量为性能数据满足预设要求的并发量。

软件的性能数据至少包括服务响应性能数据及资源性能数据之一，比如中央处理器(Central Processing Unit，CPU)核数、内存、图形处理器(Graphics Processing Unit，GPU)利用率等。软件通常用来实现多种服务，因此，在获取软件的最大负载时需要在软件实现的不同的服务下进行确定，即在实现不同的服务下分别确定软件所能承载的最大负载。本申请实施例中确定软件的负载是根据并发量确定的。

通过软件在实现当前服务时，在当前服务下设置不同的并发量，获取各并发量下软件的性能数据，进而统计各并发量下的软件的性能数据，确定出软件在实现当前服务时，软件性能最佳对应的最大并大量，即确定软件在实现当前服务时的最大负载。本申请实施例中通过JMeter压力测试工具在获取各并发量时软件的性能数据。JMeter提供了命令行方式，支持通过命令设置并发量量、日志路径等参数，用户可通过查看输出报文获取服务响应时长、成功率、每秒交易量等性能数据。

以确定软件在实现当前服务时的最大负载为例，对于当前并发量的初始值(初始并发量)不作限定，但是，由于本实施例中将当前服务的当前并发量按照预设步长增加，因此，选取的初始并发量需要保证在初始并发量下软件的性能数据满足预设要求。确定初始并发量下软件的性能数据也是通过JMeter获取的。对于性能数据满足的预设要求不作限定，性能数据至少包括服务响应性能数据及资源性能数据，如响应成功率、平均响应时长等。不同的性能数据满足的预设要求不同。对响应成功率设置响应成功率阈值，则响应成功率满足的预设要求为响应成功率大于或等于响应成功率阈值。

在实施中，为了确定软件在实现当前服务时所能承载的最大负载，在当前并发量下所有的性能数据均满足对应的预设要求的情况下，才认为软件在实现当前服务时可以承载当前并发量。在当前并发量下的性能数据满足对应的预设要求时，说明在实现当前服务时，软件可以承载当前并发量，故而，可以继续增加并发量。实际中，由于软件实现的服务较多，若统计各服务下的不同并发量时对应的性能数据，对各并发量下对应的性能数据进行汇总对比，则需要较长的时间才能确定出各服务下的最大的并发量。故而，本实施例中在对各服务下的并发量进行测试时，按照大于1的步长增加并发量，获取各并发量下的性能数据。对于预设步长的值不作限定，只要是以大于1的步长增加并发量即可；此外，预设步长可以是固定值，也可以不是按照固定值。如在每次增加并发量时，均以步长为3进行增加；或者第一次以步长为2增加并发量，在第二次以步长为3增加并发量。

如设置的初始并发量为1，即1个用户访问当前服务，假设通过JMeter获取到并发量为1时软件的性能数据满足预设要求，则按照预设步长增当前并发量，若预设步长为2，即新的当前并发量为3，然后通过JMeter获取并发量为3时的性能数据，假设对并发量为3时的性能数据进行分析后发现，各性能数据均满足对应的预设要求，则继续按照预设步长增加并发量；假设此时预设步长为3，则新的当前并发量为6，然后通过JMeter获取并发量为6时的性能数据，假设对并发量为6时的性能数据进行分析后发现，在当前性能数据中存在不满足对应预设要求的情况，故而，认为并发量为6时超出软件的承载的范围，然后根据当前并发量6以及当前并发量的上一个并发量3确定出目标并发量。需要说明的是，在目标并发量下软件的性能数据满足对应的预设要求。假设确定出目标并发量为4，即可以认为软件在实现当前服务时，软件性能最佳时对应的目标并发量为4，然后根据目标并发量4为软件分配负载。

本实施例所提供的确定软件分配的负载的方法，包括：控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，预设步长大于1；通过JMeter获取在新的当前并发量下软件的当前性能数据；其中，性能数据至少包括服务响应性能数据及资源性能数据之一；判断当前性能数据是否满足对应的预设要求；若是，则返回控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量的步骤；若否，则根据新的当前并发量和新的当前并发量的上一个当前并发量确定目标并发量；根据目标并发量为软件分配负载；其中，目标并发量为性能数据满足预设要求的并发量。由此可见，通过该方法确定出了为软件分配的最优的负载；此外，在确定为软件分配的负载时，按照大于1的预设步长增加并发量，得到增加后的并发量下的性能数据；在性能数据不满足预设要求的情况下，根据新的当前并发量和新的当前并发量的上一个当前并发量对并发量进行收敛，最终确定出目标并发量，根据目标并发量为软件分配负载。相比于依次增加并发量并获取各并发量下的性能数据确定为软件分配的目标并发量的方法，本申请实施例的方法中大大减少了需要获取的并发量下的性能数据的数量，从而提高了获取软件的最优负载的效率。

在实施中，为了提高确定软件分配的最大负载的效率，优选的实施方式是，预设步长呈倍数递增。

预设步长呈倍数递增。如初始并发量为1，然后依次按照2、4、8、16、32……的并发量确定各并发量下的性能数据。并发量增加到的最大值根据该并发量下获取到的软件的性能数据确定，当在该并发量下软件的性能数据不满足对应的预设要求，则不再增加该并发量。

本实施例提供的预设步长呈倍数递增的方式，相比于按照步长为1的方式增加并发量，并依次对各并发量下的性能数据进行判断，本实施例的方法中能够大大减少获取的性能数据的次数，从而提高了确定软件分配的最大负载的效率。

上述实施例中预设步长呈倍数递增，为了确定出软件最佳性能下对应的最大负载，优选的实施方式是，根据新的当前并发量和新的当前并发量的上一个当前并发量确定目标并发量包括：

获取新的当前并发量和新的当前并发量的上一个当前并发量的当前中间并发量；

判断当前中间并发量下的性能数据是否满足预设要求；

若是，则确定当前中间并发量为目标并发量；

若否，则获取当前中间并发量与新的当前并发量的上一个当前并发量的中间并发量，并作为新的当前中间并发量；返回判断当前中间并发量下的性能数据是否满足预设要求的步骤。

如并发量按照从1、2、4、8、16、32……的顺序呈倍数递增。假设并发量增加到32时，通过JMeter获取在并发量为32下软件的当前性能数据，对当前性能数据进行分析发现当前性能数据不满足预设要求。由于并发量为16时的性能数据满足对应的预设要求，而并发量为32时的性能数据不满足对应的预设要求，因此，可以确定出软件所能承载的最大并发量在16和32之间，故而可以根据并发量为16和并发量为32确定出目标并发量。对于根据并发量为16和并发量为32确定的目标并发量可以认为是并发量收敛的过程。本申请实施例中确定目标并发量的过程中采用的是二分法收敛并发量。在确定出目标并发量在16和32之间时，取16和32的中间值24，获取并发量为24时的性能数据，并判断性能数据是否满足对应的预设要求，如果并发量为24时的性能数据满足对应的预设要求，则确定出目标并发量为24，从而根据目标并发量为24为软件分配负载；如果并发量为24时的性能数据不满足对应的预设要求，则将目标并发量的范围缩小至16至24之间，然后取并发量为16和并发量为24的之间值20，获取并发量为20时的性能数据，并判断性能数据是否满足对应的预设要求，如果并发量为20时的性能数据满足对应的预设要求，则确定出目标并发量为20；如果并发量为20时的性能数据不满足对应的预设要求，则继续缩小目标并发量的范围为16至20之间，然后取并发量为16和并发量为20时的中间值18；重复上述过程直至获取到目标并发量的值。

本实施例提供的方法中，通过二分法收敛并发量，从而对确定出的并发量对应的性能数据进行分析，确定出目标并发量，依据确定出的并发量为软件分配负载。将并发量按照倍数递增，且在性能数据不满足预设要求的情况下，通过二分法收敛并发量，最终确定出目标并发量，相比于依次增加并发量确定软件性能最佳时对应的负载数的方式，本实施例的方法能够较快速地确定出软件性能最佳时对应的负载的数量。

性能数据中包含多种参数，如服务响应性能数据至少包括响应成功率、平均响应时长。若只以性能数据中的一种参数判断性能数据是否满足预设要求，则可能得到的并不是软件性能最佳时所能承载的最大负载。故而，优选的实施方式是，在性能数据为服务响应性能数据的情况下，判断服务响应性能数据是否满足对应的预设要求包括：

获取服务响应性能数据中的响应成功率以及平均响应时长；

判断响应成功率大于或等于响应成功率阈值以及平均响应时长是否小于或等于平均响应时长阈值；

在响应成功率大于或等于响应成功率阈值，且平均响应时长小于或等于平均响应时长阈值的情况下，返回控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量的步骤；

在响应成功率小于响应成功率阈值，或平均响应时长大于平均影响时长阈值的情况下，进入根据新的当前并发量和新的当前并发量的上一个当前并发量确定目标并发量的步骤。

对于响应成功率阈值、平均响应时长不作限定，如在测试某web服务时，设置的响应成功率阈值为100％，平均响应时长阈值为3s。若当前服务的当前并发量下响应成功率小于100％或平均响应时长大于3s，则认为软件在实现当前服务时不能承载当前并发量；若当前服务的当前并发量下响应成功率等于100％，且平均响应时长不超过3s，则认为软件在实现当前服务时能够承载当前并发量，进而可以将当前并发量继续增加，对增加后的新的当前并发量下的性能数据作出同样的分析。

本实施例提供的方法，相比于性能数据中的部分参数满足对应的预设要求的情况下，按照预设步长增加并发量的方式，本实施例提供的方法中，性能数据中的所有的参数均满足对应的预设要求的情况下，按照预设步长增加并发量，使得确定出的目标并发量较为准确，从而能够根据目标并发量为软件分配合适的负载。

为了获取到在确定为软件分配的负载的过程中的资源使用情况，优选的实施方式是，在根据目标并发量为软件分配负载之前，确定软件分配的负载的方法还包括：

以docker容器为监控目标，监控服务的资源性能数据；其中，资源性能数据至少包括CPU利用率、内存占用率、GPU利用率、显存占用率之一；

获取任务的身份识别号(Identity Document，ID)；其中，任务ID根据当前服务和当前服务的并发量确定；

根据任务的ID对各任务对应的服务响应性能数据、资源性能数据进行归档。

在对当前服务的当前并发量下的性能数据进行测试时监控目标的资源使用情况。本实施中，以docker容器为监控目标，采集CPU利用率、内存占用、GPU利用率、显存占用等。随着云原生应用在人工智能(Artificial Intelligence，AI)、大数据、边缘计算等场景的不断实践和落地，这类应用的性能测试需求也越来越多。支持单容器/多容器，单GPU卡/多GPU卡的资源监控及统计，并根据任务ID及并发量量对统计结果进行归档。需要说明的是，此处的任务是根据当前服务和当前服务的当前并发量的数量共同确定的。如将服务1、并发量为1作为任务1；将服务2、并发量为2作为任务2；将服务3、并发量为3作为任务3……。对任务1时的服务响应性能数据、资源响应性能数据；任务2时的服务响应性能数据、资源响应性能数据等进行归档。

本实施例提供的方法中，在确定为软件分配的负载的过程中对资源的使用情况进行监控；此外，对各任务下的性能数据进行归档，方便用户了解到各任务下的资源使用情况。

在确定软件在实现当前服务时，为了较准确地获取到在当前并发量下的性能数据，可能多次获取性能数据。在进行归档时，若对每次测试时的数据均进行归档，则可能会出现大量的数据；或者在测试的过程中，可能会受到干扰，导致某一次或者某几次的测试结果差异较大。因此，在进行归档时，优选的实施方式是，根据任务的ID对各任务对应的服务响应性能数据、资源性能数据进行归档包括：

分别获取预设时长内各任务对应的服务响应性能数据均值、资源性能数据均值；

根据任务的ID对各任务对应的服务响应性能数据均值、资源性能数据均值进行归档。

本实施例提供的方法中，在进行归档时以服务响应性能数据均值、资源性能数据均值进行归档，一方面，能够减少需要记录的数据；另一方面，能够减少获得的性能数据的误差。

在获取到当前服务的目标并发量后，为了方便用户了解各并发量下的性能数据，优选的实施方式是，在根据任务的ID对各任务对应的服务响应性能数据、资源性能数据进行归档之后，确定软件分配的负载的方法还包括：

根据当前任务的ID获取当前任务对应的归档信息；

解析当前任务对应的归档信息；

根据解析后的归档信息确定当前任务的性能数据。

在测试结束后，根据当前任务ID及并发量量获取JMeter的日志归档，然后通过解析json报文获取本次测试的性能数据，包括成功率、响应时长、每秒交易数量等，并根据任务ID及并发量量对解析结果进行重新归档。

在上述实施例中，对于确定软件分配的负载的方法进行了详细描述，本申请还提供确定软件分配的负载的装置、服务器对应的实施例。需要说明的是，本申请从两个角度对装置部分的实施例进行描述，一种是基于功能模块的角度，另一种是基于硬件的角度。

图2为本申请的一实施例提供的确定软件分配的负载的装置的结构图。本实施例基于功能模块的角度，包括：

控制模块10，用于控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，预设步长大于1；

获取模块11，用于通过JMeter获取在新的当前并发量下软件的当前性能数据；其中，性能数据至少包括服务响应性能数据及资源性能数据之一；

判断模块12，用于判断当前性能数据是否满足对应的预设要求；若是，则触发控制模块10，若否，则触发确定模块13；

确定模块13，用于根据新的当前并发量和新的当前并发量的上一个当前并发量确定目标并发量；根据目标并发量为软件分配负载；其中，目标并发量为性能数据满足预设要求的并发量。

由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本实施例提供的确定软件分配的负载的装置中，通过控制模块控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，预设步长大于1；利用获取模块，通过JMeter获取在新的当前并发量下软件的当前性能数据；其中，性能数据至少包括服务响应性能数据及资源性能数据之一；通过判断模块判断当前性能数据是否满足对应的预设要求；若是，则触发控制模块，若否，则触发确定模块根据新的当前并发量和新的当前并发量的上一个当前并发量确定目标并发量；根据目标并发量为软件分配负载；其中，目标并发量为性能数据满足预设要求的并发量。由此可见，通过该装置确定出了为软件分配的最优的负载；此外，在确定为软件分配的负载时，按照大于1的预设步长增加并发量，得到增加后的并发量下的性能数据；在性能数据不满足预设要求的情况下，根据新的当前并发量和新的当前并发量的上一个当前并发量对并发量进行收敛，最终确定出目标并发量，根据目标并发量为软件分配负载。相比于依次增加并发量并获取各并发量下的性能数据确定为软件分配的目标并发量的方法，本实施例的装置中大大减少了需要获取的并发量下的性能数据的数量，从而提高了获取服务的最优负载的效率。

图3为本申请另一实施例提供的服务器的结构图。本实施例基于硬件角度，如图3所示，服务器包括：

存储器20，用于存储计算机程序；

处理器21，用于执行计算机程序时实现如上述实施例中所提到的确定软件分配的负载的方法的步骤。

本实施例提供的服务器可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。

其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用数字信号处理器(Digital Signal Processor，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以集成有GPU，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括AI处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器20可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器20还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器20至少用于存储以下计算机程序201，其中，该计算机程序被处理器21加载并执行之后，能够实现前述任一实施例公开的确定软件分配的负载的方法的相关步骤。另外，存储器20所存储的资源还可以包括操作系统202和数据203等，存储方式可以是短暂存储或者永久存储。其中，操作系统202可以包括Windows、Unix、Linux等。数据203可以包括但不限于上述所提到的确定软件分配的负载的方法所涉及到的数据等。

在一些实施例中，服务器还可包括有显示屏22、输入输出接口23、通信接口24、电源25以及通信总线26。

本领域技术人员可以理解，图3中示出的结构并不构成对服务器的限定，可以包括比图示更多或更少的组件。

本申请实施例提供的服务器，包括存储器和处理器，处理器在执行存储器存储的程序时，能够实现如下方法：确定软件分配的负载的方法，效果同上。

本申请还提供一种计算机可读存储介质对应的实施例。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述方法实施例中记载的步骤。

可以理解的是，如果上述实施例中的方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请提供的计算机可读存储介质包括上述提到的确定软件分配的负载的方法，效果同上。

为了使本技术领域的人员更好地理解本申请方案，下面结合附图4和具体实施方式对本申请作进一步的详细说明。图4为本申请实施例提供的一种自动化的JMeter压测方法的流程图，如图4所示，该方法包括：

S14：对当前组合jmx在当前并发量进行JMeter测试，并获取当前测试结果；

S15：判断当前测试结果是否满足对应的阈值；若否，则进入步骤S16；若是，则进入步骤S17；

S16：令新的当前并发量＝当前并发量*2，并返回步骤S14；

S17：二分法计算并发量，并发量＝(当前并发量+当前并发量的上一个并发量)/2；

S18：判断并发量是否大于当前并发量的上一个并发量；若是，则进入步骤S19；若否，则进入步骤S20；

S19：将并发量作为当前并发量，并返回步骤S14；

S20：进行日志归档；

S21：获取新的组合jmx，并将新的组合jmx作为当前组合，返回步骤S14。

在进行步骤S14的时，可以进行性能数据采集，具体包含docker性能采集和GPU性能采集，对docker性能采集后得到docker性能数据，对GPU性能采集后得到GPU性能数据。docker性能采集函数，支持多个docker的性能采集并进行均值归档处理；GPU性能采集函数，支持多个GPU卡的性能采集并进行均值归档处理。

在步骤S20后，可以对性能数据进行均值处理并归档，得到docker性能数据和GPU性能数据。

在步骤S20后，可以解析JMeter报文并归档。加载JMeter输出的json报文，获取本次压测的平均响应时间、成功率、每秒交易笔数等信息，并根据任务名称及并发数量进行归档。

多种组合压测脚本需要进行测试，如包含组合1.jmx、组合2.jmx……，组合n.jmx，本实施例是单jmx进行压测，如先对组合1.jmx执行上述的步骤S14至步骤S20；然后再依次对2.jmx执行步骤S14至步骤S20，直至对n.jmx执行步骤S14至步骤S20，完成压测。需要说明的是，此处的组合1.jmx、组合2.jmx……组合n.jmx可以认为服务1，服务2……服务n；各服务和各服务下的并发量组成任务，如服务1和并发量1可以认为是任务1，服务1和并发量2可以认为是任务2。在使用JMeter进行压测时，输入参数：jmx文件路径地址，任务名称，平均响应阈值，目标容器ID，容器所在节点；调用JMeter进行性能测试，调用docker性能监控脚本以及调用GPU性能监控脚本等待JMeter运行结束；调用性能解析脚本，判断性能是否超过阈值，如果没有超过阈值，则可以呈倍数递增并发量；若果超过阈值，则二分法计算并发量，返回性能数据的获取的步骤，直到收敛结束，确定出软件性能最佳时对应的负载。

本实施例提供的方法中，针对每一个要测试的jmx脚本，首先通过倍数递增的方式加大并发量，当性能数据超过控制系数阈值时，通过二分法收敛并发数，最终获取到软件在实现各服务时，软件性能最佳时对应的最大并发量。由于对软件进行测试时需要调整不同的测试参数，比如并发数量，应用资源，应用启动参数等，若测试人员对不同组合条件下的服务响应性能及资源性能数据(比如CPU核数、内存、GPU利用率等)进行汇总比对确定出软件的最大负载。当组合条件较多时人工操作并统计较为耗时繁琐，且容易出错，而本申请中支持多个组合条件的jmx脚本的自动化测试，测试结果及性能数据按任务ID进行归类；支持具体jmx脚本的多并发测试，用户可通过设置成功率、响应时长等参数阈值实现自动化性能测试，并通过逐步收敛自动达到目标范围的最优结果；支持自动化采集测试过程中的应用性能及资源性能数据，帮助测试人员自动化完成多并发测试。此外，在确定为软件分配的负载时，按照倍数递增并发量进行压测，得到增加后的并发量下的性能数据；在性能数据不满足预设要求的情况下，根据新的当前并发量和新的当前并发量的上一个当前并发量对并发量进行收敛，最终确定出目标并发量，根据目标并发量为软件分配负载。相比于依次增加并发量并获取各并发量下的性能数据确定为软件分配的目标并发量的方法，本实施例的装置中大大减少了需要获取的并发量下的性能数据的数量，从而提高了获取软件的最优负载的效率。

以上对本申请所提供的一种确定软件分配的负载的方法、装置、服务器及介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种确定软件分配的负载的方法，其特征在于，包括：

控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，所述预设步长大于1；

通过JMeter获取在所述新的当前并发量下所述软件的当前性能数据；其中，性能数据至少包括所述服务响应性能数据及资源性能数据之一；

判断所述当前性能数据是否满足对应的预设要求；

若是，则返回所述控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量的步骤；

若否，则根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量；根据所述目标并发量为所述软件分配负载；其中，所述目标并发量为性能数据满足所述预设要求的并发量。

2.根据权利1所述的确定软件分配的负载的方法，其特征在于，所述预设步长呈倍数递增。

3.根据权利要求2所述的确定软件分配的负载的方法，其特征在于，所述根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量包括：

获取所述新的当前并发量和所述新的当前并发量的上一个当前并发量的当前中间并发量；

判断所述当前中间并发量下的性能数据是否满足所述预设要求；

若是，则确定所述当前中间并发量为所述目标并发量；

若否，则获取所述当前中间并发量与所述新的当前并发量的上一个当前并发量的中间并发量，并作为新的当前中间并发量；返回所述判断所述当前中间并发量下的性能数据是否满足所述预设要求的步骤。

4.根据权利要求1所述的确定软件分配的负载的方法，其特征在于，所述服务响应性能数据至少包括响应成功率、平均响应时长；在所述性能数据为所述服务响应性能数据的情况下，所述判断所述服务响应性能数据是否满足对应的预设要求包括：

获取所述服务响应性能数据中的所述响应成功率以及所述平均响应时长；

判断所述响应成功率大于或等于响应成功率阈值以及所述平均响应时长是否小于或等于平均响应时长阈值；

在所述响应成功率大于或等于所述响应成功率阈值，且所述平均响应时长小于或等于所述平均响应时长阈值的情况下，返回所述控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量的步骤；

在所述响应成功率小于所述响应成功率阈值，或所述平均响应时长大于所述平均影响时长阈值的情况下，进入所述根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量的步骤。

5.根据权利要求1至4任意一项所述的确定软件分配的负载的方法，其特征在于，在所述根据所述目标并发量为所述软件分配负载之前，所述方法还包括：

以docker容器为监控目标，监控所述服务的资源性能数据；其中，所述资源性能数据至少包括CPU利用率、内存占用率、GPU利用率、显存占用率之一；

获取任务的ID；其中，所述任务的ID根据所述当前服务和所述当前服务的并发量确定；

根据所述任务的ID对各所述任务对应的所述服务响应性能数据、所述资源性能数据进行归档。

6.根据权利要求5所述的确定软件分配的负载的方法，其特征在于，所述根据所述任务的ID对各所述任务对应的所述服务响应性能数据、所述资源性能数据进行归档包括：

分别获取预设时长内各所述任务对应的所述服务响应性能数据均值、所述资源性能数据均值；

根据所述任务的ID对各所述任务对应的所述服务响应性能数据均值、所述资源性能数据均值进行归档。

7.根据权利要求6所述的确定软件分配的负载的方法，其特征在于，在所述根据所述任务的ID对各所述任务对应的所述服务响应性能数据、所述资源性能数据进行归档之后，所述方法还包括：

根据当前任务的ID获取所述当前任务对应的归档信息；

解析所述当前任务对应的所述归档信息；

根据解析后的所述归档信息确定所述当前任务的性能数据。

8.一种确定软件分配的负载的装置，其特征在于，包括：

控制模块，用于控制当前服务的当前并发量按照预设步长增加，并将增加后的并发量作为新的当前并发量；其中，所述预设步长大于1；

获取模块，用于通过JMeter获取在所述新的当前并发量下所述软件的当前性能数据；其中，性能数据至少包括所述服务响应性能数据及资源性能数据之一；

判断模块，用于判断所述当前性能数据是否满足对应的预设要求；若是，则触发所述控制模块，若否，则触发确定模块；

所述确定模块，用于根据所述新的当前并发量和所述新的当前并发量的上一个当前并发量确定目标并发量；根据所述目标并发量为所述软件分配负载；其中，所述目标并发量为性能数据满足所述预设要求的并发量。

9.一种服务器，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述的确定软件分配的负载的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的确定软件分配的负载的方法的步骤。