Communication performance monitoring and evaluating method and device, electronic equipment and storage medium

Abstract

The invention provides a communication performance monitoring and evaluating method and device, electronic equipment and a storage medium, in the method, a hierarchical event tracking system is designed in a hierarchical architecture, supports dynamic expansion of a new event type and processing logic, can add a new tracker type without modifying a core code, and is good in expansibility and high in reliability. After the event callback function is registered on each layer of tracker, the type security check of the signature of the event callback function is carried out during compiling, so that the problem of type mismatching in the traditional callback mechanism is thoroughly solved. Static assertion is used for verifying correctness of callback function signatures in a compiling stage, runtime errors are found in advance to the compiling stage, stability and reliability of a system are greatly improved, the type is safe and reliable, a real-time communication performance statistical result can be finally output through a statistical component, and observability is good.

Description

Technical Field

[0001] This invention relates to the technical field of distributed system monitoring, and in particular to a method, apparatus, electronic device, and storage medium for monitoring and evaluating communication performance. Background Technology

[0002] In modern distributed systems and real-time application development, event-driven architecture has become the mainstream design pattern. Traditional event processing systems typically employ the following implementation methods: The observer pattern is implemented by defining an observer interface and an observed object to achieve an event subscription and notification mechanism. This approach is effective in simple scenarios, but suffers from poor type safety and limited extensibility in complex systems.

[0003] Callback function mechanism: This method directly uses function pointers or function objects as callbacks to handle events. However, it lacks a unified type checking and management mechanism, making it prone to runtime errors.

[0004] Message queue systems, such as RabbitMQ and Kafka, provide reliable event delivery mechanisms, but introduce additional system complexity and performance overhead.

[0005] Signal and slot mechanism: such as the signal and slot system in the Qt framework, provides type-safe event handling, but it is usually bound to a specific framework and lacks versatility.

[0006] The aforementioned traditional technologies have the following main technical defects and shortcomings: Insufficient type safety: Traditional callback mechanisms lack compile-time type checking, which can easily lead to runtime errors due to type mismatch.

[0007] Performance bottleneck: Frequent event triggering and callback calls often involve dynamic memory allocation and virtual function calls, which affect system performance.

[0008] Limited scalability: The existing system struggles to support dynamic expansion of new event types and processing logic, requiring modifications to the core code.

[0009] High management complexity: In large-scale distributed systems, the lack of a unified event tracking and management mechanism makes it difficult to achieve system-level monitoring and debugging.

[0010] Thread safety issues: Event handling mechanisms in multi-threaded environments often suffer from race conditions and data consistency problems.

[0011] In summary, traditional event-driven systems have inherent deficiencies in terms of type safety, scalability, and observability. Summary of the Invention

[0012] In view of this, the purpose of the present invention is to provide a method, apparatus, electronic device and storage medium for monitoring and evaluating communication performance, so as to alleviate the inherent defects of traditional event-driven systems in terms of type safety, scalability and observability.

[0013] In a first aspect, the present invention provides a method for monitoring and evaluating communication performance, comprising: Construct a hierarchical event tracing system, wherein the hierarchical event tracing system includes: an application layer tracker, a node layer tracker, and a communication endpoint layer tracker; The performance monitoring component registers event callback functions for handling target events on each layer of trackers and performs type safety checks on the event callback function signatures at compile time. During system operation, when the target event occurs, the corresponding layer tracker triggers the target event notification and executes the registered event callback function therein, and then the performance monitoring component non-intrusively collects the communication performance data of the target event; The statistics component performs streaming aggregation on the collected communication performance data and outputs communication performance statistics results.

[0014] Furthermore, a hierarchical event tracking system is constructed, including: Initialize the application layer tracker; Create the node layer tracker and the communication endpoint layer tracker, and establish a hierarchical management relationship. The application layer tracker manages the node layer tracker in singleton mode, and the node layer tracker manages the corresponding communication endpoint layer tracker. The communication endpoint layer tracker includes a subscription tracker and a publish tracker, which are used to monitor message reception processing and message sending processing, respectively.

[0015] Furthermore, the registered event callback functions are executed, and the performance monitoring component non-intrusively collects communication performance data of the target event, including: At the message publishing end, the publishing tracker injects tracking information, including the message identifier and the injection time, into the message body before the message is sent; On the message subscription side, the subscription tracker extracts the tracking information after the message arrives, and calculates the communication latency performance data of the message corresponding to the message identifier by comparing the current time with the injection time.

[0016] Furthermore, the statistical component supports chained combinations of multiple statistical analyzers, and performs streaming aggregation processing on the collected communication performance data, including: Multiple chained statistical analyzers perform real-time, multi-stage pipelined processing on the communication performance data to obtain the communication performance statistical results.

[0017] Furthermore, the type safety check is performed during the compilation phase using C++ template programming and static assertion techniques to verify the matching of the parameter types and return types of the event callback function with the expected event type. The application layer tracker, the node layer tracker, and the communication endpoint layer tracker are obtained by inheriting from and specializing the Tracker base template class; Mutexes are used between registering event callback functions on each tracker layer and executing the registered event callback functions to ensure safety in a multi-threaded environment.

[0018] Furthermore, the registration of the event callback function is achieved through a non-intrusive public event tracking mechanism; The monitoring logic of the performance monitoring component is decoupled from the business logic of the system.

[0019] Furthermore, the triggering target event notification employs type erasure technology to implement the event callback function call, thereby avoiding the overhead of virtual function calls.

[0020] Secondly, the present invention also provides an apparatus for monitoring and evaluating communication performance, comprising: A building unit is used to build a hierarchical event tracing system, wherein the hierarchical event tracing system includes: an application layer tracker, a node layer tracker, and a communication endpoint layer tracker; The registration and type safety check unit is used by the performance monitoring component to register event callback functions for handling target events on each layer of trackers, and to perform type safety checks on the event callback function signatures at compile time. The execution and acquisition unit is used to, during system operation, when the target event occurs, trigger the target event notification by the corresponding layer tracker and execute the event callback function registered therein, so that the performance monitoring component can non-intrusively acquire the communication performance data of the target event; The streaming aggregation processing unit is used to perform streaming aggregation processing on the collected communication performance data by the statistical component and output the communication performance statistical results.

[0021] Thirdly, the present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described in the first aspect.

[0022] Fourthly, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the method described in the first aspect.

[0023] This invention provides a method for monitoring and evaluating communication performance, comprising: constructing a layered event tracking system, wherein the layered event tracking system includes: an application layer tracker, a node layer tracker, and a communication endpoint layer tracker; a performance monitoring component registers event callback functions for handling target events on each layer tracker, and performs type safety checks on the event callback function signatures at compile time; during system operation, when a target event occurs, the corresponding layer tracker triggers a target event notification and executes the registered event callback functions therein, thereby the performance monitoring component non-intrusively collects communication performance data of the target event; a statistics component performs streaming aggregation processing on the collected communication performance data and outputs communication performance statistics results. As can be seen from the above description, in the communication performance monitoring and evaluation method of this invention, the layered event tracking system is designed with a layered architecture, supports dynamic expansion of new event types and processing logic, allows adding new tracker types without modifying the core code, has good scalability, and after registering event callback functions on each layer tracker, performs type safety checks on the event callback function signatures at compile time, completely solving the type mismatch problem in traditional callback mechanisms. Using static assertions to verify the correctness of callback function signatures during the compilation phase allows runtime errors to be detected earlier at the compilation stage, significantly improving the stability and reliability of the system. It is type-safe and reliable, and can ultimately output real-time communication performance statistics through a statistics component, providing good observability and mitigating the inherent defects of traditional event-driven systems in terms of type safety, extensibility, and observability. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a method for monitoring and evaluating communication performance provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a hierarchical event tracking system provided in an embodiment of the present invention; Figure 3 A schematic diagram of a communication performance monitoring and evaluation device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0026] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] Traditional event-driven systems have inherent flaws in terms of type safety, scalability, and observability.

[0028] Based on this, the layered event tracking system in the communication performance monitoring and evaluation method of this invention adopts a layered architecture design, supporting dynamic expansion of new event types and processing logic. New tracker types can be added without modifying the core code, demonstrating good scalability. After registering event callback functions on each layer of trackers, type safety checks on the event callback function signatures are performed at compile time, completely resolving the type mismatch problem in traditional callback mechanisms. Static assertions are used to verify the correctness of callback function signatures during the compilation phase, bringing runtime errors forward to the compilation stage, significantly improving system stability and reliability. The system is type-safe and reliable, and finally, real-time communication performance statistics can be output through a statistical component, providing good observability.

[0029] To facilitate understanding of this embodiment, a method for monitoring and evaluating communication performance disclosed in this embodiment of the invention will first be described in detail.

[0030] Example 1: According to an embodiment of the present invention, an embodiment of a method for monitoring and evaluating communication performance is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] Figure 1 This is a flowchart of a method for monitoring and evaluating communication performance according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps: Step S102: Construct a hierarchical event tracing system, wherein the hierarchical event tracing system includes: an application layer tracer, a node layer tracer, and a communication endpoint layer tracer; In this embodiment of the invention, the application layer tracker, node layer tracker, and communication endpoint layer tracker are obtained by inheriting from and specializing the Tracker base template class.

[0032] The Tracker basic template class provides a basic event logging and triggering mechanism, supporting the recording and restoration of arbitrary context data, as well as the recording and triggering of specified events.

[0033] The Tracker base template class is the abstract base class and general engine for the entire hierarchical event tracking system. It is not a concrete tracker that is used directly, but a "blueprint" that provides core functionality.

[0034] Its core responsibility is: Its core value lies in providing a type-safe event callback mechanism. Through C++ templates, it allows the registration of event callback functions with arbitrary signatures (function types) and ensures type safety at compile time.

[0035] Manage callback function list: Maintain a list to store all event callback functions registered to the tracker.

[0036] Provides an event triggering (Notify) interface: When a specific event (i.e. the target event) occurs, the Notify method is called to trigger the target event notification, iterate through the callback list and execute each event callback function.

[0037] To achieve thread safety: Mutex locks are used when registering event callback functions on each tracker layer and when executing registered event callback functions to ensure safety in a multi-threaded environment. `std::lock_guard` is used in the `Register` and `Notify` methods. <std::mutex>The goal is to ensure that no race conditions occur between registering a new event callback function and iterating through and executing the event callback functions, thus preventing program crashes.

[0038] Other specific trackers (such as ApplicationTracker, NodeTracker, and communication endpoint tracker) all inherit from this Tracker base class (i.e., the basic template class). This means that they automatically acquire the ability to register callbacks, trigger event notifications, and execute callbacks without having to repeatedly implement these common logics.

[0039] The application layer tracker supports tracking and triggering events throughout the entire application lifecycle, including initialization, startup, operation, shutdown, and destruction. The node layer tracker supports tracking and triggering events throughout the entire business node lifecycle, including initialization, startup, and creation of communication endpoints. The communication endpoint layer tracker includes a subscription tracker and a publisher tracker. The subscription tracker (SubscriberTracker) supports tracking and triggering events throughout the entire message reception and processing lifecycle, including message arrival, message scheduling, message processing, message discarding, and message release. The publisher tracker (PublisherTracker) supports tracking and triggering events throughout the entire message sending and processing lifecycle, including message creation, message sending, channel message creation, and channel message sending.

[0040] ApplicationTracker is a Tracker that specifically handles application-level events (such as initialization and startup). Its event callback functions may accept a structure representing the application state as a parameter.

[0041] NodeTracker is a Tracker that specializes in handling node-level events. Through this inheritance, each specific tracker becomes a strongly typed event hub that specializes in handling a particular type of event.

[0042] The process of building a hierarchical event tracking system will be described in detail below, and will not be repeated here.

[0043] Step S104: The performance monitoring component registers event callback functions for handling target events on each layer of trackers and performs type safety checks on the event callback function signatures at compile time. Specifically, the registration of event callback functions is implemented through a non-intrusive public event tracking mechanism; type safety checks are performed at the compilation stage using C++ template programming and static assertion techniques to verify the matching of the parameter types, return types, and expected event types of the event callback functions. The public tracking mechanism refers to the standard interfaces Register and Notify provided by the Tracker base class. These interfaces are public and uniform.

[0044] The BusinessMonitor component (performance monitoring component) injects its monitoring logic into various key nodes of the system by calling the PublisherTracker.Register() and SubscriberTracker.Register() methods. When an event occurs at these nodes, the Tracker automatically notifies the BusinessMonitor. Each module registers an event callback function through the corresponding OnXXX * method, where XXX is the specific event name.

[0045] This is analogous to this: Tracker provides standard "power outlets" (public tracking mechanisms). BusinessMonitor creates an "appliance" (monitoring logic) and plugs it into these outlets. Once the "circuit" is powered on (an event occurs), the "appliance" starts working.

[0046] Type safety: via the template parameter Tracker<Args...> Implementation. When registering an event callback function, the compiler checks if the signature of the event callback function matches Args... For example, NodeTracker expects a callback of type void(constNodeEvent&), and if a function of type void(int) is registered, a compile-time error will occur.

[0047] Step S106: During system operation, when a target event occurs, the corresponding layer tracker triggers a target event notification and executes the registered event callback function, thereby allowing the performance monitoring component to non-intrusively collect communication performance data of the target event. In this embodiment of the invention, the monitoring logic of the performance monitoring component is decoupled from the business logic of the system.

[0048] The aforementioned triggering of target event notifications employs type erasure to implement event callback function calls, thus avoiding the overhead of virtual function calls. Type erasure: `std::function` is a typical application of type erasure. It can wrap any callable object (function pointer, lambda expression, function object), erasing the specific type and retaining only the call signature. This allows the `Tracker` class to store callable objects of different types using a unified container.

[0049] The BusinessMonitor performance monitoring component is an advanced data analyzer. Its task is to process the raw event data (i.e., communication performance data, isolated timestamps and message IDs) generated by the underlying tracker into business-meaning performance metrics, such as end-to-end latency, throughput, and packet loss rate.

[0050] The performance monitoring component does not inherit from Tracker; instead, it is an independent component that depends on the Tracker system. It obtains data by registering event callback functions with various PublisherTrackers and SubscriberTrackers. Its relationship with the application-layer tracker, node-layer tracker, and communication endpoint-layer tracker is a "usage" (dependency) relationship: BusinessMonitor uses the data provided by these trackers.

[0051] In step S108, the statistics component performs streaming aggregation processing on the collected communication performance data and outputs the communication performance statistics results.

[0052] Specifically, the Summarizers statistics component supports streaming input of raw data (i.e., communication performance data); supports concatenating any Summarizer; and supports batch collection and packaging of statistical results.

[0053] The statistics component is a software component responsible for performing real-time aggregation calculations on raw monitoring data (i.e., communication performance data) and outputting meaningful statistical results (i.e., communication performance statistical results).

[0054] Input: A massive, fragmented stream of raw performance data (i.e., communication performance data, such as precise latency timestamps and message sizes for thousands of messages) generated by the BusinessMonitor component (i.e., the performance monitoring component). Processing: Rapid mathematical operations and aggregations are performed internally. Output: A concise, human- and machine-readable summary of performance metrics (i.e., communication performance statistics, such as average latency, maximum latency, and throughput over the past second).

[0055] This invention provides a method for monitoring and evaluating communication performance, comprising: constructing a layered event tracking system, wherein the layered event tracking system includes: an application layer tracker, a node layer tracker, and a communication endpoint layer tracker; a performance monitoring component registers event callback functions for handling target events on each layer tracker, and performs type safety checks on the event callback function signatures at compile time; during system operation, when a target event occurs, the corresponding layer tracker triggers a target event notification and executes the registered event callback functions therein, thereby the performance monitoring component non-intrusively collects communication performance data of the target event; a statistics component performs streaming aggregation processing on the collected communication performance data and outputs communication performance statistics results. As can be seen from the above description, in the communication performance monitoring and evaluation method of this invention, the layered event tracking system is designed with a layered architecture, supports dynamic expansion of new event types and processing logic, allows adding new tracker types without modifying the core code, has good scalability, and after registering event callback functions on each layer tracker, performs type safety checks on the event callback function signatures at compile time, completely solving the type mismatch problem in traditional callback mechanisms. Using static assertions to verify the correctness of callback function signatures during the compilation phase allows runtime errors to be detected earlier at the compilation stage, significantly improving the stability and reliability of the system. It is type-safe and reliable, and can ultimately output real-time communication performance statistics through a statistics component, providing good observability and mitigating the inherent defects of traditional event-driven systems in terms of type safety, extensibility, and observability.

[0056] The above provides a brief overview of the communication performance monitoring and evaluation method of the present invention. The specific details involved are described in detail below.

[0057] In an optional embodiment of the present invention, constructing a hierarchical event tracking system specifically includes the following steps: (1) Initialize the application layer tracer; (2) Create node layer trackers and communication endpoint layer trackers, and establish a hierarchical management relationship. The application layer tracker manages the node layer trackers in singleton mode, and the node layer trackers manage the corresponding communication endpoint layer trackers. The communication endpoint layer trackers include: subscription trackers and publish trackers, which are used to monitor message reception and message sending, respectively.

[0058] Specifically, such as Figure 2 As shown, the four trackers (application layer tracker, node layer tracker, subscription tracker, and publish tracker) are hierarchically managed and aggregated, forming a tree structure that clearly maps the physical architecture of the distributed system.

[0059] Their relationship is: The ApplicationTracker acts as a global singleton, managing the entire system. It knows and manages all the NodeTrackers.

[0060] Each NodeTracker represents a functional node in the system (such as a perception node or a planning node). It knows which PublisherTrackers (i.e., publishers, message publishers) and SubscriberTrackers (i.e., subscribers, message subscribers) it contains.

[0061] PublisherTracker and SubscriberTracker are the most basic leaf nodes, directly monitoring the sending and receiving of each data stream.

[0062] This relationship aligns perfectly with the communication path: the PublisherTracker sends messages to the SubscriberTracker. This makes it possible to track the entire lifecycle of a message (from publishing -> transmission -> reception -> processing).

[0063] ApplicationTracker: Used to monitor the overall health of the system. For example, it can record startup time and detect abnormal exits.

[0064] NodeTracker: Used to monitor the lifecycle and resource status of individual nodes. For example, it can detect whether a node has initialized correctly or plan whether a node has restarted.

[0065] PublisherTracker & SubscriberTracker: These are the core components of performance monitoring. They are responsible for "timestamping" (marking timestamps) on both the message publishing and subscription sides.

[0066] In PublisherTracker, a timestamp T1 is recorded at the moment before the message is sent, which is the injection time.

[0067] In SubscriberTracker, a timestamp T2 is recorded at the moment message processing begins.

[0068] Communication delay = T2 - T1.

[0069] In an optional embodiment of the present invention, the registered event callback function is executed, and the communication performance data of the target event is collected non-intrusively by the performance monitoring component, specifically including the following steps: (1) At the message publishing end, the publishing tracker injects tracking information containing the message identifier and injection time into the message body before the message is sent; (2) On the message subscription end, the subscription tracker extracts the tracking information after the message arrives, and calculates the communication delay performance data of the message corresponding to the message identifier by comparing the current time with the injection time.

[0070] Specifically, the performance monitoring component acquires information and data from key communication event nodes; injects tracking information into the communication sending end and retrieves it at the communication receiving end to obtain communication latency data; captures key message processing node events and tracks the entire message lifecycle information as input for analysis.

[0071] Obtaining information and data from key communication event nodes: This involves data acquisition. Information such as message ID, timestamp, and message size is obtained through point tracking.

[0072] The core monitoring logic involves injecting data at the sending end and retrieving it at the receiving end to obtain delayed data. When BusinessMonitor tracks data at the publishing end, it injects a tracking context (containing the message ID, publishing timestamp T1, i.e., the injection time) into the message (e.g., in the message header). When tracking data at the subscription end, it retrieves this context (i.e., the tracking information) from the message and subtracts T1 from the current time T2.

[0073] In an optional embodiment of the present invention, the statistical component supports a chained combination of multiple statistical analyzers. The statistical component performs streaming aggregation processing on the collected communication performance data, specifically including the following steps: Multiple chained statistical analyzers perform real-time, multi-stage pipelined processing of communication performance data to obtain communication performance statistics.

[0074] This application plan is divided into the following stages: Phase 1: System Initialization – Building the Monitoring Framework This stage is executed when the system starts up. Its purpose is to build the skeleton of the entire monitoring system and prepare the "listener".

[0075] 1. ApplicationTracker initialization It creates a globally unique instance of the ApplicationTracker class.

[0076] The reason for using a singleton is that an application process should have one and only one global, top-level monitoring manager. As the "root node" of the entire monitoring system, it will manage all NodeTrackers in the future.

[0077] 2. Event Callback Registration The performance monitoring component registers event callback functions on each layer of trackers to handle target events. BusinessMonitor is the "brain" of the entire monitoring system, containing the logic for calculating performance data. Event callback functions are individual functions provided by BusinessMonitor. Each function is responsible for handling a specific type of event. For example, one function might specifically calculate message latency, while another might specifically calculate message throughput.

[0078] The reason for registration is to "subscribe" to events. By registering callbacks (i.e., event callback functions), BusinessMonitor tells the system: "I am interested in 'message sending events' and 'message arrival events.' Once they occur, please notify me immediately (i.e., call the function I registered)." In BusinessMonitor's own initialization code, it calls methods such as PublisherTracker.OnMessageSent(myCallback) and SubscriberTracker.OnMessageArrived(myCallback) to register its callback functions with the corresponding Trackers.

[0079] 3. Type safety check (compile time) "Compilation" refers to the moment when the source code is compiled into an executable program, not when the program runs. This is a type of static analysis.

[0080] Static assertions (static_assert): This is a compile-time checking mechanism in C++. If the check conditions are not met, compilation will fail and an error will be reported.

[0081] Inside the Tracker's Register function, `static_assert` might be used to check whether the parameter types and return value types of the passed-in callback function are completely consistent with the event data types declared for this Tracker. This eliminates errors such as "the callback function cannot handle the event data it receives" at the source.

[0082] Phase Two: Event Triggering Phase – Execution Monitoring and Data Collection This phase occurs continuously during system operation and is the core loop of data acquisition.

[0083] 1. The incident occurred Target events are the key time points that you want to monitor in the system design. For example: communication events: before message is sent, after message arrives, and after message processing is completed; lifecycle events: node initialization, node startup, and node shutdown; resource events: memory allocation, lock acquisition and release.

[0084] 2. Event Notification Occurrence and triggering: Event occurrence: This is the result of the execution of business logic. For example, when business code calls publisher.send(msg), the "message sent" business event occurs.

[0085] Triggering event: This is the action of the monitoring system. To capture this business event, insert the following line of code immediately after the business logic inside the `publisher.send(msg)` function: `PublisherTracker.NotifyMessageSent(msg)`. This line of code triggers the monitoring event, meaning "notify all listeners that are interested in 'message sending'".

[0086] Relationship: The occurrence of an event is the cause, and the triggering event is the result. By "inserting" key points in the monitored business code, business events are transformed into signals that the monitoring system can perceive. The purpose is to "broadcast" the business events (i.e., the target events) to activate the monitoring logic.

[0087] 3. Callback execution Tracker base class: This is the Tracker basic template class introduced earlier. It is the parent class of all specific Trackers and provides core event management functionality.

[0088] Traversal execution: When the Notify method is called, the Tracker retrieves the list it maintains internally (the callback functions registered by BusinessMonitor during initialization are all in this list). Then, it calls each callback function in the list sequentially. This process of "calling them one by one" is called traversal.

[0089] Calling a callback function: When calling the callback function, event-related data (such as messages and timestamps) will also be passed in as parameters.

[0090] 4. Thread safety guarantee Mutex: A synchronization primitive, like a "key". Only when a thread obtains this key can it execute a protected piece of code (such as modifying a list of callback functions), while other threads must wait.

[0091] In the Tracker's Register (register callback) and Notify (trigger event) functions, a mutex lock is acquired first, and then unlocked after the operation is completed. This ensures that only one thread can modify the callback list or iterate through and execute callbacks at a time, preventing data corruption (race conditions) caused by multiple threads operating simultaneously. This is the fundamental mechanism that ensures the stable and reliable operation of the "callback execution" step in the process. Without it, the entire event system would crash in a multi-threaded, high-concurrency environment.

[0092] Phase Three: Hierarchical Management Process – Maintaining the Organization of the Monitoring System This phase is not a standalone step, but rather an organizational and management principle that runs throughout the entire lifecycle. It describes how instances are created in Phase One (created by the upper layer and managed by the lower layer). It describes how events are distributed in Phase Two (events first occur on the most specific Tracker, without escalating beyond the appropriate level). This ensures that the monitoring system itself has a clear and maintainable structure, and accurately reflects the physical and logical architecture of the monitored system.

[0093] The present invention has the following effects: System scalability has been greatly enhanced: This is because the architecture isolates changes at specific layers. For example, to add a "network health" monitor, you only need to add a new tracker at the communication layer, without affecting the core code at the node layer or application layer. Furthermore, the Tracker base class is a template class.<Args...> `Args...` is a variable-length template parameter that allows the `Tracker` class to accept event parameters of any type. This means that when defining new event types, there is no need to modify the underlying code of the `Tracker` class. Therefore, the layered architecture design of this invention supports the dynamic expansion of new event types and processing logic, allowing new tracker types to be added without modifying the core code. The template-based design enables the system to easily adapt to different business scenarios and changing requirements.

[0094] Development and maintenance costs have been significantly reduced: A unified event management interface is a common interface provided by all trackers, with consistent method signatures and behaviors. The two most important methods are: the Register method, used to register callback functions; and the Notify method, used to trigger events.

[0095] Regardless of the type of Tracker (ApplicationTracker, NodeTracker), developers use the same Register method to subscribe to events and similar NotifyXXX methods to trigger them. This greatly reduces the learning and usage costs.

[0096] A standardized implementation pattern refers to the fixed routine to follow when implementing a new tracker. It inherits from `Tracker<specific event parameter type>`. The `Notify` method is called where the event needs to be triggered. The tracker instance is registered with its parent tracker (e.g., a `NodeTracker` is registered with an `ApplicationTracker`) for management. This standardized development approach makes the code structure clear and easy to maintain.

[0097] In other words, a unified event management interface and standardized implementation pattern enable developers to quickly understand and use the system. The layered architecture clearly separates the event handling logic at different levels, reducing system complexity and maintenance difficulty.

[0098] Type security has been significantly improved: Tracker<Args...> The `Args...` parameter in the tracer specifies the parameter types of the events handled by the tracer. Traditional callbacks use `void*` or base class pointers, losing type information. Template-based design enforces type matching at compile time. Through template programming and compile-time type checking, the type mismatch problem in traditional callback mechanisms is completely solved. Static assertions are used to verify the correctness of the callback function signature during the compile phase, bringing runtime errors to the compilation stage and significantly improving system stability and reliability. In traditional callbacks, if a function handling node events is incorrectly registered to a message event, the program may compile successfully, but passing message data to that function at runtime will lead to memory access errors, data parsing errors, and other difficult-to-debug crashes. In this solution, the same error will be caught and reported by the compiler during the code compilation phase, making the program unable to run. Developers must immediately correct this type error, thus fundamentally eliminating such runtime failures (bringing runtime errors to the compilation stage).

[0099] Significant performance optimization results: Type erasure is a technique that erases specific type information while preserving a particular interface (such as callable). `std::function` is a typical application. In this scheme, it allows the Tracker to use a uniform container (such as a vector). <std::function<void(Args...)> The `std::function` pattern stores various callback objects (such as function pointers, lambda expressions, and function objects), even though these objects have different actual types. Traditional observer patterns typically require all listeners to inherit an interface with virtual functions. Calling a callback is a virtual function call, requiring lookup in the virtual function table (vtable), incurring additional overhead. However, the internal implementation of `std::function` often uses a technique called "small object optimization," which allows small callable objects (such as function pointers and small lambdas) to be stored inline, avoiding dynamic memory allocation. Its calling mechanism is also more efficient than virtual function calls. In other words, it uses type erasure to avoid the overhead of traditional virtual function calls and manages the lifecycle of callback objects through smart pointers, reducing the number of dynamic memory allocations. In high-frequency event-triggered scenarios, performance is improved by 30-50% compared to the traditional observer pattern.

[0100] Multithreading safety is guaranteed: The built-in thread safety mechanism ensures data consistency in event registration and triggering in a multi-threaded environment. Fine-grained locking strategies effectively avoid race conditions and improve the system's concurrency capabilities.

[0101] Enhanced system monitoring and debugging capabilities: The layered event tracing mechanism provides system-level monitoring and debugging capabilities, enabling real-time capture and analysis of system operating status. Complete event lifecycle tracing provides robust data support for system optimization and troubleshooting.

[0102] The key technical points of this invention are as follows: 1. Type-safe event callback mechanism a. Technical features: An event callback system based on C++ template type erasure, which ensures the correctness of callback function signatures through compile-time type checking.

[0103] b. Innovation: Using static assertions and callability checks to verify callback function types during the compilation phase, transforming runtime errors into compile-time errors (pre-checking).

[0104] c. Technical effect: It completely solves the type mismatch problem in the traditional callback mechanism, and improves the type security and stability of the system.

[0105] 2. High-performance event-triggered architecture a. Technical features: Type erasure is used to avoid the overhead of virtual function calls, and smart pointers are used to manage the lifecycle of callback objects, reducing dynamic memory allocation.

[0106] b. Innovation: Combining type erasure with modern C++ features to maximize performance while maintaining type safety.

[0107] c. Technical effect: In high-frequency event-triggered scenarios, the performance is improved by 30-50% compared to the traditional observer pattern.

[0108] 3. Layered event management architecture a. Technical features: A four-layer architecture consisting of ApplicationTracker, NodeTracker, SubscriberTracker, and PublisherTracker, with each layer responsible for event management within a specific scope.

[0109] b. Innovation: It adopts a layered design pattern to achieve a complete event tracing chain from the application level to the component level.

[0110] c. Technical effects: It provides a unified event management mechanism at the system level, supporting the monitoring and debugging of complex distributed systems.

[0111] Auxiliary technical features 1. Application-layer management using the Singleton pattern a. Technical features: ApplicationTracker adopts a singleton pattern to ensure a globally unique entry point for event management.

[0112] b. Innovation: By combining the friend class mechanism, controlled instance creation and access are achieved.

[0113] c. Technical effect: It simplifies the complexity of application layer event management and provides a unified system monitoring entry point.

[0114] 2. Thread-safe event handling mechanism a. Technical features: Built-in mutual exclusion mechanism protects the callback registration and triggering process, ensuring data consistency in a multi-threaded environment.

[0115] b. Innovation: Fine-grained locking strategy that balances thread safety and performance requirements.

[0116] c. Technical effect: Minimize the impact of lock contention on performance while ensuring thread safety.

[0117] 3. Standardized event type definitions a. Technical features: Standardized event type enumerations are defined through Protocol Buffers to ensure consistency and scalability of event types.

[0118] b. Innovation: Separating event type definition from implementation, supporting cross-language and cross-platform event handling.

[0119] c. Technical benefits: It provides a unified event type management mechanism, which facilitates system expansion and maintenance.

[0120] 4. Flexible parameter passing mechanism a. Technical features: Uses std::any as the event parameter container, supporting the transmission of event data of any type.

[0121] b. Innovation: While maintaining type safety, it provides flexible parameter passing capabilities.

[0122] c. Technical effect: It supports data transmission in complex event scenarios, enhancing the applicability of the system.

[0123] Example 2: This invention also provides a communication performance monitoring and evaluation apparatus, which is mainly used to execute the communication performance monitoring and evaluation method provided in Embodiment 1 of this invention. The following is a detailed description of the communication performance monitoring and evaluation apparatus provided in this invention.

[0124] Figure 3 This is a schematic diagram of a communication performance monitoring and evaluation device according to an embodiment of the present invention, as shown below. Figure 3 As shown, the device mainly includes: a construction unit 10, a registration and type security check unit 20, an execution and acquisition unit 30, and a streaming aggregation processing unit 40, wherein: The building block is used to build a layered event tracing system, which includes: an application layer tracer, a node layer tracer, and a communication endpoint layer tracer. The registration and type safety check unit is used by the performance monitoring component to register event callback functions for handling target events on each layer of trackers, and to perform type safety checks on the event callback function signatures at compile time. The execution and acquisition unit is used to trigger a target event notification by the corresponding layer tracker when a target event occurs during system operation, and execute the registered event callback function therein, so that the performance monitoring component can non-intrusively collect the communication performance data of the target event; The streaming aggregation processing unit is used by the statistical component to perform streaming aggregation processing on the collected communication performance data and output the communication performance statistical results.

[0125] This invention provides a communication performance monitoring and evaluation apparatus, comprising: constructing a layered event tracking system, wherein the layered event tracking system includes: an application layer tracker, a node layer tracker, and a communication endpoint layer tracker; a performance monitoring component registers event callback functions for handling target events on each layer tracker, and performs type safety checks on the event callback function signatures at compile time; during system operation, when a target event occurs, the corresponding layer tracker triggers a target event notification and executes the registered event callback functions therein, thereby the performance monitoring component non-intrusively collects communication performance data of the target event; a statistics component performs streaming aggregation processing on the collected communication performance data and outputs communication performance statistical results. As can be seen from the above description, in the communication performance monitoring and evaluation apparatus of this invention, the layered event tracking system is designed with a layered architecture, supports dynamic expansion of new event types and processing logic, allows the addition of new tracker types without modifying the core code, has good scalability, and after registering event callback functions on each layer tracker, performs type safety checks on the event callback function signatures at compile time, completely solving the type mismatch problem in traditional callback mechanisms. Using static assertions to verify the correctness of callback function signatures during the compilation phase allows runtime errors to be detected earlier at the compilation stage, significantly improving the stability and reliability of the system. It is type-safe and reliable, and can ultimately output real-time communication performance statistics through a statistics component, providing good observability and mitigating the inherent defects of traditional event-driven systems in terms of type safety, extensibility, and observability.

[0126] Optionally, the building unit is also used to: initialize the application layer tracker; create node layer trackers and communication endpoint layer trackers, and establish a hierarchical management relationship, wherein the application layer tracker manages the node layer trackers in singleton mode, and the node layer trackers manage the corresponding communication endpoint layer trackers, which include: subscription trackers and publish trackers, which are used to monitor message reception processing and message sending processing, respectively.

[0127] Optionally, the execution and acquisition unit is also used to: at the message publishing end, the publishing tracker injects tracking information containing the message identifier and the injection time into the message body before the message is sent; at the message subscription end, the subscription tracker extracts the tracking information after the message arrives, and calculates the communication latency performance data of the message corresponding to the message identifier by comparing the current time with the injection time.

[0128] Optionally, the statistics component supports chained combinations of multiple statistics units, and the streaming aggregation processing unit is also used for: real-time, multi-stage pipelined processing of communication performance data by multiple chained statistics units to obtain communication performance statistics results.

[0129] Optionally, type safety checks are performed during the compilation phase using C++ template programming and static assertion techniques to verify the matching of the parameter types and return types of the event callback functions with the expected event types; the application layer tracker, node layer tracker, and communication endpoint layer tracker are obtained by inheriting and specializing the Tracker base template class; a mutex lock is used between registering event callback functions on each layer tracker and executing the registered event callback functions to ensure safety in a multi-threaded environment.

[0130] Optionally, the registration event callback function is implemented through a non-intrusive public tracking mechanism; the monitoring logic of the performance monitoring component is decoupled from the system's business logic.

[0131] Optionally, the triggering of the target event notification uses type erasure technology to implement the event callback function call, in order to avoid the overhead of virtual function calls.

[0132] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0133] like Figure 4 As shown in the embodiment of this application, an electronic device 600 includes a processor 601, a memory 602, and a bus. The memory 602 stores machine-readable instructions executable by the processor 601. When the electronic device is running, the processor 601 communicates with the memory 602 via the bus. The processor 601 executes the machine-readable instructions to perform the steps of the communication performance monitoring and evaluation method described above.

[0134] Specifically, the memory 602 and processor 601 mentioned above can be general-purpose memory and processor, without any specific limitations. When the processor 601 runs the computer program stored in the memory 602, it can execute the above-mentioned method for monitoring and evaluating communication performance.

[0135] The processor 601 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 601 or by instructions in software form. The processor 601 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 602, and processor 601 reads the information from memory 602 and, in conjunction with its hardware, completes the steps of the above method.

[0136] Corresponding to the above-described method for monitoring and evaluating communication performance, this application also provides a computer-readable storage medium storing machine-executable instructions. When these machine-executable instructions are invoked and executed by a processor, they cause the processor to perform the steps of the above-described method for monitoring and evaluating communication performance.

[0137] The communication performance monitoring and evaluation device provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this application embodiment are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0138] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0139] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0140] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0141] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0142] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the communication performance monitoring and evaluation methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0143] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0144] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.< / std::mutex>

Claims

1. A method for monitoring and evaluating communication performance, characterized in that, include: Construct a hierarchical event tracing system, wherein the hierarchical event tracing system includes: an application layer tracker, a node layer tracker, and a communication endpoint layer tracker; The performance monitoring component registers event callback functions for handling target events on each layer of trackers and performs type safety checks on the event callback function signatures at compile time. During system operation, when the target event occurs, the corresponding layer tracker triggers the target event notification and executes the registered event callback function therein, and then the performance monitoring component non-intrusively collects the communication performance data of the target event; The statistics component performs streaming aggregation on the collected communication performance data and outputs communication performance statistics results.

2. The method according to claim 1, characterized in that, Constructing a hierarchical event tracking system includes: Initialize the application layer tracker; Create the node layer tracker and the communication endpoint layer tracker, and establish a hierarchical management relationship. The application layer tracker manages the node layer tracker in singleton mode, and the node layer tracker manages the corresponding communication endpoint layer tracker. The communication endpoint layer tracker includes a subscription tracker and a publish tracker, which are used to monitor message reception processing and message sending processing, respectively.

3. The method according to claim 1, characterized in that, The registered event callback functions are executed, and the performance monitoring component non-intrusively collects communication performance data of the target event, including: At the message publishing end, the publishing tracker injects tracking information, including the message identifier and the injection time, into the message body before the message is sent; On the message subscription side, the subscription tracker extracts the tracking information after the message arrives, and calculates the communication latency performance data of the message corresponding to the message identifier by comparing the current time with the injection time.

4. The method according to claim 1, characterized in that, The statistical component supports chained combinations of multiple statistical analyzers. The statistical component performs streaming aggregation processing on the collected communication performance data, including: Multiple chained statistical analyzers perform real-time, multi-stage pipelined processing on the communication performance data to obtain the communication performance statistical results.

5. The method according to claim 1, characterized in that, The type safety check is performed during the compilation phase using C++ template programming and static assertion techniques to verify the match between the parameter types and return types of the event callback function and the expected event type. The application layer tracker, the node layer tracker, and the communication endpoint layer tracker are obtained by inheriting from and specializing the Tracker base template class; Mutexes are used between registering event callback functions on each tracker layer and executing the registered event callback functions to ensure safety in a multi-threaded environment.

6. The method according to claim 1, characterized in that, The registration of the event callback function is achieved through a non-intrusive public event tracking mechanism; The monitoring logic of the performance monitoring component is decoupled from the business logic of the system.

7. The method according to claim 1, characterized in that, The triggering of the target event notification uses type erasure technology to implement the event callback function call, in order to avoid the overhead of virtual function calls.

8. A device for monitoring and evaluating communication performance, characterized in that, include: A building unit is used to build a hierarchical event tracing system, wherein the hierarchical event tracing system includes: an application layer tracker, a node layer tracker, and a communication endpoint layer tracker; The registration and type safety check unit is used by the performance monitoring component to register event callback functions for handling target events on each layer of trackers, and to perform type safety checks on the event callback function signatures at compile time. The execution and acquisition unit is used to, during system operation, when the target event occurs, trigger the target event notification by the corresponding layer tracker and execute the event callback function registered therein, so that the performance monitoring component can non-intrusively acquire the communication performance data of the target event; The streaming aggregation processing unit is used to perform streaming aggregation processing on the collected communication performance data by the statistical component and output the communication performance statistical results.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program is executed by the processor to perform the method of any one of claims 1 to 7.

Images