A layered architecture system and implementation method for stress testing of MQTT protocol

Abstract

The application relates to the technical field of data processing, in particular to a layered architecture system for pressure testing of an MQTT protocol and an implementation method thereof. The layered architecture system comprises an interface layer, a business layer, a protocol layer and a network layer. The application adopts a pressure testing thread pool to execute a pressure testing task. Compared with JMeter which simulates the number of concurrent users through the number of threads, the application can effectively avoid the problem that the pressure testing result fluctuates too much due to the uncertainty of CPU scheduling of an operating system caused by a large number of threads, and can effectively reduce the performance overhead of the operating system. The layered architecture system design concept can be applicable to complex IM business scenarios, can support a configurable custom extension I / O framework, and can realize pressure testing requirements in multiple business scenarios and improve the scalability of the layered architecture system through pressure testing request parameter configuration and I / O framework switching configuration.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a layered architecture system and implementation method for stress testing the MQTT protocol. Background Technology

[0002] MQTT (Message Queuing Telemetry Transport), as a lightweight message transmission protocol based on a publish / subscribe model, has broad application prospects in the Internet of Things (IoT). High concurrency and high frequency interactions between the front-end and back-end are common in IoT applications; therefore, stress testing of such service interfaces is necessary for using the MQTT protocol in IoT applications.

[0003] In existing technical solutions, stress testing tools (such as JMeter) are typically used to stress test the MQTT protocol. JMeter employs a modular, layered architecture design, supporting multiple protocols and high-concurrency scenarios. However, using JMeter for stress testing of the MQTT protocol has the following drawbacks: Since JMeter does not provide a sampler supporting the MQTT protocol, a custom sampler supporting the MQTT protocol needs to be implemented and loaded into JMeter for application. During stress testing, a test plan must first be created, defining the number of threads in the thread group based on the number of concurrent requesting users, configuring a custom MQTT sampler, and configuring a listener to collect the stress test results. During this process, because JMeter simulates concurrent requests by defining thread groups, with each thread representing one user, a larger number of simulated users results in more threads being created, leading to higher memory consumption on the stress testing device. Furthermore, a larger number of threads consumes more machine performance. In addition, since thread scheduling is determined by the operating system and has significant uncertainty, some threads may experience starvation, causing large fluctuations in the stress test results, failing to meet the non-functional testing requirement of QPS fluctuations of less than 10%.

[0004] To address this, a layered architecture system and implementation method for stress testing the MQTT protocol are proposed. Summary of the Invention

[0005] Therefore, it is necessary to provide a layered architecture system and implementation method for stress testing the MQTT protocol to address the aforementioned technical issues.

[0006] According to a first aspect of the present invention, a layered architecture system for stress testing the MQTT protocol is provided, comprising: an interface layer for providing a call interface, receiving stress testing requests initiated by users and parsing stress testing request parameters, encapsulating them into stress testing request configuration objects, initializing functional components and a stress testing thread pool; a business layer for providing general business functions and corresponding general business interfaces required for stress testing requests, and starting the stress testing thread pool based on a distributed instance coordination mechanism; a protocol layer for providing MQTT stress testing sampling operations, encapsulating message data in the stress testing thread into message bodies conforming to the MQTT protocol format, encoding them through an I / O framework, submitting them to the stress testing thread pool for asynchronous message sending operations, sending them to the MQTT server, and receiving return messages sent by the MQTT server, decoding the receipt information through an I / O framework, encapsulating it into an MQTT message object, calling back to the corresponding sampler, and executing the corresponding processing logic; and a network layer for sending the encoded message bodies to the MQTT server according to the established network connection, and receiving return messages sent by the MQTT server.

[0007] Optionally, the interface layer includes: an interface definition module for defining call interfaces, wherein the call interfaces include one-on-one chat load testing interfaces, group chat load testing interfaces, and hybrid load testing interfaces; a load testing request processing module for receiving load testing requests initiated by users and load testing request parameters submitted via forms, parsing the load testing request parameters using the corresponding parser according to the file type to which the load testing request parameters belong, and assembling them into a load testing request configuration object; and an initialization module for initializing functional components and a load testing thread pool.

[0008] Optionally, the functional components include a load generator, a one-on-one chat test sampler, a received message sampler, and a group chat test sampler.

[0009] Optionally, the business layer includes: a business definition module, used to define the general business functions and corresponding general business interfaces required for load testing requests; and a thread pool startup module, used to start the load testing thread pool based on a distributed instance coordination mechanism.

[0010] Optionally, the thread pool startup module further includes: a thread coordination module, used to start a load testing thread for load testing coordination before starting the load testing thread pool, using Redis's INCR command to perform an atomic auto-increment operation on the shared key, recording the current number of load testing instances, and determining whether the current number of load testing instances has reached the number of instances configured in the load testing request parameters. If the current number of load testing instances has not reached the number of instances configured in the load testing request parameters, the load testing thread is blocked by spinning, causing the load testing thread to enter an event-driven waiting state until the current number of load testing instances reaches the number of instances configured in the load testing request parameters, triggering an event broadcast, waking up all load testing threads that have entered the waiting state, entering the load testing execution phase, and starting the load testing thread pool.

[0011] Optionally, the business layer further includes a network connection construction module, which is used to select an MQTT server from the MQTT service cluster through a polling algorithm after the load testing thread pool is started, establish a Socket connection between the load testing thread and the MQTT server, and store the established Socket connection in a local cache.

[0012] Optionally, the protocol layer includes: a sampling module, used to configure the test type of the object according to the load testing request; the load testing thread calls the corresponding sampler from the functional components; the sampler encapsulates the message data in the load testing thread into a message body conforming to the MQTT protocol format; and an I / O framework implementation module, used to provide a configurable I / O framework; the I / O framework encodes the encapsulated message body and submits it to the load testing thread pool for asynchronous message sending operations, sending it to the corresponding MQTT server; and receiving the return message sent by the MQTT server; the I / O framework decodes the receipt information according to the protocol and encapsulates it into an MQTT message object, which is then called back to the corresponding sampler; the sampler executes the corresponding processing logic according to the message type of the receipt information to obtain the load testing result.

[0013] Optionally, the I / O framework implementation module further includes: an I / O framework extension module for providing newly added extended I / O frameworks; and an I / O framework switching module for dynamically switching I / O frameworks and comparing stress test results to select the optimal I / O framework under different business scenarios.

[0014] Optionally, the protocol layer further includes: a thread management module, used to allow the corresponding load testing thread to enter an event-based waiting state after the load testing thread completes the message sending operation, waiting for a return message to wake it up or for a timeout, and updating the success or failure count through an atomic increment operation; and a performance statistics module, used to perform performance statistics on the load testing results.

[0015] According to a second aspect of the present invention, a method for implementing a layered architecture system for stress testing the MQTT protocol is provided, comprising: providing a calling interface through an interface layer to receive stress testing requests initiated by users and parse the stress testing request parameters, encapsulate them into a stress testing request configuration object, and initialize functional components and a stress testing thread pool; providing general business functions and corresponding general business interfaces required for stress testing requests through a business layer, and starting the stress testing thread pool based on a distributed instance coordination mechanism; providing MQTT stress testing sampling operations through a protocol layer, encapsulating message data in the stress testing thread into a message body conforming to the MQTT protocol format, encoding it through an I / O framework, and submitting it to the stress testing thread pool for asynchronous message sending operations, sending it to the MQTT server, and receiving return messages sent by the MQTT server, decoding the receipt information through an I / O framework, encapsulating it into an MQTT message object, calling back to the corresponding sampler, and executing the corresponding processing logic; and sending the encoded message body to the MQTT server according to the established network connection through a network layer, and receiving return messages sent by the MQTT server.

[0016] The beneficial effects of this application are as follows: The layered architecture system and implementation method for stress testing the MQTT protocol provided in this application have the following beneficial effects: Using a stress testing thread pool to execute stress testing tasks effectively avoids the problem of excessive fluctuations in stress testing results caused by the uncertainty of CPU scheduling in the operating system due to a large number of threads, compared to JMeter simulating concurrent users by the number of threads (i.e., one thread corresponding to one user), and effectively reduces the performance overhead of the operating system; the layered architecture system design is applicable to complex IM business scenarios, and supports configurable custom extended I / O frameworks. Through stress testing request parameter configuration and I / O framework switching configuration, it can not only meet the stress testing requirements under multiple business scenarios, but also improve the scalability of the layered architecture system; using Redis's INCR command to perform atomic auto-increment operations on shared keys enables distributed stress testing support for multiple stress testing instances, solving the problem of insufficient performance of JMeter simulating a large number of concurrent users accessing a single machine. Attached Figure Description

[0017] Figure 1 This is an exemplary system architecture diagram in which this application can be applied.

[0018] Figure 2 This is a schematic diagram of an embodiment of a layered architecture system for stress testing the MQTT protocol according to this application.

[0019] Figure 3 This is a flowchart of an embodiment of a layered architecture system for stress testing the MQTT protocol according to this application. Detailed Implementation

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0023] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0024] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0025] Terminal devices 101, 102, and 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc.

[0026] Server 105 can be a server that provides various services, such as a backend server that supports the pages displayed on terminal devices 101, 102, and 103.

[0027] It should be noted that the layered architecture system for stress testing the MQTT protocol provided in this application embodiment is generally set in a server / terminal device, and correspondingly, the implementation of the layered architecture system for stress testing the MQTT protocol is generally executed by the server / terminal device.

[0028] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0029] Continue to refer to Figure 2 This diagram illustrates a structural schematic of an embodiment of a layered architecture system 200 for stress testing the MQTT protocol according to this application. By employing a layered design concept, during the stress testing of the MQTT protocol, each layer only calls the layer below it. This not only facilitates the maintenance of the layered architecture system but also allows for stress testing of the MQTT protocol with only minor code modifications when changes are needed in the business scenario. Furthermore, it enhances the concurrency consistency and scalability of the layered architecture system. Specifically, the layered architecture system includes: an interface layer 201, a business layer 202, a protocol layer 203, and a network layer 204.

[0030] According to an embodiment of this application, the interface layer 201 is used to provide a calling interface, receive load testing requests initiated by users, parse load testing request parameters, encapsulate them into a load testing request configuration object, and initialize functional components and a load testing thread pool.

[0031] According to an embodiment of this application, the interface layer 201 includes: an interface definition module, used to define calling interfaces, wherein the calling interfaces include a one-on-one chat load testing interface, a group chat load testing interface, and a hybrid load testing interface; a load testing request processing module, used to receive load testing requests initiated by users and load testing request parameters submitted based on forms, parse the load testing request parameters using a corresponding parser according to the file type to which the load testing request parameters belong, and assemble them into a load testing request configuration object; and an initialization module, used to initialize functional components and a load testing thread pool.

[0032] It should be noted that "one-on-one chat" refers to a chat method where one person chats with another, "group chat" refers to a chat method where multiple people (3 or more) participate, and "mixed" refers to a stress testing method where "one-on-one chat" and "group chat" are carried out simultaneously.

[0033] According to the embodiments of this application, taking the one-chat load testing scenario as an example, the user can call the layered architecture system provided by this application through the call interface and initiate a load testing request. The load testing request parameters are submitted to the layered architecture system in the form of a form. The load testing request parameters in the one-chat load testing scenario include, but are not limited to: (1) connectUrl: MQTT service connection URL, multiple service instances are separated by English commas, for example: 10.14.122.86:6789, 10.14.122.88:6789; (2) con nectTimeout: MQTT connection timeout; (3) message: message content; (4) messageSize: message size, unit b represents bytes, unit k represents kilobytes, unit m represents megabytes. This parameter is not empty. If it is empty, the message is invalid. Configure according to actual usage. It should not be too large. It should preferably not exceed 10k (about 5000 characters); (5) needLogin: whether login is required. true: required, false: not required. Only test point-to-point. (6) serviceId: Service ID of the application, obtained through management configuration; (7) appId: Application ID, obtained through management configuration; (8) secretKey: Message content encryption key; (9) sleepTime: Sleep time, the sending rate is adjusted by the sleep time, can be left blank; (10) testCount: Total number of tests; (11) coreSize: Core number of threads in the stress test thread pool; (12) maxSize: Maximum number of threads in the stress test thread pool; (13) rejectHandler: Thread pool reject test, value: abort / discard / discardOldest / callerRuns, default: abort; (14) poolName: Name of the stress test thread pool, can be left blank; (15) blockQueueSize: Size of the blocking queue of the sending thread pool; (16) waitResponse: Whether to wait for the sending receipt, true: yes, false: do not wait.Generally true; (17) waitTime: Timeout for waiting to receive and send acknowledgments, in ms; (18) dataFormat: Data format of user account file, value: cvs / json, generally cvs; (19) userFile: User data file for load testing; (20) workerSize: Effective when using netty for load testing, is the size of the netty load testing thread pool; (21) instanceCount: Number of instances of load testing client, multiple load testing clients coordinate the test; (22) testIdentifier: When there are multiple load testing clients, the unique identifier for this test, different for each test, can be the current timestamp.

[0034] According to an embodiment of this application, the interface layer 201 can be implemented as a test application, such as cmc-test-app, so that users can call the layered architecture system involved in this application through the test application. When the interface layer 201 receives the load testing request and load testing request parameters initiated by the user, it will call the corresponding parser according to the file type (such as CSV, JSON) of the load testing request parameters uploaded by the user, extract the load testing request parameters and assemble them into a unified load testing request configuration object, and then initialize the functional components and load testing thread pool.

[0035] According to an embodiment of this application, the functional components include: a LoadGenerator for loading user account and group configuration information; a SingleSampler for initiating single-chat load testing and counting the number of single-chat messages sent; a ReceiverSampler for receiving single-chat, group chat, and return messages; and a GroupSampler for initiating group chat load testing and counting the number of group chat messages sent.

[0036] According to an embodiment of this application, the business layer 202 is used to provide the general business functions and corresponding general business interfaces required for load testing requests, and to start the load testing thread pool based on a distributed instance coordination mechanism.

[0037] According to an embodiment of this application, the business layer 202 includes: a business definition module, used to define the general business functions and corresponding general business interfaces required for load testing requests; and a thread pool startup module, used to start the load testing thread pool based on a distributed instance coordination mechanism.

[0038] According to an embodiment of this application, the thread pool startup module further includes: a thread coordination module, used to start a load testing thread for load testing coordination before starting the load testing thread pool, use Redis's INCR command to perform an atomic auto-increment operation on the shared key, record the current number of load testing instances, and determine whether the current number of load testing instances has reached the number of instances configured in the load testing request parameters. If the current number of load testing instances has not reached the number of instances configured in the load testing request parameters, the load testing thread is blocked by spinning, causing the load testing thread to enter an event-driven waiting state until the current number of load testing instances reaches the number of instances configured in the load testing request parameters, triggering an event broadcast, waking up all load testing threads that have entered the waiting state, entering the load testing execution phase, and starting the load testing thread pool.

[0039] According to an embodiment of this application, the business layer 202 further includes: a network connection construction module, which is used to select an MQTT server from the MQTT service cluster through a polling algorithm after the load testing thread pool is started, establish a Socket connection between the load testing thread and the MQTT server, and store the established Socket connection in a local cache.

[0040] According to the embodiments of this application, in order to solve the problems of asynchronous startup of load testing instances and unreliable load testing results in the prior art, this application adopts a distributed instance coordination mechanism to improve the concurrency consistency of the layered architecture system and the reliability of load testing results. Specifically, during the load testing startup phase, each instance does not immediately execute the load testing task, but enters a spin-wait state, continuously polling the number of instances recorded in Redis. Only when the current number of load testing instances reaches the number of instances configured in the load testing request parameters, all instances start executing the load testing task almost simultaneously, ensuring the consistency of load testing concurrency time points and improving the accuracy and comparability of load testing results. A specific application scenario is as follows: This layered architecture system is deployed to test the MQTT message service capabilities of a large-scale IoT platform. The platform requires support for 100,000 concurrent device connections, with each device sending a status message every 5 seconds, and supporting point-to-point communication between devices. To verify the platform's performance under high concurrency scenarios, this layered architecture system is used for distributed load testing verification. The distributed instance coordination mechanism works as follows: If the configuration requires starting 10 load testing instances, and assuming 3 instances are already running, the current load testing thread returns 4 after executing INCR. Since the total number of instances configured by the user is 10, this load testing thread enters an event-driven waiting state to avoid CPU idle time. When the 10th instance executes INCR and returns 10, the system determines that the number of load testing instances has met the requirement, triggers an event broadcast, wakes up all waiting threads, and enters the load testing execution phase. This mechanism ensures the accuracy and consistency of the instance count in the distributed environment through Redis's atomic operations.

[0041] According to an embodiment of this application, after the load testing thread pool starts, each load testing thread selects an MQTT server (node) from the MQTT service cluster using a round-robin algorithm and establishes a Socket connection between the two. After a successful connection, the Socket connection is stored in a local cache for reuse in subsequent message sending. Based on the configured load testing request parameters, it is determined whether to perform authentication (such as username / password or token) and subscription operations (such as subscribing to a one-on-one chat topic) to ensure that the connection is in a communicable state.

[0042] According to an embodiment of this application, protocol layer 203 is used to provide sampling operations for MQTT load testing. It encapsulates message data in the load testing thread into a message body conforming to the MQTT protocol format, encodes it through an I / O framework, and submits it to the load testing thread pool to asynchronously execute message sending operations, sending it to the MQTT server, and receiving return messages sent by the MQTT server. It decodes the receipt information through the I / O framework, encapsulates it into an MQTT message object, and calls back to the corresponding sampler to execute the corresponding processing logic.

[0043] According to an embodiment of this application, the protocol layer 203 includes: a sampling module, used to encapsulate message data in the load testing thread into a message body conforming to the MQTT protocol format by calling the corresponding sampler from the functional components according to the test type of the load testing request configuration object; an I / O framework implementation module, used to provide a configurable I / O framework, encode the encapsulated message body through the I / O framework, submit it to the load testing thread pool for asynchronous message sending operation, send it to the corresponding MQTT server, and receive the return message sent by the MQTT server, decode the receipt information through the I / O framework, encapsulate it into an MQTT message object, and call back to the corresponding sampler, which executes the corresponding processing logic according to the message type of the receipt information to obtain the load testing result; a thread management module, used to enter an event-based waiting state after the load testing thread completes the message sending operation, wait for the return message to wake up or time out, and update the success or failure count through an atomic increment operation; and a performance statistics module, used to perform performance statistics on the load testing results.

[0044] According to an embodiment of this application, the I / O framework implementation module further includes: an I / O framework extension module for providing newly added extended I / O frameworks; and an I / O framework switching module for dynamically switching I / O frameworks and comparing stress test results to select the optimal I / O framework under different business scenarios.

[0045] According to an embodiment of this application, during the sampler startup phase, the load testing thread first calls the corresponding sampler (e.g., SingleSampler) from the functional components based on the test type (e.g., one-on-one chat) of the load testing request configuration object. Specifically, the correspondence between test types and samplers is as follows: for one-on-one chat, the sampler is SingleSampler; for group chat, the sampler is GroupSampler; and for mixed test types, both SingleSampler and GroupSampler are used. The sampler encapsulates the message data in the load testing thread into a message body conforming to the MQTT protocol format (e.g., authentication messages, subscription messages, Ping messages, PUBLISH messages, etc.). Then, the encapsulated message body is encoded using the I / O framework and submitted to the load testing thread pool for asynchronous message sending operations, ultimately sending the message to the corresponding MQTT server. Furthermore, the layered architecture system supports dynamic switching of the I / O framework to select the optimal I / O framework for different business scenarios, thereby improving the adaptability and flexibility of the layered architecture system.

[0046] According to embodiments of this application, the I / O frameworks involved in this application include, but are not limited to, the TIO framework and the Netty framework. Network communication is achieved through the TIO framework and the Netty framework. The TIO framework adopts the AIO asynchronous non-blocking I / O method, and the Netty framework adopts the NIO synchronous non-blocking I / O method, which has excellent performance. It is possible to quickly switch between the TIO framework and the Netty framework through simple configuration. In addition, it also supports configurable custom extended I / O frameworks. By simply using the interface of the I / O framework extension module, a new extended I / O framework can be added to improve the scalability of the layered architecture system.

[0047] According to an embodiment of this application, after receiving a return message from the MQTT server, the I / O framework decodes the protocol and encapsulates it into a unified MQTT message object, which is then passed to the corresponding sampler via a callback mechanism. The sampler executes corresponding processing logic based on the message type of the receipt information. For example, if it is a one-on-one or group chat message, the sampler's receive count is updated via an atomic increment operation; if it is a receipt message (such as PUBACK), the corresponding load testing thread is woken up via a thread communication mechanism (such as CountDownLatch or CompleteableFuture). If the load testing thread is woken up within a set timeout period, the success count is incremented; if the timeout occurs, the failure count is incremented, achieving accurate statistics on message response latency and success rate.

[0048] According to embodiments of this application, the statistical performance includes, but is not limited to, total number of messages sent (totalSent), number of successful acknowledgment messages (successAck), number of failed messages (failed), message sending latency (latencyHistogram), message receiving latency (receiveLatencyHistogram), average response time (Queries Per Second), and message sending failure rate.

[0049] According to an embodiment of this application, network layer 204 is used to send the encoded message body to the MQTT server according to the established network connection, and to receive the return message sent by the MQTT server.

[0050] According to embodiments of this disclosure, any plurality of modules of interface layer 201, service layer 202, protocol layer 203, and network layer 204 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of interface layer 201, service layer 202, protocol layer 203, and network layer 204 can be at least partially implemented as hardware circuitry, such as field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits (ASICs), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, and firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of interface layer 201, service layer 202, protocol layer 203, and network layer 204 can be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0051] An electronic device according to embodiments of this application includes a processor that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from a storage portion into random access memory (RAM). The processor may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor may also include onboard memory for caching purposes. The processor may include a single processing unit or multiple processing units for performing different actions of the method flow according to embodiments of this application.

[0052] The RAM stores various programs and data required for the operation of the electronic device. The processor, ROM, and RAM are interconnected via a bus. The processor executes various operations of the method flow according to embodiments of this application by executing programs in the ROM and / or RAM. It should be noted that the programs may also be stored in one or more memories other than ROM and RAM. The processor may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0053] According to embodiments of this application, the electronic device may further include an input / output (I / O) interface, which is also connected to a bus. The electronic device may also include one or more of the following components connected to the I / O interface: an input section including a keyboard, mouse, etc.; an output section including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section including a hard disk, etc.; and a communication section including a network interface card such as a LAN card, modem, etc. The communication section performs communication processing via a network such as the Internet. A drive is also connected to the I / O interface as needed. Removable media, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage section as needed.

[0054] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0055] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include one or more memories other than ROM and / or RAM described above.

[0056] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the item recommendation method provided in the embodiments of this application.

[0057] When the computer program is executed by a processor, it performs the functions defined in the system / apparatus of this application embodiments. According to embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0058] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices or magnetic storage devices. In another embodiment, the computer program may also be transmitted and distributed as signals over a network medium, and downloaded and installed via a communication component, and / or installed from a removable medium. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0059] In such an embodiment, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a processor, it performs the functions defined in the system of the embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0060] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0061] Further reference Figure 3 As a response to the above Figure 2The present application provides an embodiment of a layered architecture system for stress testing the MQTT protocol, which is described in the following embodiment. Figure 2 The system embodiment shown corresponds to this.

[0062] like Figure 3 As shown in this embodiment, a method for implementing a layered architecture system for stress testing the MQTT protocol is described. This method includes the following steps.

[0063] S1. Provide a call interface through the interface layer, receive load testing requests initiated by users, parse the load testing request parameters, encapsulate them into a load testing request configuration object, and initialize functional components and load testing thread pool.

[0064] S2. Provide the general business functions and corresponding general business interfaces required for load testing requests through the business layer, and start the load testing thread pool based on the distributed instance coordination mechanism.

[0065] S3. By providing sampling operations for MQTT load testing through the protocol layer, the message data in the load testing thread is encapsulated into a message body conforming to the MQTT protocol format, encoded through the I / O framework, and submitted to the load testing thread pool for asynchronous message sending operations to the MQTT server. It also receives return messages from the MQTT server, decodes the receipt information through the I / O framework, encapsulates it into an MQTT message object, and calls back to the corresponding sampler to execute the corresponding processing logic.

[0066] S4. Based on the established network connection, the network layer sends the encoded message body to the MQTT server and receives the return message from the MQTT server.

[0067] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0068] The above description, in conjunction with specific embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the inventive concept, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A layered architecture system for stress testing the MQTT protocol, characterized in that, include: The interface layer is used to provide calling interfaces, receive load testing requests initiated by users, parse the load testing request parameters, encapsulate them into load testing request configuration objects, and initialize functional components and load testing thread pools. The functional components include a load generator, a one-on-one chat test sampler, a received message sampler, and a group chat test sampler. The business layer provides the general business functions and corresponding general business interfaces required for load testing requests, as well as starts the load testing thread pool based on a distributed instance coordination mechanism. The distributed instance coordination mechanism is as follows: During the load test startup phase, each instance does not immediately execute the load test task, but enters a spin-wait state and continuously polls the number of instances recorded in Redis. When the current number of load test instances reaches the number of instances configured in the load test request parameters, all instances start executing the load test task simultaneously. The protocol layer is used to provide sampling operations for MQTT load testing. It encapsulates message data in the load testing thread into message bodies that conform to the MQTT protocol format, encodes them through the I / O framework, and submits them to the load testing thread pool for asynchronous message sending operations. The message is sent to the MQTT server, and the return messages sent by the MQTT server are received. The acknowledgment information is decoded through the I / O framework and encapsulated into MQTT message objects. The callback is then sent to the corresponding sampler to execute the corresponding processing logic. The protocol layer includes: The sampling module is used to configure the test type of the object according to the load testing request. The load testing thread calls the corresponding sampler from the functional components and encapsulates the message data in the load testing thread into a message body that conforms to the MQTT protocol format through the sampler. And the I / O framework implementation module, including: an I / O framework extension module, which provides new and extended I / O frameworks; and an I / O framework switching module, which dynamically switches I / O frameworks and compares stress test results to select the optimal I / O framework in different business scenarios. The network layer is used to send the encoded message body to the MQTT server and receive the return message sent by the MQTT server, based on the established network connection.

2. The layered architecture system for stress testing the MQTT protocol according to claim 1, characterized in that, The interface layer includes: The interface definition module is used to define the calling interface, which includes a one-on-one chat load testing interface, a group chat load testing interface, and a hybrid load testing interface. The load testing request processing module is used to receive load testing requests initiated by users and load testing request parameters submitted via forms. Based on the file type of the load testing request parameters, it uses the corresponding parser to parse the load testing request parameters and assembles them into a load testing request configuration object. The initialization module is used to initialize functional components and the load testing thread pool.

3. The layered architecture system for stress testing the MQTT protocol according to claim 1, characterized in that, The business layer includes: The business definition module is used to define the general business functions and corresponding general business interfaces required for load testing requests; The thread pool startup module is used to start the stress testing thread pool based on a distributed instance coordination mechanism.

4. A layered architecture system for stress testing the MQTT protocol according to claim 3, characterized in that, The thread pool startup module also includes: The thread coordination module is used to start a load testing thread for load testing coordination before starting the load testing thread pool. It uses Redis's INCR command to perform an atomic auto-increment operation on the shared key, records the current number of load testing instances, and determines whether the current number of load testing instances has reached the number of instances configured in the load testing request parameters. If the current number of load testing instances has not reached the number of instances configured in the load testing request parameters, it blocks the load testing threads in the load testing thread pool by spinning, causing the load testing threads to enter an event-driven waiting state until the current number of load testing instances reaches the number of instances configured in the load testing request parameters. At this point, an event broadcast is triggered, waking up all load testing threads that have entered the waiting state, entering the load testing execution phase, and starting the load testing thread pool.

5. A layered architecture system for stress testing the MQTT protocol according to claim 3, characterized in that, The business layer also includes: The network connection building module is used to select an MQTT server from the MQTT service cluster through a polling algorithm after the load testing thread pool starts, establish a Socket connection between the load testing thread and the MQTT server, and store the established Socket connection in the local cache.

6. A layered architecture system for stress testing the MQTT protocol according to claim 1, characterized in that, The I / O framework implementation module provides a configurable I / O framework. It encodes the encapsulated message body using the I / O framework and submits it to the load testing thread pool for asynchronous message sending operations. The message is sent to the corresponding MQTT server, and the module receives return messages from the MQTT server. The I / O framework decodes the receipt information using the protocol and encapsulates it into an MQTT message object, which is then called back to the corresponding sampler. The sampler executes the appropriate processing logic based on the message type of the receipt information to obtain the load testing results.

7. A layered architecture system for stress testing the MQTT protocol according to claim 1, characterized in that, The protocol layer also includes: The thread management module is used to make the corresponding load testing thread enter an event-based waiting state after the load testing thread finishes the message sending operation, waiting for the return message to wake it up or for a timeout, and updating the success or failure count through an atomic increment operation. The performance statistics module is used to perform performance statistics on the stress test results.

8. A method for implementing a layered architecture system for stress testing the MQTT protocol, characterized in that, include: The interface layer provides a call interface to receive load testing requests initiated by users, parse the load testing request parameters, encapsulate them into a load testing request configuration object, and initialize functional components and load testing thread pool. The functional components include a load generator, a one-on-one chat test sampler, a received message sampler, and a group chat test sampler. The business layer provides the general business functions and corresponding general business interfaces required for load testing requests, and starts the load testing thread pool based on a distributed instance coordination mechanism. The distributed instance coordination mechanism is as follows: During the load test startup phase, each instance does not immediately execute the load test task, but enters a spin-wait state and continuously polls the number of instances recorded in Redis. When the current number of load test instances reaches the number of instances configured in the load test request parameters, all instances start executing the load test task simultaneously. The sampling operation for MQTT load testing is provided through the protocol layer. The message data in the load testing thread is encapsulated into a message body that conforms to the MQTT protocol format, encoded through the I / O framework, and submitted to the load testing thread pool for asynchronous message sending operation. The message is sent to the MQTT server, and the return message sent by the MQTT server is received. The acknowledgment information is decoded through the I / O framework and encapsulated into an MQTT message object. The callback is then sent to the corresponding sampler to execute the corresponding processing logic. The protocol layer includes: The sampling module is used to configure the test type of the object according to the load testing request. The load testing thread calls the corresponding sampler from the functional components and encapsulates the message data in the load testing thread into a message body that conforms to the MQTT protocol format through the sampler. The I / O framework implementation module includes: an I / O framework extension module, which provides new and extended I / O frameworks; and an I / O framework switching module, which dynamically switches I / O frameworks and compares stress test results to select the optimal I / O framework for different business scenarios. The network layer sends the encoded message body to the MQTT server and receives the return message from the MQTT server based on the established network connection.

Images