性能评测方法及装置、设备、存储介质

技术领域

本申请涉及通信技术，涉及但不限于一种性能评测方法及装置、设备、存储介质。

背景技术

在企业界，各大互联网公司为了提升存储系统的性能也都部署了自己的内存关键字-值(key-value，KVS)存储系统平台。Facebook使用高速缓存系统(Memcached)建立了一个拥有上千台服务器节点的分布式内存缓存系统。全球最大的图片社交分享网站Pinterest为了拥有更好的用户体验，使用Redis存储日益增长的数据。在国内，作为社交平台之一的新浪微博也是使用Redis来存储数据。学术界对内存KVS的研究也越来越多。

随着诸多内存KVS产品的问世，客观、公平地评测这些内存KVS的性能也变得愈发重要。内存KVS性能评测需要参考相关数据库评测基准。数据库基准测试旨在客观、公证地评测数据库产品的性能，以激励数据库厂商优化其产品。自从威斯康星评测基准被提出以来，数据库评测基准已在过去30年里取得了巨大的成功。事务处理性能委员会(Transaction Processing Performance Council，TPC)提出了一系列基准来评测关系型数据库，包括TPC-C、TPC-H、TPC-E、TPC-DS等，得到学术界和工业界的广泛认可。其他典型基准包括针对决策支持系统的星型模式评测基准(StarSchemaBenchmark，SSB)和混合了TPC-H和TPC-C工作负载的CH-Benchmark。相关数据库将数据存储于磁盘中，再通过大量的I/O操作执行数据库管理任务，相关技术中的基准均力求反应这一重要特性。然而内存KVS在启动时将数据全部加载到内存、进而进行管理，相关的评测基准无法用来评测内存KVS。然而，相关技术中的评测工具无法支持Redis Cluster(Remote Dictionary Server Cluster，Redis集群)，学术界也没有Redis Cluster性能评测方面的研究。

根据调研，Redis Cluster自从问世以来，就没有专业的评测工具能对RedisCluster的性能进行准确的测评。在现有内存KVS性能评测工具中，内存性能测试器(memtier_benchmark)应用比较广泛。它提供了强大的定制功能，用户可以根据自己的需求按一定比例、模式发送不同大小读写请求；同时用户也可以根据实际需求将memtier_benchmark配置成多客户端模式，即模拟多个客户端对内存KVS发送数据包进行评测；此外memtier_benchmark可以通过设置多线程和发送管线(pipeline)的深度来提高发送请求的并发度。但相关技术中的memtier_benchmark只支持Memcached和单机版的Redis。

发明内容

有鉴于此，本申请提供的性能评测方法及装置、设备、存储介质，能够评测出对于具有不同数据长度的第一请求，集群系统在单位时间内分别能够处理的数量上限。本申请提供的性能评测方法及装置、设备、存储介质是这样实现的：

本申请提供的性能评测方法，包括：逐步增加单位时间内发送给集群系统的第一请求的第一数量；其中，所述第一请求具有固定数据长度；所述第一请求用于请求所述集群系统存储所述第一请求携带的数据；确定所述集群系统对每单位时间内接收的第一数量的第一请求的第一处理时长；根据每一所述第一处理时长，测量所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限。

本申请提供的性能评测装置，包括：调节模块，用于逐步增加单位时间内发送给集群系统的第一请求的数量；其中，所述第一请求具有固定数据长度；所述第一请求用于请求所述集群系统存储所述第一请求携带的数据；确定模块，用于确定所述集群系统对每单位时间内接收的第一数量的第一请求的第一处理时长；确定模块，还用于根据每一所述第一处理时长，测量所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限。

本申请提供的电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现本申请所述的方法。

本申请提供的计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本申请提供的所述的方法。

在本申请中，通过逐步增加单位时间内发送给集群系统的具有固定数据长度的第一请求的第一数量的方式，确定集群系统对每单位时间内接收的第一数量的第一请求的第一处理时长；根据每一次测量得到的第一处理时长，测量集群系统在单位时间内能够处理的具有固定数据长度的第一请求的数量上限。如此，能够评测出对于具有不同数据长度的第一请求，集群系统在单位时间内分别能够处理的数量上限，从而实现对集群系统性能的评测研究，也即，能够评测出承载集群系统的平台的CPU处理效率对集群系统的性能的影响。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。

图1为本申请提供的一种性能评测方法的实现流程示意图；

图2为本申请提供的另一性能评测方法的实现流程示意图；

图3为本申请提供的又一性能评测方法的实现流程示意图；

图4为本申请提供的再一性能评测方法的实现流程示意图；

图5为本申请提供的又一性能评测方法的实现流程示意图；

图6为本申请提供的评测模块的功能结构示意图；

图7为本申请提供的节点管理子模块的初始化过程示意图；

图8为本申请提供的集群节点变化处理过程示意图；

图9为本申请提供的在评测模块内部请求创建的过程示意图；

图10为本申请提供的请求应答处理的过程示意图；

图11为本申请提供的创建异步事件的过程示意图；

图12为本申请提供的客户端子模块的初始化过程示意图；

图13为本申请提供的评测模块各个类以及类之间的关系示意图；

图14为本申请性能评测装置的结构示意图；

图15为本申请提供的电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请中的附图，对本申请的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请的目的，不是旨在限制本申请。在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

需要指出，本申请所涉及的术语“第一\第二\第三”用以区别类似或不同的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请能够以除了在这里图示或描述的以外的顺序实施。

本申请提供一种性能评测方法，该方法应用于电子设备，该电子设备在实施的过程中可以为各种类型的具有信息处理能力的设备。例如，所述电子设备可以包括个人计算机、笔记本电脑、掌上电脑或服务器等；该电子设备还可以为移动终端，例如所述移动终端可以包括手机、车载电脑、平板电脑或投影仪等。该方法所实现的功能可以通过电子设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该电子设备至少包括处理器和存储介质。

图1为本申请实施例提供的性能评测方法的实现流程示意图，如图1所示，该方法可以包括以下步骤101至步骤103：

步骤101，评测系统逐步增加单位时间内发送给集群系统的第一请求的第一数量；其中，所述第一请求具有固定数据长度。

在本申请中，评测系统在发送具有固定数据长度的第一请求时，是按照特定的第一步长，逐步增加单位时间内发送给集群系统的第一请求的数量的，可见，评测系统在每次测试时，发送给集群系统的第一请求的数量为多个，且数量并不固定。

举例来说，在第一次评测中，评测系统发送固定数据长度为46字节的第一请求给集群系统，先发送100个第一请求给集群系统，确定集群系统在单位时间内处理的第一请求的个数；再发送200个第一请求给集群系统，再次确定集群系统在单位时间内处理的第一请求的个数；以100个请求为第一步长，逐次增加发送给集群系统的第一请求的数量，直至发现某次发送的第一请求的数量增长，而集群系统在单位时间内处理的第一请求的个数并未增长时(比如，上一次发送的第一请求数量为1400，集群系统能够在单位时间内处理完1400个请求；而当次发送的第一请求数量增长为1600，但集群系统在单位时间内处理的第一请求数量仍然为1400个)，则能够确定集群系统在当前第一请求的固定数据长度为46字节的情况下，能够处理的最大的请求数量为1400个。

在第二次评测中，评测系统发送固定数据长度为48字节的第一请求给集群系统，先发送100个第一请求给集群系统，确定集群系统在单位时间内处理的第一请求的个数；再发送200个第一请求给集群系统，再次确定集群系统在单位时间内处理的第一请求的个数；以100个请求为发送步长，逐次增加发送给集群系统的第一请求的数量，直至发现某次发送的第一请求的数量增长，而集群系统在单位时间内处理的第一请求的个数并未增长时(比如，上一次发送的第一请求数量为1300，集群系统能够在单位时间内处理完1300个请求；而当次发送的第一请求数量增长为1400，但集群系统在单位时间内处理的第一请求数量仍然为1300个)，则能够确定集群系统在当前第一请求的固定数据长度为48字节的情况下，能够处理的最大的请求数量为1300个。

在本申请中，评测系统在对集群系统单位时间内能够处理的固定数据长度的第一请求的数量上限进行评测时，其他影响集群系统处理能力的参数是保存不变的，比如，网络传输带宽、请求类型或请求中携带的键值范围等。

在一些实施例中，第一请求的类型可以为set请求。

步骤102，评测系统确定所述集群系统对每单位时间内接收的第一数量的第一请求的第一处理时长。

评测系统发送第一请求给集群系统之后，集群系统会对接收到的第一请求进行处理，评测系统在确定集群系统对单位时间内接收到的第一数量的第一请求的第一处理时长时，确定方式可以是多种多样的。比如，第一请求中携带有发送时间戳，集群系统中存在接收时间戳和返回响应时间戳，则第一处理时长为集群系统中返回响应时间戳与接收时间戳的差值；再如，评测系统中设置有第一请求的发送时间戳T

步骤103，评测系统根据每一所述第一处理时长，测量所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限。

可以理解地，评测系统创建的请求发送给集群系统之后，会被集群系统中的相应节点处理，当集群系统中不断有第一请求到达时，集群系统中节点的CPU资源也会不断地被耗尽，当CPU利用率达到100％时，单位时间内能够处理的请求的个数便不会增长，集群系统的性能会在此时保持平衡，也即，集群系统到达单位时间内能够处理的第一请求的数量上限。可见，承载集群系统的平台的CPU处理效率会对集群系统的性能产生影响。

在本申请中，通过逐步增加单位时间内发送给集群系统的具有固定数据长度的第一请求的第一数量的方式，确定集群系统对每单位时间内接收的第一数量的第一请求的第一处理时长；根据每一次测量得到的第一处理时长，测量集群系统在单位时间内能够处理的具有固定数据长度的第一请求的数量上限。如此，能够评测出对于具有不同数据长度的第一请求，集群系统在单位时间内分别能够处理的数量上限。

在一些实施例中，如图2所示，所述方法还可以包括以下步骤201至步骤203，从而测量出集群系统在单位时间内能够处理第二数量的第二请求时第二请求的数据长度上限：

步骤201，评测系统逐步增加单位时间内发送给集群系统的第二请求的数据长度；其中，每次单位时间内发送给集群系统的第二请求的数量为固定的第二数量。

在本申请中，第二请求的数据长度，是指第二请求中携带的数据的长度。

在本申请中，所述第二数量为所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限，所述第二请求的初始数据长度与所述固定数据长度的差值满足第一阈值，所述第二请求与所述第一请求的类型相同。如此，能够减少对集群系统在单位时间内能够处理的具有固定第二数据的第二请求的数据长度上限的评测次数，提高评测效率，降低评测功耗。

这是因为：在评测出集群系统在单位时间内能够处理的具有固定数据长度的第一请求的数量上限之后，例如，当测量出集群系统对固定数据长度为46字节的第一请求的处理数量上限为1400个时，此时要继续测量集群系统在单位时间内能够处理第二数量的第二请求时第二请求的数据长度上限，则可以将第二数量设定为固定数据长度为46字节的第一请求的数量上限1400，并将第二请求的初始数据长度设定为与46字节的差值满足第一阈值的长度(如第一阈值范围为[-10，10]字节)。这样，实质上相当于从一个接近于数据长度上限的初始值开始测量，而不需要从相距数据长度上限较远的值(如30字节或60字节)开始测量，从而能够减少对集群系统在单位时间内能够处理的具有固定第二数据的第二请求的数据长度上限的评测次数，提高评测效率，降低评测功耗。

可以理解地，设定第二请求的初始数据长度与所述固定数据长度的差值满足第一阈值，是因为：集群系统能够处理的请求的数量上限和数据长度上限，与承载该集群系统的平台的CPU处理能力有关，但在每次评测时，CPU的处理能力一般不会前后保持完全一致，有可能存在上一次测量出固定数据长度为46字节的第一请求的最大处理数量为1400个，而在下一次测量时，对于固定数据长度为46字节的第一请求的最大处理数量为1500个。因此，可以将第二请求的初始数据长度设定为固定数据长度的差值满足第一阈值的值，并逐步增加第二请求的数据长度，从而能够快速测量出集群系统能够处理的第二请求的数据长度上限。

需要说明的是，第二请求与第一请求的类型相同，是指集群系统在接收到这两种请求之后，能够对这两种请求做同样的处理。举例来说，如果第一请求为set请求，则第二请求也为set请求；如果第一请求为get请求，则第二请求也为get请求；如果第一请求为其他类型的请求，则第二请求也为相同的其他类型的请求。

在本申请中，评测系统在发送具有固定数量的第二请求时，是按照特定的第二步长，逐步增加单位时间内发送给集群系统的第二请求的数据长度的，可见，评测系统在每次测试时，发送给集群系统的第二请求的数据长度并不固定。

举例来说，在第一次测试中，评测系统发送固定数量为1000的第二请求给集群系统，先发送数据长度为46字节的第二请求给集群系统，确定集群系统在单位时间内处理的第二请求的个数；再发送数据长度为48字节的第二请求给集群系统，再次确定集群系统在单位时间内处理的第二请求的个数；以2字节为第二步长，逐次增加发送给集群系统的第二请求的数据长度，直至发现某次发送的第二请求的数据长度增长，而集群系统在单位时间内处理的第二请求的个数减少时(比如，上一次发送的第二请求的数据长度为48字节，集群系统能够在单位时间内处理完1000个请求；而当次发送的第二请求的数据长度增长为50字节，但集群系统在单位时间内处理的第二请求数量减少为900个)，则能够确定集群系统在当前第二请求的数量为1000个时，能够处理的第二请求的最大数据长度为48字节。

在第二次测试中，评测系统发送固定数量为800的第二请求给集群系统，先发送数据长度为50字节的第二请求给集群系统，确定集群系统在单位时间内处理的第二请求的个数；再发送数据长度为52字节的第二请求给集群系统，再次确定集群系统在单位时间内处理的第二请求的个数；以2字节为第二步长，逐次增加发送给集群系统的第二请求的数据长度，直至发现某次发送的第二请求的数据长度增长，而集群系统在单位时间内处理的第二请求的个数减少时(比如，上一次发送的第二请求的数据长度为60字节，集群系统能够在单位时间内处理完800个请求；而当次发送的第二请求的数据长度增长为62，但集群系统在单位时间内处理的第二请求数量减少为700个)，则能够确定集群系统在当前第二请求的数量为800个时，能够处理的第二请求的最大数据长度为60字节。

在本申请中，评测系统在对集群系统单位时间内能够处理的固定数量的第二请求的数据长度上限进行评测时，其他影响集群系统处理能力的参数是保存不变的，比如，网络传输带宽、请求类型或请求中携带的键值范围等。在一些实施例中，第二请求的类型为set请求。

步骤202，评测系统确定集群系统对每单位时间内接收的第二数量的第二请求的第二处理时长。

在本申请中，评测系统确定集群系统对每单位时间内接收的所述第二数量的第二请求的第二处理时长的方式与步骤102中的方式一致，在此不再赘述。

步骤203，评测系统根据每一第二处理时长，测量集群系统在单位时间内能够处理第二数量的第二请求时第二请求的数据长度上限。

可以理解地，评测系统发送第二请求给集群系统，第二请求的数据长度会影响集群系统的处理性能，这是因为：集群系统在收到第二请求后，会将请求中的数据写到内存中，因此，第二请求中数据长度越大，则对第二请求的处理时间就越长，相应地，单位时间内处理请求的数量也就越少。

在本申请中，通过逐步增加单位时间内发送给集群系统的具有固定数量的第二请求的数据长度的方式，确定集群系统对每单位时间内接收的第二数量的第二请求的第二处理时长；根据每一次测量得到的第二处理时长，测量集群系统在单位时间内能够处理的具有固定数量的第二请求的数据长度上限。如此，能够评测出对于不同数量的第二请求，集群系统在单位时间内分别能够处理的数据长度上限。

在一些实施例中，如图3所示，所述方法还可以包括以下步骤301至步骤303，从而确定出集群系统在单位时间内接收的第三请求的数据长度与其能够接收的第三请求的数量之间的关系：

步骤301，评测系统逐步增加单位时间内发送给集群系统的第三请求的数据长度；其中，每次单位时间内发送给集群系统的第三请求的数量为固定的第三数量。

在本申请中，所述第三数量为所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限，所述第三请求的初始数据长度大于所述固定数据长度，所述第三请求与所述第一请求的类型相同。如此，能够在承载集群系统的平台的CPU处理能力达到上限的情况下，减少确定集群系统在单位时间内能够第三请求的数据长度和第三请求的数量之间的关系的评测次数，提高评测效率，降低评测功耗。

这是因为：在评测出集群系统在单位时间内能够处理的具有固定数据长度的第一请求的数量上限之后，例如，当测量出集群系统对固定数据长度为46字节的第一请求的处理数量上限为1400个时，此时要继续测量集群系统在单位时间内能够接收到的第三请求的第四数量时，则可以将第三数量设定为固定数据长度为46字节的第一请求的数量上限1400，并将第三请求的初始数据长度设定为大于固定数据长度的值(如48字节)，那么在这种情况下，承载集群系统的平台的CPU处理能力基本已经达到上限，此时再测量集群系统在单位时间内能够接收到的第四数量时，就能够较为快速地达到接收第三请求的数量上限，从而在确定出数据长度与请求数量的关系的同时，减少评测次数，降低评测功耗。

在本申请中，评测系统在发送具有固定数量的第三请求时，是按照特定的第三步长，逐步增加单位时间内发送给集群系统的第三请求的数据长度的，可知，评测系统在每次测试时，发送给集群系统的第三请求的数据长度并不固定。

举例来说，在测试中，评测请求发送第三数量为1000的第三请求给集群系统，先发送数据长度为48字节的第三请求给集群系统，确定集群系统在单位时间内能够接收的第三请求的个数M1(即第四数量)；再发送数据长度为50字节的第三请求给集群系统，再次确定集群系统在单位时间内能够接收的第三请求的个数M2；以2字节为第三步长，逐次增加发送给集群系统的第三请求的数据长度，依次确定集群系统在单位时间内能够接收的第三请求的个数M(M≤1000)。

在本申请中，评测系统在确定集群系统单位时间内能够接收的第三请求的第四数量时，其他影响集群系统处理能力的参数是保存不变的，比如，网络传输带宽、请求类型和请求中携带的键值范围等。在一些实施例中，第三请求的类型可以为set请求。

当然，在一些实施例中，第三请求的类型也可以与第一请求的类型不同，只需知道第三请求能够被集群系统接收即可。

步骤302，评测系统确定集群系统在每单位时间内接收的第三请求的第四数量；其中，第四数量小于或等于第三数量。

在本申请中，评测系统向集群系统发送请求时的网络传输带宽是固定不变的，而网络传输带宽(单位：MBps)＝请求的数据长度*单位时间内传输请求的个数。可见，第三请求的数据长度与评测系统在单位时间内能够传输的第三请求的个数呈反比关系，相应地，第三请求的数据长度与集群系统在单位时间内能够接收的第三请求的个数也呈反比关系。

步骤303，评测系统根据每一第四数量，确定第三请求的数据长度与所述集群系统在单位时间内能够接收的所述第三请求的数量之间的关系。

在本申请中，通过逐步增加单位时间内发送给集群系统的具有第三数量的第三请求的数据长度的方式，确定集群系统在单位时间内能够接收的第三请求的第四数量，从而能够测量出集群系统在单位时间内接收的第三请求的数据长度与其能够接收的第三请求的数量之间的关系，进而确定出网络传输带宽对集群系统接收第三请求的数量的影响。

在一些实施例中，如图4所示，所述方法还可以包括以下步骤401至步骤410，从而确定出集群系统对不同的请求的处理能力：

步骤401，评测系统获取集群系统中存储的键值的范围。

在本申请中，集群系统中存储有多个不同的键值对，每一个键值对都有键值和与键值所关联的数据，每一个键值对中的键值都不相同，集群系统中存储的键值是具有一定范围的。

步骤402，评测系统将第五数量的第四请求发送给集群系统；其中，第四请求携带有第一数据和与第一数据关联的所述范围内的键值，第四请求用于请求集群系统根据所述范围内的键值查找对应存储的第二数据，以及在查找到第二数据时用第一数据替换第二数据；所述第四请求与所述第一请求的类型相同。

在本申请中，所述第五数量为所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限。如此，能够在集群系统的存储内存达到上限的情况下，快速评测出集群系统对不同类型请求的处理能力，减少评测次数，降低评测功耗。这是因为：在评测出集群系统在单位时间内能够处理的具有固定数据长度的第一请求的数量上限之后，例如，当测量出集群系统对固定数据长度为46字节的第一请求的处理数量上限为1400个时，此时要继续测量集群系统对第四请求和第五请求的处理时长时，则可以将第五数量设定为固定数据长度为46字节的第一请求的数量上限1400，那么在这种情况下，集群系统的存储内存基本已经达到上限，如此，能够有效避免其他影响因素对测量的影响。这样，后续在分别测量集群系统对第四请求、第五请求、第六请求和第七请求的处理时长时，针对每一种请求均仅需测量一次，即可准确得出集群系统对占据相同内存的不同类型请求的处理时长。

在本申请中，评测系统发送给集群系统的请求的第五数量是固定不变的，每次测试时改变的是发送的请求类型。

比如，在步骤402中，评测系统发送第五数量(如1000个)的第四请求给集群系统，每一个第四请求中均携带有第一数据和与第一数据关联的键值，且每一个第四请求的键值都在集群系统存储的键值范围内，这样，集群系统在接收到评测系统发送的第四请求之后，在对第四请求进行响应时，会根据第四请求中携带的键值，在存储空间中查找对应相同的键值，并在查找到相同的键值之后，直接将自身存储的键值所对应的第二数据替换为第四请求中携带的第一数据。可见，集群系统对第四请求的处理分为三步，即先查找键值，再获取第二数据，并用第一数据替换第二数据。在一些实施例中，第四请求可以为set请求。

步骤403，评测系统确定集群系统对接收的第五数量的第四请求的第三处理时长。

在本申请中，评测系统确定集群系统对接收的第五数量的第四请求的第三处理时长的方式，与步骤102中确定第一处理时长的方式相同，在此不再赘述。

步骤404，评测系统将所述第五数量的第五请求发送给集群系统；其中，所述第五请求携带有所述范围内的键值，所述第五请求用于请求所述集群系统返回根据所述键值读取的对应存储的第二数据；所述第五请求与所述第一请求的类型不同。

需要说明的是，第五请求与第一请求的类型不同，是指集群系统在接收到这两种请求之后，对这两种请求做不同的处理。举例来说，如果第一请求为set请求，则第二请求可以为get请求，即集群系统根据第一请求存储数据，而根据第五请求读取数据；如果第一请求为get请求，则第二请求可以为set请求，即集群系统根据第一请求读取数据，而根据第五请求存储数据。

在本申请中，评测系统发送第五数量(如1000个)的第五请求给集群系统，每一个第五请求中携带的键值均在集群系统存储的键值范围内，这样，根据第五请求中携带的键值，是能够从集群系统中查找到相同键值的。集群系统在接收到测评系统发送的第五请求之后，会响应第五请求，即根据第五请求中携带的键值查找到相同的键值，并读取该键值对应存储的第二数据。可见，集群系统对第五请求的处理分为两步，即先查找键值，再获取第二数据。

在一些实施例中，第五请求可以为get请求。

步骤405，评测系统确定集群系统对接收的第五数量的第五请求的第四处理时长。

在本申请中，评测系统确定集群系统对接收的第五数量的第五请求的第四处理时长的方式，与步骤102中确定第一处理时长的方式相同，在此不再赘述。

在根据步骤403和步骤405确定出第三处理时长和第四处理时长后，可以根据这两个处理时长，确定出集群系统对第四请求和第五请求的处理性能，由上述步骤402和步骤404中的分析可知，集群系统对第五请求的处理性能要明显高于对第四请求的处理性能。

步骤406，评测系统将第五数量的第六请求发送给集群系统；其中，第六请求携带有第三数据和与第三数据关联的所述范围外的键值，第六请求用于请求集群系统查找是否存储所述范围外的键值，以及如果未存储将所述范围外的键值和关联的第三数据进行关联存储。

在本申请中，评测系统发送第五数量(如1000个)的第六请求给集群系统，每一个第六请求中均携带有第三数据和与第三数据关联的键值，且每一个键值都在集群系统存储的键值范围外，这样，集群系统在接收到评测系统发送的第六请求之后，在对第六请求进行响应时，在存储空间中是查找不到与第六请求中携带的键值相同的键值的，此时，集群系统会重新申请新的内存空间，以用来存储第六请求中的键值和关联的第三数据。可以理解地，重新申请新的内存空间，耗时会较长。在一些实施例中，第六请求可以为set请求。

步骤407，评测系统确定集群系统对接收的第五数量的第六请求的第五处理时长。

在本申请中，评测系统确定集群系统对接收的第五数量的第六请求的第五处理时长的方式，与步骤102中确定第一处理时长的方式相同，在此不再赘述。

在根据步骤403和步骤407确定出第三处理时长和第五处理时长后，可以根据这两个处理时长，确定出集群系统对第四请求和第六请求的处理性能，由上述步骤402和步骤406中的分析可知，集群系统对第四请求的处理性能要高于对第六请求的处理性能。

步骤408，评测系统将第五数量的第七请求发送给集群系统；其中，第七请求携带有所述范围外的键值，第七请求用于请求集群系统读取所述范围外的键值所关联的数据，以及返回读取失败的响应结果。

在本申请中，评测系统发送第五数量(如1000个)的第七请求给集群系统，每一个第七请求中携带的键值均在集群系统存储的键值范围外，这样，根据第七请求中携带的键值，是不能够从集群系统中查找到相同键值的，也不能够在集群系统中读取到键值关联的第二数据。因此，集群系统在接收到第七请求之后，会返回读取失败的响应结果。可见，集群系统对第七请求的处理过程为，查找不到相同键值后直接返回读取失败的结果，耗时较短。

在一些实施例中，第七请求可以为get请求。需要说明的是，所述第五数量为所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限，所述第六请求与所述第一请求的类型相同；所述第七请求与所述第一请求的类型不同。如此，能够在集群系统的存储内存达到上限的情况下，快速评测出集群系统对不同类型请求的处理能力，减少评测次数，降低评测功耗。

步骤409，评测系统确定集群系统对接收的第五数量的第七请求的第六处理时长。

在本申请中，评测系统确定集群系统对接收的第五数量的第七请求的第六处理时长的方式，与步骤102中确定第一处理时长的方式相同，在此不再赘述。

在根据步骤405和步骤409确定出第四处理时长和第六处理时长后，可以根据这两个处理时长，确定出集群系统对第五请求和第七请求的处理性能，由上述步骤404和步骤408中的分析可知，集群系统对第七请求的处理性能要高于对第五请求的处理性能。

需要说明的是，在本申请中，对评测系统向集群系统发送第四请求、第五请求、第六请求和第七请求的顺序并不做限定，可以选择任意顺序发送，也即，集群系统处理第四请求、第五请求、第六请求和第七请求的顺序可以为任意顺序。

在本申请中，对发送给集群系统的请求中携带的键值是否相同并不做限定，不同的请求中携带的键值可以相同，也可以不同。

步骤410，评测系统根据第三处理时长和第四处理时长，比较集群系统对第四请求和第五请求的处理性能；以及，根据第三处理时长和第五处理时长，比较集群系统对第四请求和第六请求的处理性能；以及，根据第四处理时长和第六处理时长，比较集群系统对第五请求和第七请求的处理性能。

在本申请中，评测系统在分别确定出集群系统对第四请求的第三处理时长、对第五请求的第四处理时长、对第六请求的第五处理时长以及对第七请求的第六处理时长之后，可以根据各个处理时长，确定出集群系统对不同的请求的处理能力。

在一些实施例中，如图5所示，所述方法还可以包括以下步骤501至步骤503，能够确定出第八请求中携带的键值的缺失率，从而确定更新后的集群系统对接收到的第八请求的处理能力：

步骤501，评测系统发送N个第八请求给更新后的集群系统；其中，每一第八请求携带的键值不同，更新后的集群系统为增加新的节点后的集群系统，N大于1。

在本申请中，第八请求与第五请求和/或第七请求的类型相同。

在本申请中，测评系统是在其他条件(如网络传输带宽或承载集群系统的服务器的CPU处理能力等)保持不变的情况下，发送N个携带不同键值的请求给增加新的节点的集群系统，以确定更新后的集群系统对接收到的第八请求的处理能力。

在一些实施例中，评测系统还可以先测量未增加新的节点的集群系统对接收到的请求的处理能力，将其与更新后的集群系统对接收到的第八请求的处理能力进行对比，以进一步确定增加新的节点对集群系统处理请求的性能的影响。

在一些实施例中，还可以在不增加集群系统中节点的情况下，评测系统通过不断增长发送给集群系统的第八请求的键值范围，来测量接收的请求的键值范围对集群系统处理请求的性能的影响。

步骤502，更新后的集群系统接收第八请求并响应，向评测系统返回基于每一键值对对应的第八请求的响应信息；

步骤503，评测系统根据更新后的集群系统返回的基于每一键值对对应的第八请求的响应信息，确定更新后的集群系统的键值缺失率。

在本申请中，步骤501中确定更新后的集群系统对接收到的第八请求的处理能力，即为确定获取评测系统发送给更新后的集群系统的第八请求的键值缺失率，第八请求的键值缺失率越小，则说明更新后的集群系统对接收到的第八请求的处理能力越强。

键值缺失，是指评测系统发送N个携带不同键值的第八请求给集群系统，N为大于1的整数。例如，评测系统向集群系统发送500个携带不同键值的第八请求，集群系统在接收到这500个第八请求之后，根据每一个第八请求中携带的键值，确定相同的键值是否存在，如果集群系统中不存在相同的键值，则说明该第八请求中的键值缺失；如果集群系统中存在相同的键值，则对应读取与该键值所关联的数据，也即该第八请求中的键值命中。键值缺失率，即为确定出的键值在集群系统中缺失的第八请求的数量与500的比值。

在本申请中，对集群系统返回的响应信息的类型并不做限定。例如，响应信息表征的是集群系统中存在与第八请求中携带的键值相同的键值，还是不存在与第八请求中携带的键值相同的键值；再如，返回的响应信息中携带的是与第八请求中携带的键值相同的键值所关联的数据，因此响应信息中可能有数据，也可能没有数据。在本申请中，第八请求为get请求。

在一些实施例中，通过如下步骤5031至步骤5032执行步骤503：

步骤5031，评测系统根据第八请求的响应信息，确定更新后的集群系统是否读取到携带的键值所关联的数据，从而得到确定结果。

集群系统在接收到第八请求之后，会根据第八请求中携带的键值，在存储空间中查找是否存在与第八请求中携带的键值相同的键值，如果查找到，则在响应信息中携带读取的与键值相关联的数据，返回给第八请求；如果没有查找到，则读取数据失败，返回键值缺失的响应结果给第八请求。

步骤5032，评测系统根据每一第八请求对应的确定结果，确定更新后的集群系统的键值缺失率。

在本申请中，通过发送携带不同键值的N个第八请求给增加新的节点的集群系统，根据集群系统返回的对每一个第八请求的响应信息，能够确定出第八请求中携带的键值的缺失率，从而确定更新后的集群系统对接收到的第八请求的处理能力。

下面将说明本申请在一个实际的应用场景中的示例性应用。

为了解决Redis Cluster(即集群系统)的性能评测问题，本申请提出了一种能够支持Redis Cluster性能评测方案。该方案实现了三种评测模式，这三种评测模式可以评测出中央处理器(central processing unit，CPU)利用率、网络传输带宽、内存读写速度以及内存容量对Redis Cluster性能的影响。

本申请将面向Redis Cluster的性能评测模块(即评测系统)按功能独立性划分为如下(1)至(5)共5个不同的子模块。

(1)数据包处理子模块：性能评测模块和Redis Cluster之间发送或接收的数据包有一定的格式，因此性能评测模块需要有相应的子模块来实现与Redis Cluster的格式化通信。数据包处理子模块是将性能评测模块中数据包处理功能抽象出来的一个子模块，主要负责对发送数据包的格式化和接收数据包的解析。

(2)节点管理子模块：Redis Cluster是分布式的内存KVS，Redis Cluster使用哈希节点(hash slot)解决请求分发的问题，性能评测模块需实现对Redis Cluster分布式的支持。在评测模块中需要设置节点管理子模块，该子模块主要负责与Redis Cluster集群中节点建立网络连接、维护集群中节点的网络信息以及节点上hash slot分布信息。且RedisCluster在运行过程会随时增添或移除节点，节点管理子模块需要感知集群节点的变换，并及时更新每个节点的扩展插槽(slot)分布。

(3)请求管理子模块：与单机Redis和Memcached不同，面向Redis Cluster的性能评测模块需要与集群中的所有节点建立套接字(socket)连接，发送请求前需要根据请求中的key计算请求的目的节点。在性能评测模块中需要有请求管理子模块，该子模块需要实现与Redis Cluster一致的请求分发算法，可以根据请求中的键值(key)计算相应的slot，同时该子模块需要与节点管理子模块进行交互计算请求的目的节点。此外，请求管理子模块还需要实现请求创建和请求应答处理等功能。

(4)事件管理子模块：为了实现在高性能收发数据包的同时，减少系统资源的浪费，memtier_benchmark使用基于异步事件的事件通知库(libevent)来支持底层的网络通信。性能评测模块需要与memtier_benchmark网络模块进行交互，因此在性能评测模块中需要实现与libevent相关的事件管理子模块，该模块主要完成异步事件的创建、注销、处理等功能。

(5)客户端管理子模块：从客户端/服务器(Client/Server，C/S)架构的角度来看，评测模块相当于Redis Cluster的客户端。在实际测试中为了提高测试的并发度，需要性能评测模块实现多个客户端的共同评测。客户端子模块主要负责客户端的创建、管理等工作，同时客户端子模块也是评测模块的主模块，负责初始化其他子模块、启动性能评测。

基于以上分析，如图6所示，给出了评测模块的功能结构示意图。下面给出上述5个子模块的功能设计及实现方法。

(1)数据包处理子模块功能设计及实现：

(a)功能设计：

数据包处理子模块不发送也不接收数据包，仅在发送请求前使用该模块将请求格式化然后存储到相应的位置。在解析接收数据包时，使用不同的返回值表示不同的解析结果。设计“数据包进程(packet_process)”类来实现数据包处理子模块的功能，其字段和接口设计如表1和表2所示。数据包处理子模块在进行数据包处理时仅使用内部接口,与外部子模块无交互过程，其中format_request()和parse_response()函数为对外的数据包格式化接口和数据包解析接口。外部模块通过format_request()接口来完成请求的格式化。接口的参数信息如下所示，其中“type”参数表示请求的类型，请求类型参数不能为空；“key”、“key_len”“value”、“value_len”这四个参数分别表示一个请求中key的值、key的长度、value的值、value的长度。format_request()函数首先使用request_type()内部函数判断请求的类型，然后再根据类型分别调用format_SET_request()、format_GET_request()、format_SLOT_request()这三个内部函数完成请求的格式化。最终将格式化后的数据包存储到m_write_buf指针指定的存储位置。

表1

表2

(b)功能实现：

使用“packet_process”类实现数据包处理子模块的功能，该类的成员变量和接口函数定义如表1和表2所示。表1为数据包处理子模块字段设计表，表2为数据包处理子模块接口设计表。为了提高各子模块内聚度，降低子模块间的耦合，“packet_process”类中的成员变量均为私有变量，在接口函数中仅有format_request()和parse_response()两个函数为公共(public)类型，其他接口函数均为私有(private)类型函数。私有函数运行时所需的参数为“packet_process”类的私有成员变量。这些变量在format_request()函数中完成赋值。

(2)节点管理子模块功能设计及实现：

(a)功能设计：

节点管理子模块的主要功能可概括为维护节点信息、节点和slot映射关系这两张信息表以及实现与远程节点建立网络连接功能。设计“node管理(node_manage)”类来实现节点管理子模块的功能，其字段和接口设计如表3和表4所示。

表3

表4

表3为节点管理子模块字段设计表，表4为节点管理子模块接口设计表。

在字段设计表3中，使用node_info结构体来保存单个节点的信息。在node_info结构体中，socket_ptr字段是与远程节点建立socket连接的文件描述符；port字段为远程节点上Redis Cluster进程监听的端口号；node_id字段是节点的编号(从0开始)；ip_addr字段保存远程节点的IP地址。node_info结构体在add_node_item()接口函数中初始化，每次初始化成功后将结构体的首地址添加到node_info_tab指针数组中保存并增加节点信息表中数据条目node_tab_cnt变量的值。使用del_node_item()接口函数可以从node_info_tab表中删除一条信息，每次从表中间删除数据时，后面的数据会向前移动。节点管理子模块的初始化过程如图7所示。首先使用setup_node_info()接口根据命令行中给出的节点的信息列表初始化node_info_tab表，setup_node_info()接口根据Redis Cluster集群中节点的个数，使用add_node_item()接口将节点的IP地址和端口号保存到node_info_tab表中。然后使用connect_with_cluster()接口依次与集群中的所有节点建立socket连接。在使用connect_with_node()接口与集群中单个节点成功建立socket连接后，通过update_node_item()接口将socket连接的文件描述符和节点的编号保存node_info_tab表的对应位置。在与集群中所有节点都建立完socket连接后，使用get_node_slots_mapping()接口获取节点对应的slot分布信息。在收到Redis Cluster返回的slot信息数据包后，通过parse_node_slots_mapping()接口解析每个节点上slot分布。最后由setup_slot_map_info()接口根据节点的个数调用add_slot_item()接口将节点和slot分布信息依次添加到slot_info_tab表中。

在性能评测的过程中Redis Cluster集群的数量和节点slot分布可能会随时发生改变。节点管理子模块负责感知集群节点的变化，并负责相关的处理工作。集群节点变化处理如图8所示。数据包处理子模块的parse_response()接口解析到“返回(MOVED)”异常后通知客户端子模块，由客户端子模块调用节点管理子模块的is_node_change()接口判断集群中是否有新节点的加入或旧节点的移除。如果集群中有新节点的加入，节点管理子模块首先与新节点建立网络连接，更新完节点信息表后，通知事件管理子模块为新连接建立并设置异步事件。在异步事件创建、设置完成后，节点管理子模块使用get_node_slot_mapping()接口重新获取每个节点的slot分布信息。如果是旧节点的移除，首先关闭与远程节点的socket连接，然后重新获取节点的slot分布。并使用parse_node_slots_mapping()接口重新解析slot分布信息，在更新完slot_info_tab表后，节点管理子模块返回消息给客户端子模块，表示整个节点感知工作完成，客户端子模块可继续进行性能评测。

(b)功能实现：

使用“node_manage”类来实现节点管理子模块的功能，该类的成员变量和接口函数定义如表3和表4所示。在性能评测的过程中节点管理子模块会与其他子模块频繁交互，因此在“node_manage”类中只有connect_with_node()函数为内部私有函数，其他接口函数均为公共函数。connect_with_node()函数实现了与一个运行rediscluster进程的远程节点建立网络连接的功能。“node_manage”类提供了connect_with_cluster()外部公共函数来实现与整个rediscluster集群建立网络连接。该函数会根据Redis Cluster集群中节点的数量依次调用connect_with_node()函数与集群中所有节点建立网络连接。在此过程中只要有一个节点的网络连接失败，connect_with_cluster()函数便返回执行失败。

(3)请求管理子模块功能设计及实现：

(a)功能设计：

请求管理子模块需要设计两个不同的数据结构，用于描述产生的请求以及接收到的应答数据包。此外还需要实现与请求和应答相关的创建、处理等接口。设计“请求管理(request_mange)”类来实现请求管理子模块的功能，其字段和接口设计如表5和表6所示。表5为请求管理子模块字段设计表，表5为请求管理子模块接口设计表。

表5

表6

使用request结构体描述一个评测请求的信息，使用response结构体用于描述一个请求的应答信息。Redis Cluster使用循环冗余校验码(Cyclic Redundancy Check，CRC)校验的方式来计算key对应的slot号。

图9反映了在评测模块内部请求创建的过程。客户端子模块通知请求管理子模块创建请求，请求管理子模块首先根据命令行参数中给出请求的信息，产生请求的描述信息，并将请求信息描述对象压入队列中；然后，获取key和value(仅SET请求需要value)，在获取到请求中的key后，请求管理子模块计算key对应的slot编号；然后使用节点管理模块获取存储该slot的节点的编号；获取节点编号后，确定请求的发送缓冲区，再以发送缓存区指针为参数完成请求的格式化，最后触发对应节点的写事件完成请求的发送。

图10为请求应答处理的过程。在测试机器收到RedisCluster返回的请求应答数据包时，libevent的读事件将被触发，事件管理子模块的事件处理回调函数将会被调用，回调函数完成请求应答的处理。请求管理子模块首先生成一个应答信息描述对象，并从请求队列中弹出上一个请求的描述信息，再计算上一个请求处理延时。在请求管理子模块处理应答的过程中，会使用数据包处理模块完成应答数据包的解析，请求管理子模块会根据解析结果更新应答的相关信息，至此一个请求应答的处理已经完成。应答处理完成后请求管理子模块会通知memtier_benchmark的性能统计模块更新性能信息，最后再根据上一个请求的应答信息(如上一个请求是否命中或产生错误)来创建新的请求。

(b)功能实现：

使用“request_manage”类来实现请求管理子模块的功能，该类的成员变量和接口函数定义如表5和表6所示。请求管理子模块在功能上主要负责创建不同类型的请求以及处理请求应答。在“request_manage”类中仅有create_request()、create_SLOT_request()和handle_response()这三个函数为外部公共函数，在其他类中可以调用create_request()和create_SLOT_request()来创建性能评测请求和扩展插槽(SLOT)请求，调用handle_response()函数来处理请求的应答。“request_manage”类中的其他函数均为内部私有函数，这些私有函数在创建请求或处理应答的过程中会被调用，其他的类不能使用这些函数。

(4)事件管理子模块功能设计及实现：

(a)功能设计：

从软件整体结构上来看，事件管理子模块可以视作评测模块和底层libevent库的交互层。事件管理子模块在设计上需要向评测模块中的其他子模块提供接口，方便其他子模块完成数据的发送和接收。在自身功能实现上，事件管理子模块需要使用libevent库的接口函数。设计“事件管理(event_manage)”类来实现事件管理子模块的功能，其字段和接口设计如表7和表8所示。表7为事件管理子模块字段设计表，表8为事件管理子模块接口设计表。

表7

表8

图11为创建异步事件的过程，客户端子模块首先通知节点管理子模块与远程redis节点建立socket连接。在所有连接都建立完成后，客户端子模块通过create_event()接口通知事件管理子模块创建读写异步事件。事件管理子模块从节点管理子模块的节点信息表node_info_tab中获取每条连接的socket文件描述符，然后使用create_node_event()接口函数为每条socket连接流创建异步事件。在为所有的socket连接都创建异步事件后，客户端子模块通过事件管理子模块来初始化数据缓冲区，缓冲区用于保存发送和接收的数据。set_event()接口主要使用libevent库的event_assign()接口函数和event_add()来完成事件激活工作。

(b)功能实现：

使用“event_manage”类来实现事件管理子模块的功能，该类的成员变量和接口函数定义如表7和表8所示。“event_manage”类是对底层网络libevent库函数的二次封装，目的是更方便、高效的维护每条socket流的异步事件。在“event_manage”类中所有的函数均为外部公共函数。其他类可以使用该类的接口函数来完成异步事件的创建、激活以及数据的发送。

(5)客户端子模块功能设计及实现：

(a)功能设计：

评测模块可以模拟多个客户端对Redis Cluster进行性能评测。在设计上使用一个的“客户端(class client)”类来描述一个客户端，多客户端表示使用该类生成多个对象。为了方便管理多个客户端对象，设计“客户端群组(class client_group)”类来创建和销毁多客户端。此外，客户端子模块在运行过程中需要使用其他子模块来完成性能的评测，客户端子模块在设计上需要创建其他子模块的实例，进而使用其他子模块的接口函数完成相应的功能。客户端子模块中client_group类的字段和接口设计如表9和表10所示，client类的字段和接口设计如表11和表12所示。

表9

表10

表11

表12

图12表示客户端子模块的初始化过程，首先在C++语言的main()函数中创建client_group对象，client_group类的构造函数client_group()在初始化libenvet基事件管理器后，使用create_client()接口函数来创建指定数量的client对象。每当一个client对象创建完成后，需要使用client对象的setup_client()接口来完成client对象的初始化，随着其他子模块对象被创建，其他子模块的初始化也会依次进行。最后在所有对象都初始化完成后，用run_clients()接口来启动评测。

(b)功能实现：

客户端子模块使用“客户端组(client_group)”和“客户端(client)”这两个类来实现，“client_group”类用来描述所有客户端的信息，其字段和接口信息如表9和表10所示，“client”类用来描述每个client的信息，字段和接口信息如表11和表12所示。

下面给出各个子模块类关系的描述。本申请中使用UML的类图来描述评测模块内部结构，评测模块各个类以及类之间的关系如图13所示。“client_group”类是用来描述所有客户端组的信息，“client”类描述一个客户端的信息。“client_group”类和“client”类是组合关系，表示一个客户端组对象是由多个客户端对象组成的。“client”类是性能评测模块的主功能类，但不进行具体的性能评测工作，“client”类依赖“request_manage”、“node_manage”和“event_manage”这三个类来完成性能评测。“request_manage”类定义了用于描述发送请求数据包和接收应答数据包的数据结构，并实现了请求创建、请求发送以及应答处理等相关函数。函数运行结束后可以返回空，也可以返回一个指定类型的值，在函数的执行结果不唯一时，可指定返回值来表示不同的执行结果。在评测模块实际运行中，某些接口函数需要根据其调用的其他函数的返回值来判断函数的执行情况。接口函数的返回值设计如表13所示。

表13

下面给出本申请的三种测试方法。

(1)高并发模式测试(X86)：

在X86平台上主要评测CPU处理能力和网络带宽对Redis Cluster性能的影响，评测时所需要的参数如下表14所示。实际测试中可以通过设置“-t，-c”参数来调节评测模块的并发度，通过设置“-d”参数来调节网络数据包的大小。为了评测出在X86平台上CPU处理Redis Cluster实例的效率和网络带宽对Redis Cluster性能的影响，规定每个RedisCluster节点使用最大内存为1600MB。Redis Cluster实例在收到数据后将存储在自己的内存空间中，当1600MB的最大内存使用完时，Redis Cluster会通过最近最少使用(LeastRecently Used，LRU)算法选择合适的数据换出，换出后的空间用来存储新接收的数据。使用LRU算法选择数据换出时会占用一定的CPU处理时间，在本次测试中当Redis Cluster的最大内存被写满时即终止测试，从而避免LRU算法对CPU处理时间的占用。

实现在Redis Cluster最大内存被写满时终止测试，测试过程可分为如下三个步骤：(1)设置好评测模块的并发度、数据包大小等参数，以较大的请求数量执行测试，保证Redis Cluster最大内存被写满并产生替换，记录Redis Cluster最大内存被写满时，集群中所有节点能存储key的数量。(2)保证其他参数不变，根据步骤一统计的结果，重新设置“key-maximum”和“-n”参数，进行性能评测，并统计性能测试结果。(3)以并发度(即第一数量)和数据包大小(即第二请求和第三请求的数据长度)为两个控制变量，每次测试仅改变其中一个变量，每次改变都需要执行步骤一和步骤二，在步骤二中统计测试结果。

表14

理论分析：高并发模式主要发送SET请求(即第一请求)评测Redis Cluster的性能，在评测请求大小不变的情况下，提高性能评测模块的并发度，其实质就是增加了评测模块单位时间内创建请求的个数。这些被创建的请求经过网络到达Redis Cluster端，然后被相应的节点处理。因此在某一范围内不断提高性能评测模块的并发度会增加单位时间内请求的处理个数，亦即Redis Cluster的性能会得到提高。然而，在某一特定的硬件环境中，CPU的处理能力和网络的传输能力都是有限的。当Redis Cluster端不断有新的请求到达时，集群中节点的CPU资源也会不断地被耗尽，当CPU利用率达到100％时，单位时间内被处理的请求的个数便不会增长，Redis Cluster性能会在此时保持平衡。相同地，单位时间内需要传输的总带宽达到网络带宽上限时，Redis Cluster的性能也会停止增长。因此，从理论上来看，无论评测请求的类型和大小是否一样，在某一范围内增加评测模块的并发度会提高Redis Cluster的性能，超过这一范围之后Redis Cluster将达到性能瓶颈，性能将停止增长并围绕某一性能值上下波动。

此外，发送SET请求评测Redis Cluster性能时，SET请求的大小会影响RedisCluster的处理性能。Redis Cluster在收到SET请求后会将请求中的数据写到内存中，请求中数据长度越大，请求处理时间越长，单位时间内请求处理的个数也就越少。从理论上分析，对于不同大小的SET请求，性能值应该是不一样的。

最后，由公式"网络传输带宽(单位：MBps)＝数据包大小*单位时间内传输数据包的个数”可以看出网络传输带宽受数据包大小的影响。因此，对于不同大小的请求，在RedisCluster达到性能瓶颈时的影响因素也是不一样的。对于大的数据包请求而言，更容易受到网络带宽的限制。在相同的并发度情况下，Redis Clsuter单位时间内收到小数据包的个数会多于大数据包，因此，对于较小的数据包请求，CPU的利用率可能会更容易影响其性能。

预期的测试结论：面向Redis Cluster的评测模块可通过调节并发度和数据包大小来评测平台的CPU处理效率和网络带宽对Redis Cluster性能的影响。

(2)请求自定义模式测试(arm)

使用请求自定义模式测试时所需的参数如表14所示。在测试过程中需要改变的参数为“--ratio，-n，--key-maximum，--key-minimun”，使用“--ratio”参数可以控制评测模块发送SET请求和GET请求的比例；“-n”参数是发送请求的数量；调节“--key-maximum，--key-minimun”参数可以构造出MISS和HIT这两种请求处理结果。同时调节以上这三个参数便可以构造出GET HIT(GET命中)、GET MISS(GET缺失)、SET HIT(SET命中)、SET MISS(SET缺失)这四种不同的请求。具体测试步骤为：(1)启动Redis Cluster并规定每个节点使用的最大内存为800MB，设置“--ratio”参数为“--ratio＝1:0”(仅仅发生SET请求)，调节“--key-maximum，--key-minimun，-n”参数使所有的SET请求(即第四请求)都命中并恰好填满800MB内存，测试完成后统计测试结果。(2)在步骤1基础上将“--ratio”参数设置为“--ration＝0:1”，其他参数保持不变，发送GET请求(即第五请求)，测试结束后统计测试结果。(3)在步骤2基础上，改变“--key-maximum，--key-minimun”参数继续测试，使所有的GET请求都缺失(即第七请求)，且关闭评测模块在GET请求缺失后自动发送SET请求的功能，在测试结束后统计测试结果。(4)在步骤3的基础上将“--ratio”参数设置为“--ration＝1:0”发送SET请求，使所有SET请求都缺失(即第六请求)，测试结束后统计测试结果。

理论分析：Redis Cluster在底层使用Hashmap来存储数据，当Redis Cluster接收到一个SET请求时，首先通过请求中的key计算相同的key是否已经存储在Hashmap中，如果已经存储，则表示该SET请求命中，此时直接将请求中的value写到Hashmap中对应的位置，以前旧的value数据将被覆盖。若请求中的key没有存储在Hashmap中，则表示该请求缺失，需要重新申请空间来存储新的key-value对。从处理时间上来看SET MISS请求比SET HIT请求多出申请空间这部分时间，因此SET MISS请求处理时间要比SET HIT请求时间长。向Redis Cluster发送GET请求，当请求中key已经存储在Hashmap中时，Redis Cluster读出key对应的value，将value作为应答数据包返回给对方，如果Hashmap中没有存储相同的key，则直接返回GET MISS结果，从理论上来看，GET HIT请求需要从内存中读出value值，因此相对于GET MISS请求，GET HIT请求的处理时间更长。

预期测试结果：1、GET请求的性能要明显高于SET请求的处理性能；2、在请求的命中和缺失方面，GET MISS请求性能要优于GET HIT请求性能，而SET MISS请求的性能低于SET HIT请求的性能；3、内存的读写速度对SET MISS请求的性能影响较为明显，原因是SETMISS请求除了写内存外还需要分配新的内存空间。

(3)key-range递增模式测试

Redis Cluster作为万维网(World Wide Web，Web)服务器和磁盘数据库中间的内存缓存系统，其直接目的是缓存Web服务器需要访问的数据，对于Web服务器来说，更加关注GET请求处理的性能。Web服务器发送GET请求从Redis Cluster中读取数据，如果产生GETMISS，需要从磁盘数据库中读取数据，在获取数据后发送SET请求重新将数据写到RedisCluster中，以提高下次访问的命中率。当某个内存使用满的Redis节点收到这种新的写请求，会产生驱逐(eviction)操作(从内存中选择旧数据进行替换，以保存新的数据)，eviction操作会增加Redis Cluster的处理延时，影响其处理性能。

Key-range递增模式可有效评测内存容量对Redis Cluster性能的影响。具体步骤为：(1)发送SET请求，填充满每个节点的内存，并确保不产生eviction操作，记录key的范围。(2)发送GET请求，不断增长key的范围，且在key的范围达到某一值时停止增长，加入新节点后(即更新后的集群系统)继续发送GET请求(即第八请求)，统计步骤2整个过程中的性能。

理论分析：在其他条件保持不变的情况下，Redis Cluster集群的内存容量越大，能存储的key就越多，这样Web服务器发送GET请求的缺失率就越低，亦即eviction操作就越少。Key-range递增模式是在测试过程中不断增加请求中key的范围，当key的范围增长到集群所能存储的最大值时，继续增加key的范围就会产生eviction操作，促使GET请求缺失率的增长，导致性能的下降。在性能下降过程中添加新的节点，扩大Redis Cluster集群整体内存容量，由于内存扩容后能缓存更多的key，GET请求的缺失率会下降，Redis Cluster性能会有所上升。

预期测试结论：调节key-range能评测内存容量对Redis Cluster性能的影响。

在本申请中，提出了一种支持Redis Cluster性能评测的方法，该方法实现了三种评测模式，这三种评测模式可以评测出CPU利用率、网络带宽、内存读写速度以及内存容量对Redis Cluster性能的影响。

基于前述的实施例，本申请提供一种性能评测装置，该装置包括所包括的各模块、以及各模块所包括的各单元，可以通过处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图14为本申请性能评测装置的结构示意图，如图14所示，所述装置140包括调节模块141和确定模块142，其中：调节模块141，用于逐步增加单位时间内发送给集群系统的第一请求的数量；其中，所述第一请求具有固定数据长度；确定模块142，用于确定所述集群系统对每单位时间内接收的第一数量的第一请求的第一处理时长；确定模块142，还用于根据每一所述第一处理时长，测量所述集群系统在单位时间内能够处理的具有所述固定数据长度的第一请求的数量上限。

在一些实施例中，调节模块141，还用于逐步增加单位时间内发送给所述集群系统的第二请求的数据长度；其中，每次单位时间内发送给所述集群系统的第二请求的数量为固定的第二数量；确定模块142，还用于确定所述集群系统对每单位时间内接收的所述第二数量的第二请求的第二处理时长；根据每一所述第二处理时长，测量所述集群系统在单位时间内能够处理所述第二数量的第二请求时所述第二请求的数据长度上限。

在一些实施例中，调节模块141，还用于逐步增加单位时间内发送给所述集群系统的第三请求的数据长度；其中，每次单位时间内发送给所述集群系统的第三请求的数量为固定的第三数量；确定模块142，还用于确定所述集群系统在每单位时间内接收的第三请求的第四数量；其中，所述第四数量小于或等于所述第三数量；根据每一所述第四数量，确定第三请求的数据长度与所述集群系统在单位时间内能够接收的所述第三请求的数量之间的关系。

在一些实施例中，装置140包括获取模块、发送模块和比较模块，所述获取模块，用于获取所述集群系统中存储的键值的范围；所述发送模块，用于将第五数量的第四请求发送给所述集群系统；确定模块142，用于确定所述集群系统对接收的所述第五数量的第四请求的第三处理时长；所述发送模块，还用于将所述第五数量的第五请求发送给所述集群系统；确定模块142，还用于确定所述集群系统对接收的所述第五数量的第五请求的第四处理时长；所述比较模块，用于根据所述第三处理时长和所述第四处理时长，比较所述集群系统对所述第四请求和所述第五请求的处理性能。

在一些实施例中，所述发送模块，用于将所述第五数量的第六请求发送给所述集群系统；确定模块142，用于确定所述集群系统对接收的所述第五数量的第六请求的第五处理时长；所述比较模块，用于根据所述第三处理时长和所述第五处理时长，比较所述集群系统对所述第四请求和所述第六请求的处理性能。

在一些实施例中，所述发送模块，用于将所述第五数量的第七请求发送给所述集群系统；确定模块142，用于确定所述集群系统对接收的所述第五数量的第七请求的第六处理时长；所述比较模块，用于根据所述第四处理时长和所述第六处理时长，比较所述集群系统对所述第五请求和所述第七请求的处理性能。

在一些实施例中，所述发送模块，用于发送N个第八请求给更新后的集群系统；确定模块142，用于根据所述更新后的集群系统返回的基于每一所述键值对对应的所述第八请求的响应信息，确定所述更新后的集群系统的键值缺失率。

在一些实施例中，确定模块142，用于根据所述第八请求的响应信息，确定所述更新后的集群系统是否读取到携带的键值所关联的数据，从而得到确定结果；根据每一所述第八请求对应的确定结果，确定所述更新后的集群系统的键值缺失率。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请中图14所示的性能评测装置对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。也可以采用软件和硬件结合的形式实现。

需要说明的是，本申请中，如果以软件功能模块的形式实现上述的方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请不限制于任何特定的硬件和软件结合。

本申请提供一种电子设备，图15为本申请的电子设备的硬件实体示意图，如图15所示，所述电子设备150包括存储器151和处理器152，所述存储器151存储有可在处理器152上运行的计算机程序，所述处理器152执行所述程序时实现上述实施例中提供的方法中的步骤。

需要说明的是，存储器151配置为存储由处理器152可执行的指令和应用，还可以缓存在处理器152以及电子设备150中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(RandomAccess Memory，RAM)实现。

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

本申请提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述方法实施例提供的方法中的步骤。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质、存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”或“一些实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施过程构成任何限定。上述本申请序号仅仅为了描述，不代表实施例的优劣。上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如对象A和/或对象B，可以表示：单独存在对象A，同时存在对象A和对象B，单独存在对象B这三种情况。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者设备中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个模块或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或模块的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的模块可以是、或也可以不是物理上分开的，作为模块显示的部件可以是、或也可以不是物理模块；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部模块来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能模块可以全部集成在一个处理单元中，也可以是各模块分别单独作为一个单元，也可以两个或两个以上模块集成在一个单元中；上述集成的模块既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。