Network performance monitoring method and device, electronic equipment and storage medium

Abstract

The invention provides a network performance monitoring method and device, electronic equipment and a storage medium. The method comprises the following steps: establishing an RPC data acquisition channel; wherein the RPC data acquisition channel is used for acquiring an RPC request actively sent to a server side and an RPC request pushed by the server side; acquiring monitoring data requested by the RPC based on the RPC data acquisition channel; wherein the monitoring data of the RPC request comprises a method name of the RPC request; the method name and the network service function have a mapping relationship; based on the monitoring data, determining a target RPC request which does not conform to a preset performance monitoring index; according to the method name of the target RPC request, determining a target service function and a function code corresponding to the target service function; and according to the function code, determining the reason for the network performance abnormity caused by the target RPC request. According to the mode, the analysis and debugging efficiency of the network performance exception problem is improved.

Description

Methods, devices, electronic equipment, and storage media for monitoring network performance Technical Field

[0001] This invention relates to the field of computer network technology, and in particular to a method, apparatus, electronic device, and storage medium for monitoring network performance. Background Technology

[0002] Modern networks commonly employ a microservices architecture, with services communicating via the RPC (Remote Procedure Call Protocol) framework. In network performance analysis scenarios, RPC-related data can be used to monitor the communication process.

[0003] In related technologies, network performance analysis often focuses on low-level network testing at the hardware level. This includes simulating weak network environments using specialized tools, conducting high-concurrency server stress tests, or using packet capture to analyze underlying network protocol data. Ultimately, this only yields abstract metrics such as latency and packet loss rate. Such solutions fail to provide clear direction for problem localization. When network performance anomalies are detected, tedious methods such as adding additional logs and meticulously checking code line by line are required to attempt to pinpoint the root cause, consuming significant time and manpower. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a method, apparatus, electronic device and storage medium for monitoring network performance, so as to improve the efficiency of analyzing and debugging network performance anomalies in microservice architecture.

[0005] In a first aspect, embodiments of the present invention provide a method for monitoring network performance. The method is applied to a client and includes: establishing an RPC data acquisition channel; wherein the RPC data acquisition channel is used to acquire RPC requests actively sent to a server and RPC requests pushed to a server; acquiring monitoring data of the RPC requests based on the RPC data acquisition channel; wherein the monitoring data of the RPC requests includes: the method name of the RPC request; the method name having a mapping relationship with network service functions; determining target RPC requests that do not meet preset performance monitoring indicators based on the monitoring data; determining the target service function and its corresponding function code based on the method name of the target RPC request; and determining the cause of network performance abnormalities caused by the target RPC request based on the function code.

[0006] Secondly, embodiments of the present invention provide a network performance monitoring device, which is installed on a client side. The device includes: a first assembly module for establishing an RPC data acquisition channel; wherein the RPC data acquisition channel is used to collect RPC requests actively sent to the server and RPC requests pushed to the server; a first acquisition module for acquiring monitoring data of RPC requests based on the RPC data acquisition channel; wherein the monitoring data of RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with network service functions; a first determination module for determining target RPC requests that do not meet preset performance monitoring indicators based on the monitoring data; and a second determination module for determining the target service function and its corresponding function code based on the method name of the target RPC request; and determining the cause of network performance abnormalities caused by the target RPC request based on the function code.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-described network performance monitoring method.

[0008] Fourthly, embodiments of the present invention provide a storage medium storing machine-executable instructions. When the machine-executable instructions are invoked and executed by a processor, the machine-executable instructions cause the processor to implement the aforementioned network performance monitoring method.

[0009] The embodiments of the present invention bring the following beneficial effects: The above-mentioned network performance monitoring method, apparatus, electronic device, and storage medium include: establishing an RPC data acquisition channel; wherein, the RPC data acquisition channel is used to acquire RPC requests actively sent to the server and RPC requests pushed to the server; based on the RPC data acquisition channel, acquiring monitoring data of RPC requests; wherein, the monitoring data of RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with network service functions; based on the monitoring data, determining the target RPC request that does not meet the preset performance monitoring indicators; determining the target service function and its corresponding function code according to the method name of the target RPC request; and determining the cause of the network performance abnormality caused by the target RPC request according to the function code.

[0010] In this approach, by establishing an RPC data acquisition channel, RPC requests actively sent by the client to the server and RPC requests pushed by the server can be directly collected. The method names of these RPC requests are obtained as monitoring data. The method names of the RPC requests have a mapping relationship with network service functions. From these RPC requests, target RPC requests that do not meet the preset performance monitoring indicators are identified. Then, the mapping relationship is used to trace back to the corresponding target service function, directly locating the function code corresponding to the target service function. By analyzing the function code, the root cause of the network performance abnormality caused by the target RPC request is determined.

[0011] This method captures RPC requests from the code logic layer, which can accurately locate the source of network request data in the business logic layer and intuitively determine the location of network performance bottlenecks in the business logic layer. Without adding extra logs or blindly checking the code, it can directly trace from abnormal RPC requests to the corresponding business functions and underlying business code, significantly improving the efficiency of analyzing and debugging network performance anomalies in microservice architecture.

[0012] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0013] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0014] 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.

[0015] Figure 1 is a flowchart of a network performance monitoring method provided in an embodiment of the present invention; Figure 2 is a schematic diagram of a data viewing interface provided in an embodiment of the present invention; Figure 3 is a structural schematic diagram of a network performance monitoring device provided in an embodiment of the present invention; Figure 4 is a structural schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0017] In related technologies, network performance analysis often focuses on low-level network testing at the hardware level. This includes simulating weak network environments using specialized tools, conducting high-concurrency server stress tests, or using packet capture to analyze low-level network protocol data. Testers typically rely on experience to preset common weak network test parameters (such as 200ms transmission latency and 3% packet loss rate) to conduct tests. However, such tests only obtain abstract hardware-level metrics like latency and packet loss rate. When abnormal network performance metrics are detected, technicians cannot directly link them to specific business function modules, making it difficult to pinpoint the root cause of performance problems. They can only attempt to locate the problem through tedious methods such as adding extra logs and checking code line by line, which not only lacks precise direction but also consumes significant time and manpower.

[0018] Based on this, the network performance monitoring method, apparatus, electronic device and storage medium provided in this embodiment of the invention can be applied to network performance monitoring scenarios.

[0019] To facilitate understanding of this embodiment, a network performance monitoring method disclosed in this embodiment of the invention will be described in detail first. As shown in Figure 1, the network performance monitoring method includes the following steps: Step S102: Establish an RPC data acquisition channel; wherein, the RPC data acquisition channel is used to collect RPC requests actively sent to the server and RPC requests pushed by the server.

[0020] In actual implementation, a pre-built data acquisition plugin is connected to the network sending and receiving components on the client side. The data acquisition plugin is embedded in the component code corresponding to the network sending and receiving components, and an RPC data acquisition channel is established. During the execution of the component code, various network operation data contained in the RPC request are captured in real time through the RPC data acquisition channel.

[0021] Here, the network sending component is the client's network communication module, responsible for encapsulating the business parameters of RPC requests and initiating communication with the server. It is the core carrier for the client to transmit business instructions to the server. The network receiving component is also a client's network communication module, responsible for listening for data pushes from the server to the client and receiving RPC request data packets pushed by the server to the client. In a microservice architecture, the network sending and receiving components belong to the code logic layer. These two components are business-related code modules written by developers, responsible for the conversion between business data and network transmission data, rather than the hardware layer or the pure low-level network layer.

[0022] The RPC requests captured by the RPC data acquisition channel include: RPC requests actively sent by the client to the server, and RPC requests pushed by the server to the client. Among the RPC requests pushed by the server to the client are attribute synchronization type RPC requests. That is, when the business attributes on the server change, the server will actively trigger and push this type of RPC request to the client. Upon receiving it, the client will synchronously update the corresponding local attribute status, achieving attribute data consistency between the server and the client.

[0023] Step S104: Based on the RPC data acquisition channel, obtain monitoring data of RPC requests; wherein, the monitoring data of RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with the network service function.

[0024] The method name of the aforementioned RPC request is used as a characteristic string to uniquely identify the business function corresponding to the RPC request, and has a one-to-one mapping relationship with the specific network business function under the microservice architecture.

[0025] For example, taking the game business scenario, the game microservice architecture contains multiple independent business function modules such as login, combat, store, and social. Each specific business function under each module corresponds to a unique RPC request method name.

[0026] If the game's business function is "player account and password login verification", the corresponding RPC method name can be set to game.login.account.verify; if the game's business function is "server synchronization of player combat damage data", the corresponding RPC method name can be set to game.battle.damage.sync.

[0027] Therefore, the method name `game.login.account.verify` uniquely maps to the business function of "verifying player account login with password". The method name `game.shop.item.purchase` uniquely maps to the business function of "players purchasing items in the game store".

[0028] When a client initiates an RPC request carrying the method name `game.login.account.verify`, the server can directly locate the "account and password login verification" business processing module through this method name and execute the corresponding account verification logic. Furthermore, if this RPC request experiences performance issues, the server can quickly pinpoint the specific "account and password login verification" business function through the method name, providing a clear direction for subsequent troubleshooting.

[0029] In addition, monitoring data for RPC requests may also include the RPC request invocation time, the parameter content of the RPC request, and the amount of data in the parameter content. The RPC request invocation time refers to the time when the client actively sends the RPC request to the server, or the time when the client receives the RPC request pushed by the server. The aforementioned RPC request parameter content refers to the parameter data transmitted along with the RPC request, conforming to the specifications of the corresponding protocol type.

[0030] Taking the game login scenario as an example, the RPC request with the method name game.login.account.verify is bound to the LoginVerifyProtocol protocol, which stipulates that two parameters must be passed: the player account of type string and the password of type string; therefore, the parameter content of this RPC request refers to the player account and password.

[0031] The data volume of the above parameters can be the size of the parameter content in bytes, i.e., the communication volume. The above RPC request invocation method refers to the RPC request sending method, including sending from the client to the server and sending from the server to the client.

[0032] In this step, monitoring data of the aforementioned RPC requests can be obtained through the RPC data acquisition channel.

[0033] Step S106: Based on monitoring data, identify target RPC requests that do not meet the preset performance monitoring indicators.

[0034] The aforementioned performance monitoring metrics are used to determine whether the RPC request is running normally. Specifically, they may include one or more of the following: the threshold for the number of RPC request calls, the threshold for the amount of data in the RPC request parameters, and the compliance metrics for the RPC request parameters.

[0035] If the initial collected RPC request monitoring data only contains the method name, then the method name is used as the retrieval identifier to retrieve one or more data such as the call time, parameter content, and data volume of the parameter content corresponding to the RPC request. The retrieved data is compared with the corresponding performance monitoring indicators one by one to filter out abnormal RPC requests that do not meet the performance monitoring indicators and identify them as target RPC requests.

[0036] Alternatively, while collecting the RPC request method name, one or more data such as its call time, parameter content, and the amount of data in the parameter content can be collected simultaneously. These data can be used together as the monitoring data for the RPC request. The monitoring data of each RPC request can be compared with the corresponding performance monitoring indicators one by one to filter out abnormal RPC requests that do not meet the indicator requirements and mark them as target RPC requests.

[0037] Taking the game login scenario as an example, the preset performance monitoring indicators can be configured as follows: the threshold for the number of calls is: the number of times the login verification RPC request (method name game.login.account.verify) is called within 5 minutes for a single account is ≤5 times; the threshold for the amount of data in the parameter content is: the amount of data in the parameter content of the login verification RPC request is ≤100 bytes; the compliance indicator for the parameter content is: the parameter content must contain the player's account and password.

[0038] Step S108: Determine the target business function and its corresponding function code based on the method name of the target RPC request; determine the cause of the network performance abnormality caused by the target RPC request based on the function code.

[0039] After determining the target RPC request, the target business function mapped to the method name of the target RPC request can be determined based on the mapping relationship.

[0040] Then, by searching the code layer globally, we can directly trace back to the corresponding business function and underlying business code. By analyzing the execution logic, data processing flow and resource call status of the function code, we can accurately locate the root cause of the network performance abnormality caused by the target RPC request.

[0041] For example, the target RPC request is named game.login.account.verify, and the target business function mapped to is "player account password login verification". The reason why it does not meet the preset performance monitoring indicators is that the number of calls by a single account within 5 minutes far exceeds the preset call count threshold.

[0042] By using the unique identifier corresponding to the target business function, a global search at the business code layer directly locates the verifyAccount(String playerAccount, String playerPassword) function code under the LoginVerifyService class of the "Login Verification Module" in the game microservice. Business personnel can analyze the execution logic of this code to determine the cause of network performance anomalies. For example, if business personnel find that the verifyAccount method does not have debouncing logic to limit the call frequency, when players quickly and continuously click the login button, the client will repeatedly initiate login verification requests, resulting in a surge in the number of calls in a short period of time. In addition, the code does not have a mechanism for "delayed retry after verification failure", and players' repeated login retries further exacerbate the problem of exceeding the call limit.

[0043] The above factors together caused the number of calls to the game.login.account.verify request to exceed the threshold, making it a target RPC request that did not meet the performance monitoring metrics, and also the reason why the target RPC request caused network performance abnormalities.

[0044] The aforementioned network performance monitoring method establishes an RPC data acquisition channel. This channel is used to collect RPC requests actively sent to the server and RPC requests pushed to the server. Based on the RPC data acquisition channel, monitoring data for the RPC requests is obtained. This monitoring data includes: the method name of the RPC request; a mapping relationship between the method name and network service functions; based on the monitoring data, target RPC requests that do not meet preset performance monitoring indicators are identified; according to the method name of the target RPC request, the target service function and its corresponding function code are determined; and based on the function code, the cause of the network performance anomaly caused by the target RPC request is determined.

[0045] In this approach, by establishing an RPC data acquisition channel, RPC requests actively sent by the client to the server and RPC requests pushed by the server can be directly collected. The method names of these RPC requests are obtained as monitoring data. The method names of the RPC requests have a mapping relationship with network service functions. From these RPC requests, target RPC requests that do not meet the preset performance monitoring indicators are identified. Then, the mapping relationship is used to trace back to the corresponding target service function, directly locating the function code corresponding to the target service function. By analyzing the function code, the root cause of the network performance abnormality caused by the target RPC request is determined.

[0046] This method captures RPC requests from the code logic layer, which can accurately locate the source of network request data in the business logic layer and intuitively determine the location of network performance bottlenecks in the business logic layer. Without adding extra logs or blindly checking the code, it can directly trace from abnormal RPC requests to the corresponding business functions and underlying business code, significantly improving the efficiency of analyzing and debugging network performance anomalies in microservice architecture.

[0047] The following implementation provides a specific method for establishing an RPC data acquisition channel.

[0048] Specifically, a pre-built data acquisition plugin is integrated into the first component code corresponding to the network sending component and the second component code corresponding to the network receiving component, so as to establish RPC data acquisition channels in the network sending component and network receiving component of the client respectively through the data acquisition plugin; wherein, the network sending component is used to actively send RPC requests to the server; the network receiving component is used to receive RPC requests pushed by the server to the client.

[0049] The aforementioned network sending component is the client's network communication module, responsible for encapsulating the business parameters of RPC requests and initiating communication with the server. It is the core carrier for the client to transmit business instructions to the server. The network receiving component is also a client's network communication module, responsible for listening for data pushes from the server to the client and receiving RPC request data packets pushed by the server to the client. In a microservice architecture, the network sending and receiving components belong to the code logic layer. These two components are business-related code modules written by developers, responsible for the conversion between business data and network transmission data, rather than the hardware layer or the pure low-level network layer.

[0050] In this method, a pre-built data acquisition plugin can be integrated into the client's network sending and receiving components via instrumentation. Specifically, the data acquisition plugin is integrated into the first component code corresponding to the network sending component and the second component code corresponding to the network receiving component. The plugin will establish RPC data acquisition channels within the client's network sending and receiving components, respectively, and these channels will be integrated into the execution flow of the aforementioned component code along with the plugin.

[0051] When the first and second component code runs, the RPC data acquisition channel will capture RPC requests in real time without intruding on the original business logic, and obtain data such as the method name, parameter content, and call time of the captured RPC requests.

[0052] The following examples provide a specific implementation of determining the target RPC request.

[0053] The methods for identifying target RPC requests that do not meet preset performance monitoring metrics may include at least one of the following: The monitoring data for the RPC request also includes the RPC request call time, and the performance monitoring metrics include a threshold for the number of RPC request calls; based on the RPC request call time, the number of RPC requests with the same method name within a preset time period is counted, and RPC requests with a call count exceeding the call count threshold are identified as target RPC requests; The monitoring data for the RPC request also includes the RPC request parameter content, and the performance monitoring metrics include a threshold for the data volume of the RPC request parameter content; the data volume of the RPC request parameter content is determined, and RPC requests with a data volume exceeding the data volume threshold for the parameter content are identified as target RPC requests; The monitoring data for the RPC request also includes the RPC request parameter content, and the performance monitoring metrics include: compliance metrics for the RPC request parameter content; The RPC request parameter content is verified, and RPC requests whose parameter content does not meet the compliance metrics for the parameter content are identified as target RPC requests.

[0054] The threshold for the number of times the aforementioned RPC request is invoked, the threshold for the amount of data in the parameters of the aforementioned RPC request, and the compliance indicators for the parameters of the RPC request are used to screen target RPC requests from the aspects of the frequency of RPC request invocation, the amount of data in the parameters, and the compliance of the parameters.

[0055] Specifically, to determine a target RPC request that does not meet the preset performance monitoring indicators, at least one of the following methods can be used: If the monitoring data of the RPC request also includes the call time of the RPC request, and the performance monitoring indicators have a threshold for the number of RPC requests, then based on the call time of the RPC request, the cumulative number of RPC requests with the same method name within a preset time period is counted; when the number of calls exceeds the preset call count threshold, the RPC request with the corresponding method name is determined to be the target RPC request.

[0056] If the monitoring data for the RPC request also includes the parameters of the RPC request, and the performance monitoring metrics have a threshold for the amount of data in the parameters of the RPC request, then the amount of data in the parameters of the RPC request, such as the number of bytes or characters, is calculated first; when the amount of data exceeds the threshold for the amount of data in the parameters, the RPC request is determined to be the target RPC request.

[0057] If the monitoring data of an RPC request contains parameter content, and the performance monitoring metrics include compliance metrics for the RPC request parameter content, such as parameter format, parameter field completeness, parameter value range, and whether it contains redundant / malicious fields, then the RPC request parameter content is checked to see if it meets the compliance metric requirements. RPC requests whose parameter content does not meet the compliance metric requirements are identified as the target RPC request.

[0058] Taking the game login scenario as an example, the preset performance monitoring indicators can be configured as follows: the threshold for the number of RPC request calls is: the number of times the login verification RPC request (method name game.login.account.verify) is called within 5 minutes for a single account is ≤5 times; for example, if the RPC request with the method name game.login.account.verify is initiated 8 times within 5 minutes, then the RPC request is identified as the target RPC request.

[0059] In one approach, a display plugin can be directly integrated into the client through a data acquisition plugin, allowing network performance analysis to begin at any time. By providing control, filtering, merging, and sorting functions within the display plugin, users can better integrate and analyze network request data.

[0060] Specifically, the RPC requests include multiple requests; these requests are integrated according to preset dimensions to obtain integrated RPC data; and a data viewing interface is generated in the graphical user interface provided by the client based on the integrated RPC data.

[0061] The preset dimensions can be at least one dimension, such as the calling method of the RPC request, the method name of the RPC request, the calling time of the RPC request, or the size of the data in the parameter content of the RPC request. After classifying and aggregating multiple RPC requests according to the preset dimensions, the integrated RPC data is obtained.

[0062] Then, by calling the interface of the preset drawing tool, the preset drawing tool can be controlled to render and generate a visual data viewing interface in the client's graphical user interface based on the integrated RPC data, intuitively displaying the running characteristics and parameter content of various RPC requests. This preset drawing tool can be a drawing tool built into the data acquisition plugin, such as the ImGui lightweight graphical interface drawing tool, which can be quickly embedded into the client program and generate an interactive graphical user interface.

[0063] Specifically, the following steps are taken: First, determine the calling method of the RPC request; second, classify and process multiple RPC requests according to the calling method to obtain the first integrated RPC data; third, determine the calling time of the RPC request; fourth, classify and process multiple RPC requests according to the method name of the RPC request to obtain the second integrated RPC data; fifth, determine the data volume of the parameter content of the RPC request; sixth, sort multiple RPC requests according to the calling time of the RPC request to obtain the third integrated RPC data; and finally, sort multiple RPC requests according to the size of the data volume of the parameter content of the RPC request to obtain the fourth integrated RPC data.

[0064] In other words, one approach can be divided into two types based on how the RPC request is invoked: RPC requests initiated by the client to the server and RPC requests pushed by the server to the client. Depending on the requirements, one type of RPC request data can be displayed to reduce interference from invalid data.

[0065] In one approach, multiple RPC requests can be categorized and processed according to the method name of the RPC request, and the number of calls corresponding to each RPC method name can be counted, allowing for a visual overview of high-frequency RPC requests.

[0066] In one approach, multiple RPC requests can be sequentially ordered according to their call times, allowing for a complete view of the RPC call sequence along a timeline, clearly presenting the trigger order and time distribution characteristics of the RPC requests.

[0067] In one approach, multiple RPC requests can be sorted directly according to the data volume of the parameters in the RPC request. This allows for quick identification of RPC requests with high communication volume, clarifying which RPC requests are consuming the main network transmission bandwidth between the client and server. This provides precise targets for investigation, enabling subsequent analysis of network performance bottlenecks and optimization of data transmission strategies.

[0068] In one approach, in response to a data update operation performed on the data viewing interface, the displayed content of the data viewing interface is updated; in response to a data save operation performed on the data viewing interface, the integrated RPC data is saved in a preset format.

[0069] The aforementioned data update operation refers to an interactive operation that triggers a dynamic change in the content, sorting, or range of monitoring data requested via RPC in the data viewing interface. The aforementioned data save operation refers to the triggering operation on the corresponding data save control in the data viewing interface. The aforementioned preset format can be CSV format.

[0070] As shown in Figure 2, the data viewing interface displays monitoring data for multiple RPC requests sorted by method name. The interface also includes several interactive controls, such as a data acquisition control, a data filtering control, a data sorting control, a data acquisition end control, and a data save control. Each interactive control is bound to a corresponding interactive operation. Users can trigger the interactive control by clicking, checking boxes, or selecting from dropdown menus to execute the corresponding interactive operation.

[0071] For example, when a user clicks the data retrieval control, the data retrieval operation is triggered. It continuously retrieves monitoring data from newly generated RPC requests, re-sorts them according to the default method name dimension, and updates the content displayed on the data viewing interface in real time, thus achieving dynamic data refresh.

[0072] After a user triggers a data filtering operation, the collected RPC monitoring data will be filtered according to the corresponding filtering conditions, retaining only the data that meets the conditions and updating it to the data viewing interface.

[0073] After a user triggers a data sorting operation, the system will reorder the RPC monitoring data according to the selected dimensions and refresh the display order of the data viewing interface.

[0074] The data acquisition, filtering, and sorting operations described above are all data update operations. However, Figure 2 also shows controls for ending the acquisition and saving data. These controls do not correspond to data update operations; rather, they are auxiliary operations that support static data analysis and persistent storage.

[0075] When the user clicks the "End Acquisition" control, the system will stop collecting RPC data in real time. The data viewing interface will then display all the data that has been collected so that it is convenient for users to perform static analysis. When the user clicks the "Save Data" control, the data saving operation is triggered. The system will name the currently integrated RPC data according to the current date and save it as a CSV file. After saving, the user can retrieve the file at any time for analysis or data comparison.

[0076] The following embodiments provide specific implementation methods for determining the functional code corresponding to the target business function.

[0077] In one approach, based on the mapping relationship, the target business function mapped to the method name of the target RPC request is determined; the identifier of the target business function is determined, and the corresponding function code is determined from the business code layer.

[0078] By comparing the monitoring data of each RPC request with the preset performance monitoring indicators one by one, abnormal RPC requests, i.e. target RPC requests, can be filtered out. Then, the target business function mapped to the method name of the target RPC request can be determined according to the mapping relationship.

[0079] Then, extract the unique business identifier corresponding to the target business function, such as the function code or business module identifier, and use this identifier as the retrieval basis to perform a global search and association matching at the business code layer, thereby accurately locating the function code corresponding to the target business function.

[0080] By analyzing the execution logic, data processing flow, and resource call status of the functional code, the root cause of the network performance anomaly caused by the target RPC request can be accurately located.

[0081] Corresponding to the above method embodiments, referring to Figure 3, a schematic diagram of a network performance monitoring device includes: a first assembly module 302, used to establish an RPC data acquisition channel; wherein, the RPC data acquisition channel is used to collect RPC requests actively sent to the server and RPC requests pushed by the server; a first acquisition module 304, used to acquire monitoring data of the RPC requests based on the RPC data acquisition channel; wherein, the monitoring data of the RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with network service functions; a first determination module 306, used to determine target RPC requests that do not meet preset performance monitoring indicators based on the monitoring data; a second determination module 308, used to determine the target service function and its corresponding function code according to the method name of the target RPC request; and determine the cause of network performance abnormality caused by the target RPC request according to the function code.

[0082] This method captures RPC requests from the code logic layer, which can accurately locate the source of network request data in the business logic layer and intuitively determine the location of network performance bottlenecks in the business logic layer. Without adding extra logs or blindly checking the code, it can directly trace from abnormal RPC requests to the corresponding business functions and underlying business code, significantly improving the efficiency of analyzing and debugging network performance anomalies in microservice architecture.

[0083] The aforementioned first component module is used to connect the pre-set data acquisition plugin to the first component code corresponding to the network sending component and the second component code corresponding to the network receiving component, so as to establish the RPC data acquisition channel in the network sending component and the network receiving component of the client respectively through the data acquisition plugin; wherein, the network sending component is used to actively send RPC requests to the server; the network receiving component is used to receive the RPC requests pushed by the server to the client.

[0084] The first determining module is configured to: count the number of times RPC requests with the same method name are called within a preset time period based on the call time of the RPC request; determine the number of times an RPC request is called with a call count threshold as the target RPC request; determine the data volume of the parameter content of the RPC request; determine the RPC request with the data volume exceeding the data volume threshold of the parameter content as the target RPC request; and verify the parameter content of the RPC request; determine the RPC request with the parameter content not conforming to the compliance indicators of the parameter content as the target RPC request.

[0085] The aforementioned RPC requests include multiple requests; the aforementioned device further includes a first integration module, used to integrate the multiple RPC requests according to a preset dimension to obtain integrated RPC data; and to generate a data viewing interface in the graphical user interface provided by the client based on the integrated RPC data.

[0086] The aforementioned first integration module is further configured to: determine the invocation method of the RPC request; classify the multiple RPC requests according to the invocation method to obtain first integrated RPC data; classify the multiple RPC requests according to the method name of the RPC request to obtain second integrated RPC data; determine the invocation time of the RPC request; sort the multiple RPC requests in chronological order according to the invocation time to obtain third integrated RPC data; and determine the data volume of the parameter content of the RPC request; sort the multiple RPC requests according to the data volume to obtain fourth integrated RPC data.

[0087] The first generation module is used to update the content displayed on the data viewing interface in response to the data update operation applied to the data viewing interface; wherein, the data update operation includes: data acquisition operation, data filtering operation and data sorting operation; and in response to the data saving operation applied to the data viewing interface, the integrated RPC data is saved in a preset format.

[0088] The second determining module is used to determine the target business function mapped to the method name of the target RPC request based on the mapping relationship; determine the identifier of the target business function; and determine the function code corresponding to the target business function from the business code layer.

[0089] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-mentioned network performance monitoring method.

[0090] Referring to Figure 4, the above-mentioned electronic device includes a processor 100 and a memory 101. The memory 101 stores machine-executable instructions that can be executed by the processor 100. The processor 100 executes the machine-executable instructions to implement the above-mentioned method for synchronizing physical information in the game.

[0091] Furthermore, the electronic device shown in Figure 4 also includes a bus 102 and a communication interface 103, with the processor 100, the communication interface 103, and the memory 101 connected via the bus 102.

[0092] The memory 101 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, only a single bidirectional arrow is used in Figure 4, but this does not imply that there is only one bus or one type of bus. The processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method can be completed through integrated logic circuits in the processor 100 hardware or through software instructions. The processor 100 described above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can 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 invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 101, and the processor 100 reads the information in memory 101 and, in conjunction with its hardware, completes the steps of the methods in the aforementioned embodiments.

[0093] The processor in the aforementioned electronic device, by executing machine-executable instructions, can perform the following operations of the aforementioned network performance monitoring method: establishing an RPC data acquisition channel; wherein, the RPC data acquisition channel is used to acquire RPC requests actively sent to the server and RPC requests pushed to the server; based on the RPC data acquisition channel, acquiring monitoring data of RPC requests; wherein, the monitoring data of RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with network service functions; based on the monitoring data, identifying target RPC requests that do not meet preset performance monitoring indicators; based on the method name of the target RPC request, determining the target service function and its corresponding function code; based on the function code, determining the cause of the network performance abnormality caused by the target RPC request.

[0094] This method captures RPC requests from the code logic layer, which can accurately locate the source of network request data in the business logic layer and intuitively determine the location of network performance bottlenecks in the business logic layer. Without adding extra logs or blindly checking the code, it can directly trace from abnormal RPC requests to the corresponding business functions and underlying business code, significantly improving the efficiency of analyzing and debugging network performance anomalies in microservice architecture.

[0095] The processor in the aforementioned electronic device, by executing machine-executable instructions, can implement the following operations of the aforementioned network performance monitoring method: a pre-set data acquisition plugin is connected to the first component code corresponding to the network sending component and the second component code corresponding to the network receiving component, so as to establish the RPC data acquisition channel in the network sending component and network receiving component of the client respectively through the data acquisition plugin; wherein, the network sending component is used to actively send RPC requests to the server; and the network receiving component is used to receive RPC requests pushed by the server to the client.

[0096] The processor in the aforementioned electronic device, by executing machine-executable instructions, can implement the following operations of the aforementioned network performance monitoring method: based on the call time of the RPC request, count the number of RPC requests with the same method name within a preset time period, and determine the RPC requests whose call count exceeds the call count threshold as the target RPC requests; determine the data volume of the parameter content of the RPC request, and determine the RPC requests whose data volume exceeds the data volume threshold of the parameter content as target RPC requests; verify the parameter content of the RPC request, and determine the RPC requests whose parameter content does not conform to the compliance indicators of the parameter content as target RPC requests.

[0097] The aforementioned RPC requests include multiple requests; the processor in the aforementioned electronic device, by executing machine-executable instructions, can implement the following operations of the aforementioned network performance monitoring method: integrate the multiple RPC requests according to a preset dimension to obtain integrated RPC data; and generate a data viewing interface in the graphical user interface provided by the client based on the integrated RPC data.

[0098] The processor in the aforementioned electronic device, by executing machine-executable instructions, can implement the following operations of the aforementioned network performance monitoring method: determining the invocation method of the RPC request; classifying and processing the multiple RPC requests according to the invocation method to obtain first integrated RPC data; classifying and processing the multiple RPC requests according to the method name of the RPC request to obtain second integrated RPC data; determining the invocation time of the RPC request; sorting the multiple RPC requests in chronological order according to the invocation time to obtain third integrated RPC data; determining the data volume of the parameter content of the RPC request; and sorting the multiple RPC requests according to the data volume to obtain fourth integrated RPC data.

[0099] The processor in the aforementioned electronic device can perform the following operations of the aforementioned network performance monitoring method by executing machine-executable instructions: updating the displayed content of the data viewing interface in response to a data update operation performed on the data viewing interface; and saving the integrated RPC data in a preset format in response to a data save operation performed on the data viewing interface.

[0100] The processor in the aforementioned electronic device can perform the following operations of the aforementioned network performance monitoring method by executing machine-executable instructions: determining the target service function mapped to the method name of the target RPC request based on the mapping relationship; determining the identifier of the target service function; and determining the function code corresponding to the target service function from the service code layer.

[0101] This embodiment also provides a storage medium storing machine-executable instructions. When the machine-executable instructions are invoked and executed by a processor, the machine-executable instructions cause the processor to implement the aforementioned network performance monitoring method.

[0102] The machine-executable instructions stored in the aforementioned storage medium can be used to perform the following operations in the aforementioned network performance monitoring method by executing these machine-executable instructions: establishing an RPC data acquisition channel; wherein, the RPC data acquisition channel is used to acquire RPC requests actively sent to the server and RPC requests pushed to the server; based on the RPC data acquisition channel, acquiring monitoring data of RPC requests; wherein, the monitoring data of RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with network service functions; based on the monitoring data, identifying target RPC requests that do not meet preset performance monitoring indicators; based on the method name of the target RPC request, identifying the target service function and its corresponding function code; and based on the function code, determining the cause of the network performance anomaly caused by the target RPC request.

[0103] This method captures RPC requests from the code logic layer, which can accurately locate the source of network request data in the business logic layer and intuitively determine the location of network performance bottlenecks in the business logic layer. Without adding extra logs or blindly checking the code, it can directly trace from abnormal RPC requests to the corresponding business functions and underlying business code, significantly improving the efficiency of analyzing and debugging network performance anomalies in microservice architecture.

[0104] The machine-executable instructions stored in the aforementioned storage medium can be used to perform the following operations in the aforementioned network performance monitoring method by executing these machine-executable instructions: A pre-configured data acquisition plugin is connected to the first component code corresponding to the network sending component and the second component code corresponding to the network receiving component, so as to establish the RPC data acquisition channel in the network sending component and network receiving component of the client respectively through the data acquisition plugin; wherein, the network sending component is used to actively send RPC requests to the server; and the network receiving component is used to receive RPC requests pushed by the server to the client.

[0105] The machine-executable instructions stored in the aforementioned storage medium can be used to perform the following operations in the aforementioned network performance monitoring method by executing these machine-executable instructions: based on the call time of the RPC request, count the number of RPC requests with the same method name within a preset time period, and identify RPC requests with a call count exceeding the call count threshold as target RPC requests; determine the data volume of the parameter content of the RPC request, and identify RPC requests with a data volume exceeding the data volume threshold of the parameter content as target RPC requests; verify the parameter content of the RPC request, and identify RPC requests with parameter content that does not conform to the compliance indicators of the parameter content as target RPC requests.

[0106] The aforementioned RPC requests include multiple requests; the machine-executable instructions stored in the aforementioned storage medium can be executed to perform the following operations in the aforementioned network performance monitoring method: integrating the multiple RPC requests according to a preset dimension to obtain integrated RPC data; and generating a data viewing interface in the graphical user interface provided by the client based on the integrated RPC data.

[0107] The machine-executable instructions stored in the aforementioned storage medium can be used to perform the following operations in the aforementioned network performance monitoring method by executing these machine-executable instructions: determining the calling method of the RPC request; classifying the multiple RPC requests according to the calling method to obtain first integrated RPC data; classifying the multiple RPC requests according to the method name of the RPC request to obtain second integrated RPC data; determining the calling time of the RPC request; sorting the multiple RPC requests in chronological order according to the calling time to obtain third integrated RPC data; and determining the data volume of the parameter content of the RPC request; sorting the multiple RPC requests according to the data volume to obtain fourth integrated RPC data.

[0108] The machine-executable instructions stored in the aforementioned storage medium can be executed to perform the following operations in the aforementioned network performance monitoring method: updating the displayed content of the data viewing interface in response to a data update operation performed on the data viewing interface; and saving the integrated RPC data in a preset format in response to a data save operation performed on the data viewing interface.

[0109] The machine-executable instructions stored in the aforementioned storage medium can be used to perform the following operations in the aforementioned network performance monitoring method: based on the mapping relationship, determine the target service function mapped to the method name of the target RPC request; determine the identifier of the target service function, and determine the function code corresponding to the target service function from the service code layer.

[0110] The computer program product of a network performance monitoring method, apparatus, electronic device, and storage medium provided in this embodiment of the invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0111] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0112] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0113] 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 invention, essentially, 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. 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.

[0114] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0115] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention 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 within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for monitoring network performance, characterized in that, The method is applied to a client and includes: establishing an RPC data acquisition channel; wherein the RPC data acquisition channel is used to acquire RPC requests actively sent to the server and RPC requests pushed by the server; based on the RPC data acquisition channel, acquiring monitoring data of the RPC requests; wherein the monitoring data of the RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with network service functions; based on the monitoring data, identifying target RPC requests that do not meet preset performance monitoring indicators; determining the target service function and its corresponding function code according to the method name of the target RPC request; and determining the cause of network performance abnormalities caused by the target RPC request according to the function code.

2. The method according to claim 1, characterized in that, The step of establishing an RPC data acquisition channel includes: integrating a pre-configured data acquisition plugin into the first component code corresponding to the network sending component and the second component code corresponding to the network receiving component, so as to establish the RPC data acquisition channel in the network sending component and the network receiving component of the client respectively through the data acquisition plugin; wherein, the network sending component is used to actively send RPC requests to the server; the network receiving component is used to receive RPC requests pushed by the server to the client.

3. The method according to claim 1, characterized in that, The step of determining target RPC requests that do not meet preset performance monitoring indicators based on the monitoring data includes at least one of the following: the monitoring data of the RPC request further includes the call time of the RPC request, and the performance monitoring indicator includes a threshold for the number of calls to the RPC request; based on the call time of the RPC request, the number of calls to RPC requests with the same method name within a preset time period is counted, and RPC requests with a call count exceeding the call count threshold are determined as target RPC requests; the monitoring data of the RPC request further includes the parameter content of the RPC request, and the performance monitoring indicator includes a threshold for the data volume of the parameter content of the RPC request; the data volume of the parameter content of the RPC request is determined, and RPC requests with a data volume exceeding the data volume threshold of the parameter content are determined as target RPC requests; The monitoring data for the RPC request also includes the parameter content of the RPC request, and the performance monitoring indicators include: compliance indicators of the parameter content of the RPC request; Verify the parameter content of the RPC request, and identify RPC requests whose parameter content does not meet the compliance indicators of the parameter content as target RPC requests.

4. The method according to claim 1, characterized in that, The RPC requests include multiple requests; after the step of obtaining the monitoring data of the RPC requests, the method further includes: integrating the multiple RPC requests according to a preset dimension to obtain integrated RPC data; and generating a data viewing interface in the graphical user interface provided by the client based on the integrated RPC data.

5. The method according to claim 4, characterized in that, The step of integrating the multiple RPC requests according to a preset dimension to obtain integrated RPC data includes at least one of the following: determining the calling method of the RPC request, classifying the multiple RPC requests according to the calling method, and obtaining first integrated RPC data; According to the method name of the RPC request, the multiple RPC requests are classified and processed to obtain the second integrated RPC data; Determine the call time of the RPC request, and sort the multiple RPC requests in chronological order according to the call time to obtain the third integrated RPC data; The amount of data in the parameter content of the RPC request is determined, and the multiple RPC requests are sorted according to the size of the data to obtain the fourth integrated RPC data.

6. The method according to claim 4, characterized in that, After the step of generating a data viewing interface in the graphical user interface provided by the client based on the integrated RPC data, the method includes: updating the display content of the data viewing interface in response to a data update operation applied to the data viewing interface; and saving the integrated RPC data in a preset format in response to a data save operation applied to the data viewing interface.

7. The method according to claim 1, characterized in that, The steps of determining the target business function mapped to the method name of the target RPC request and determining the corresponding function code of the target business function include: determining the target business function mapped to the method name of the target RPC request based on the mapping relationship; determining the identifier of the target business function; and determining the corresponding function code of the target business function from the business code layer.

8. A network performance monitoring device, characterized in that, The device is installed on the client side and includes: a first assembly module for establishing an RPC data acquisition channel; wherein the RPC data acquisition channel is used to acquire RPC requests actively sent to the server and RPC requests pushed by the server; a first acquisition module for acquiring monitoring data of the RPC requests based on the RPC data acquisition channel; wherein the monitoring data of the RPC requests includes: the method name of the RPC request; the method name has a mapping relationship with network service functions; a first determination module for determining target RPC requests that do not meet preset performance monitoring indicators based on the monitoring data; and a second determination module for determining the target service function and its corresponding function code based on the method name of the target RPC request; and determining the cause of network performance abnormalities caused by the target RPC request based on the function code.

9. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the network performance monitoring method according to any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores machine-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the network performance monitoring method according to any one of claims 1-7.

Images