CN115941991B - 在大并发下收取消息稳定性验证方法及系统 - Google Patents

Abstract

本申请提供一种在大并发下收取消息稳定性验证方法及系统。所述方法包括：通过双向通信协议收取消息，记录收取到的消息数量；对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳；根据所述第一时间戳和所述第二时间戳获取时间差；根据多个消息的时间差获取平均时间差；根据所述平均时间差判断是否符合收取消息侧收取消息的稳定性的第一指标。

Description

在大并发下收取消息稳定性验证方法及系统

技术领域

本申请涉及互联网直播测试系统领域，具体而言，涉及一种在大并发下收取消息稳定性验证方法及系统。

背景技术

现有的直播双向通信协议WebSocket长链接消息在压测过程中，大部分场景及方案是以压测消息推送以及消息分发为目的，对于客户端长链接消息在大并发下收取的稳定性，缺乏有效的验证手段。

因此，需要提出一种在大并发下收取消息稳定性验证方法及系统，对用户收到消息情况有可靠的数据了解，以及保证最终交付效果。

在所述背景技术部分公开的上述信息仅用于加强对本申请的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

为了解决上述问题，本申请提出一种在大并发下收取消息稳定性验证方法及系统。

根据本申请的第一方面，提出一种在大并发下收取消息稳定性验证方法，包括：

通过双向通信协议收取消息，记录收取到的消息数量；

对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳；

根据所述第一时间戳和所述第二时间戳获取时间差；

根据多个消息的时间差获取平均时间差；

根据所述平均时间差判断是否符合收取消息侧收取消息的稳定性的第一指标。

根据一些实施例，还包括：

在收取到消息的情况下，判断双向通信协议状态；

在所述双向通信协议状态为断开的情况下，重新创建新的双向通信协议，记录重新连接次数。

根据一些实施例，所述对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳，包括：

在第一时间内，通过所述双向通信协议未收到消息的情况下，停止收取消息；

在停止收取消息的情况下，对收取到的消息进行解析。

根据一些实施例，包括：

所述第一时间戳为接收到消息的时间，所述第二时间戳为对应消息发送的时间。

根据一些实施例，还包括：

根据所述收取到的消息数量和系统记录的发送的消息数量，确定收到的比率，根据所述比率判断是否符合收取消息侧收取消息的稳定性的第二指标。

根据一些实施例，包括：根据所述重新连接次数判断是否符合收取消息侧收取消息的稳定性的第三指标。

根据本申请的第二方面，提出一种在大并发下收取消息稳定性验证系统，包括：

接收单元，用于通过双向通信协议收取消息，记录收取到的消息数量；

解析单元，用于对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳；

获取时间差单元，用于根据所述第一时间戳和所述第二时间戳获取时间差，并根据多个消息的时间差获取平均时间差；

稳定性判断单元，用于根据所述平均时间差判断是否符合收取消息侧收取消息的稳定性的第一指标。

根据一些实施例，还包括：

重连判断单元，用于在收取到消息的情况下，判断双向通信协议状态；还用于在所述双向通信协议状态为断开的情况下，重新创建新的双向通信协议，记录重新连接次数。

根据一些实施例，所述稳定性判断单元，还用于根据所述收取到的消息数量和系统记录的发送的消息数量，确定收到的比率，根据所述比率判断是否符合收取消息侧收取消息的稳定性的第二指标。

根据一些实施例，所述稳定性判断单元，还用于根据所述重新连接次数判断是否符合收取消息侧收取消息的稳定性的第三指标。

本申请提出一种在大并发下收取消息稳定性验证方法及系统，通过模拟用户对双向通信协议WebSocket进行大量收消息的行为，模拟用户在压测过程中批量收取消息的行为，测试收取消息是否稳定，补足消息压测的链路测试方法的缺失；同时通过根据压测收取到的消息数量和系统记录的发送的消息数量，确定收到的比率；消息收取平均延迟，双向通信协议WebSocket重连次数等数据分析，进行最终数据分析和得出稳定性结论来补足测试方案的缺失，为以收取消息稳定性为目标的项目交付和技术优化，提供客观的数据和方向目标。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

通过参照附图详细描述其示例实施例，本申请的上述和其它目标、特征及优点将变得更加显而易见。下面描述的附图仅仅是本申请的一些实施例，而不是对本申请的限制。

图1示出一示例性实施例的在大并发下收取消息稳定性验证方法流程图；

图2示出一示例性实施例的在大并发下收取消息稳定性验证系统示意图。

具体实施方式

现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本申请将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有这些特定细节中的一个或更多，或者可以采用其它的方式、组元、材料、装置等。在这些情况下，将不详细示出或描述公知结构、方法、装置、实现、材料或者操作。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

本领域技术人员可以理解，附图只是示例实施例的示意图，附图中的模块或流程并不一定是实施本申请所必须的，因此不能用于限制本申请的保护范围。

大并发是指互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。而现有的直播双向通信协议WebSocket长链接消息在压测过程中，大部分场景及方案是以压测消息推送以及消息分发为目的，对于客户端长链接消息在大并发下收取的稳定性，缺乏有效的验证手段。

图1示出一示例性实施例的在大并发下收取消息稳定性验证方法流程图。

S101，通过双向通信协议收取消息，记录收取到的消息数量。

根据示例实施例，系统创建无限循环，通过双向通信协议WebSocket的收取功能，不停的循环收取消息，并记录收取到的消息数量。

根据一些实施例，WebSocket是一种在单个传输层通信协议TCP连接上进行全双工通信的协议。

根据示例实施例，系统通过JMeter实现对消息接口进行压力请求，并且JMeter发送的消息时会加上当时的时间戳，此时双向通信协议WebSocket可以收到JMeter发送的消息。

其中，JMeter是服务器组织基于Java开发的压力测试工具，用于对软件做压力测试的语言。

S102，判断是否收到消息。

根据示例实施例，若收到消息，则转到S103；若在第一时间内通过双向通信协议未收到消息，则停止收取消息，并转到S104。

S103，在收取到消息的情况下，判断双向通信协议状态。

根据示例实施例，在双向通信协议状态为断开的情况下，转到S1031；在双向通信协议未断开的情况下，转到S101。

S1031，重新创建新的双向通信协议，记录重新连接次数。

根据示例实施例，在双向通信协议状态为断开的情况下，重新创建新的双向通信协议，记录重新连接次数，并转到S101。

S104，对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳。

根据示例实施例，对收取到的消息进行解析，其中，第一时间戳为接收到消息的时间，第二时间戳为对应消息发送的时间。

S105，根据第一时间戳和第二时间戳获取时间差。

根据示例实施例，系统根据第一时间戳和消息中的第二时间戳进行差值计算，算出该消息发送时和接收时的时间差并记录。

S106，根据多个消息的时间差获取平均时间差。

根据示例实施例，对多个消息的时间差平均求值，得出平均时间差。

S107，根据平均时间差判断是否符合收取消息侧收取消息的稳定性的第一指标。

根据示例实施例，设定收取消息侧收取消息稳定性的第一指标，在系统收取消息的平均时间差小于等于第一指标的情况下，确定符合收取消息侧收取消息的稳定性的第一指标。

S108，根据收取到的消息数量和系统记录的发送的消息数量，确定收到的比率，根据比率判断是否符合收取消息侧收取消息的稳定性的第二指标。

根据示例实施例，设定收取消息侧收取消息稳定性的第二指标，在收取到的消息数量和系统记录的发送的消息数量的比率大于等于第二指标的情况下，确定符合收取消息侧收取消息的稳定性的第二指标。

S109，根据重新连接次数判断是否符合收取消息侧收取消息的稳定性的第三指标。

根据示例实施例，设定收取消息侧收取消息稳定性的第三指标，在重新连接次数小于等于第三指标的情况下，确定符合收取消息侧收取消息的稳定性的第三指标。

在压测收取到的消息数量和系统记录的发送的消息数量，确定收到的比率；消息收取平均延迟，双向通信协议WebSocket重连次数分别符合收取消息侧收取消息的稳定性的第一指标、第二指标和第三指标的情况下，确定双向通信协议的稳定性。

本申请提出一种在大并发下收取消息稳定性验证方法，通过模拟用户对双向通信协议WebSocket进行大量收消息的行为，模拟用户在压测过程中批量收取消息的行为，测试收取消息是否稳定，补足消息压测的链路测试方法的缺失；同时通过根据压测收取到的消息数量和系统记录的发送的消息数量，确定收到的比率；消息收取平均延迟，双向通信协议WebSocket重连次数等数据分析，进行最终数据分析和得出稳定性结论来补足测试方案的缺失，为以收取消息稳定性为目标的项目交付和技术优化，提供客观的数据和方向目标。

图2示出一示例性实施例的在大并发下收取消息稳定性验证系统示意图。

如图2所示，在大并发下收取消息稳定性验证系统包括接收单元201，解析单元202，获取时间差单元203和稳定性判断单元204。

根据示例实施例，接收单元201，用于通过双向通信协议收取消息，记录收取到的消息数量。

根据示例实施例，系统创建无限循环，通过双向通信协议WebSocket的收取功能，接收单元201不停的循环收取消息，并记录收取到的消息数量。

根据示例实施例，接收单元201在第一时间内通过双向通信协议未收到消息，则停止收取消息，并发送信号给解析单元202，使其对接收到的消息进行解析。

根据一些实施例，WebSocket是一种在单个传输层通信协议TCP连接上进行全双工通信的协议。

根据示例实施例，系统通过JMeter实现对消息接口进行压力请求，并且JMeter发送的消息时会加上当时的时间戳，此时双向通信协议WebSocket可以收到JMeter发送的消息。

其中，JMeter是服务器组织基于Java开发的压力测试工具，用于对软件做压力测试的语言。

根据示例实施例，解析单元202，用于对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳，其中，第一时间戳为接收到消息的时间，第二时间戳为对应消息发送的时间。

根据示例实施例，获取时间差单元203，用于根据第一时间戳和第二时间戳获取时间差，并根据多个消息的时间差平均求值，得出平均时间差，并把平均时间差发送给稳定性判断单元204。

根据示例实施例，稳定性判断单元204，用于根据平均时间差判断是否符合收取消息侧收取消息的稳定性的第一指标。

根据示例实施例，稳定性判断单元204设定收取消息侧收取消息稳定性的第一指标，在系统收取消息的平均时间差小于等于第一指标的情况下，稳定性判断单元204确定符合收取消息侧收取消息的稳定性的第一指标。

根据一些实施例，稳定性判断单元204，还用于设定收取消息侧收取消息稳定性的第二指标，在收取到的消息数量和系统记录的发送的消息数量的比率大于等于第二指标的情况下，确定符合收取消息侧收取消息的稳定性的第二指标。

根据一些实施例，在大并发下收取消息稳定性验证系统还包括重连判断单元205，用于在收取到消息的情况下，判断双向通信协议状态；还用于在双向通信协议状态为断开的情况下，重新创建新的双向通信协议，记录重新连接次数，并把重连次数发送给稳定性判断单元204。

根据一些实施例，稳定性判断单元204，还用于设定收取消息侧收取消息稳定性的第三指标，在重新连接次数小于等于第三指标的情况下，确定符合收取消息侧收取消息的稳定性的第三指标。

根据示例实施例，在压测收取到的消息数量和系统记录的发送的消息数量，确定收到的比率；消息收取平均延迟，双向通信协议WebSocket重连次数分别符合收取消息侧收取消息的稳定性的第一指标、第二指标和第三指标的情况下，稳定性判断单元204确定双向通信协议的稳定性。

本申请提出一种在大并发下收取消息稳定性验证系统，通过模拟用户对双向通信协议WebSocket进行大量收消息的行为，模拟用户在压测过程中批量收取消息的行为，测试收取消息是否稳定，补足消息压测的链路测试方法的缺失；同时通过根据压测收取到的消息数量和系统记录的发送的消息数量，确定收到的比率；消息收取平均延迟，双向通信协议WebSocket重连次数等数据分析，进行最终数据分析和得出稳定性结论来补足测试方案的缺失，为以收取消息稳定性为目标的项目交付和技术优化，提供客观的数据和方向目标。

应清楚地理解，本申请描述了如何形成和使用特定示例，但本申请不限于这些示例的任何细节。相反，基于本申请公开的内容的教导，这些原理能够应用于许多其它实施例。

此外，需要注意的是，上述附图仅是根据本申请示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

以上具体地示出和描述了本申请的示例性实施例。应可理解的是，本申请不限于这里描述的详细结构、设置方式或实现方法；相反，本申请意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (4)

1.一种在大并发下收取消息稳定性验证方法，其特征在于，包括：

收取消息侧通过双向通信协议收取消息，记录收取到的消息数量；

在收取到消息的情况下，判断双向通信协议状态；

在所述双向通信协议状态为断开的情况下，重新创建新的双向通信协议，记录重新连接次数；

对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳；

根据所述第一时间戳和所述第二时间戳获取时间差；

根据多个消息的时间差获取平均时间差；

根据所述平均时间差判断是否符合所述收取消息侧收取消息的稳定性的第一指标；

根据在压测中所述收取消息侧收取到的消息数量和系统记录的发送的消息数量，确定收到的比率，根据所述比率判断是否符合所述收取消息侧收取消息的稳定性的第二指标；

根据所述重新连接次数判断是否符合所述收取消息侧收取消息的稳定性的第三指标。

2.如权利要求1所述的收取消息稳定性验证方法，其特征在于，所述对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳，包括：

在第一时间内，通过所述双向通信协议未收到消息的情况下，停止收取消息；

在停止收取消息的情况下，对收取到的消息进行解析。

3.如权利要求1所述的收取消息稳定性验证方法，其特征在于，包括：

所述第一时间戳为接收到消息的时间，所述第二时间戳为对应消息发送的时间。

4.一种在大并发下收取消息稳定性验证系统，其特征在于，包括：

接收单元，用于通过双向通信协议收取消息，记录收取到的消息数量；

解析单元，用于对收取到的消息进行解析，获取消息的第一时间戳和第二时间戳；

获取时间差单元，用于根据所述第一时间戳和所述第二时间戳获取时间差，并根据多个消息的时间差获取平均时间差；

稳定性判断单元，用于根据所述平均时间差判断是否符合收取消息侧收取消息的稳定性的第一指标；还用于根据在压测中所述收取到的消息数量和系统记录的发送的消息数量，确定收到的比率，根据所述比率判断是否符合收取消息侧收取消息的稳定性的第二指标；还用于根据所述重新连接次数判断是否符合收取消息侧收取消息的稳定性的第三指标；

重连判断单元，用于在收取到消息的情况下，判断双向通信协议状态；还用于在所述双向通信协议状态为断开的情况下，重新创建新的双向通信协议，记录重新连接次数。