Latency parameter collection method and apparatus, electronic device, and storage medium

Abstract

The application provides a time delay parameter acquisition method, comprising: recording second timestamp information through the general execution engine when the server sends a task processing result to the client; and determining a time delay parameter of a use environment of the general execution engine based on the first timestamp information and the second timestamp information. The application also provides a time delay parameter acquisition device, an electronic device and a storage medium. The application can timely and accurately obtain a time delay parameter, monitor the task processing quality of an online service process, and does not need to invade a business processing process when the time delay parameter is obtained, thereby reducing the influence on task execution.

Description

Technical Field

[0001] This invention relates to latency parameter acquisition and processing technology in network communication, and particularly to latency parameter acquisition methods, devices, systems, equipment, and storage media. Background Technology

[0002] In related technologies, there are several ways to improve cluster resource utilization. One is to rationally allocate application resource requests within the cluster itself to run as many jobs as possible. Another is to fill in other jobs during off-peak hours to run more jobs. Online-offline co-deployment improves resource utilization by filling in offline jobs while online jobs are running. Offline tasks cannot be added indefinitely; it's necessary to ensure that online jobs are not affected and that their SLO (Solution Time Limit) remains within acceptable limits. Simultaneously, offline jobs must be able to quickly go online and offline, promptly relinquishing resources when online jobs require them. Therefore, it is necessary to obtain latency parameters accurately and promptly to monitor the task processing quality of online service processes. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a latency parameter acquisition method, device, electronic device, and storage medium, which can obtain latency parameters in a timely and accurate manner, monitor the task processing quality of online service processes, and at the same time, obtain latency parameters without intruding into the business processing process, thereby reducing the impact on task execution.

[0004] The technical solution of this invention is implemented as follows:

[0005] This invention provides a method for acquiring time delay parameters, including:

[0006] Obtain usage environment information for the general execution engine;

[0007] Based on the usage environment information of the general execution engine, determine the hook points that match the general execution engine;

[0008] The general execution engine is mounted at the hook point;

[0009] When the client sends a task request to the server, the first timestamp information is recorded through the general execution engine;

[0010] When the server sends the task processing result to the client, it records the second timestamp information through the general execution engine;

[0011] Based on the first timestamp information and the second timestamp information, the latency parameters of the usage environment of the general execution engine are determined.

[0012] This invention also provides a time delay parameter acquisition device, comprising:

[0013] The information transmission module is used to obtain the usage environment information of the general execution engine;

[0014] The information processing module is used to determine the hook point that matches the general execution engine based on the usage environment information of the general execution engine;

[0015] The information processing module is used to mount the general execution engine at the hook point;

[0016] The information processing module is used to record the first timestamp information through the general execution engine when the client sends task request information to the server.

[0017] The information processing module is used to record a second timestamp information through the general execution engine when the server sends the task processing result to the client.

[0018] The information processing module is used to determine the latency parameters of the usage environment of the general execution engine based on the first timestamp information and the second timestamp information.

[0019] In the above scheme,

[0020] The information processing module is used to determine the filtering conditions that match the task request information;

[0021] The information processing module is used to filter the task request information by means of filtering conditions that match the task request information, so as to obtain filtered task request information.

[0022] The information processing module is used to send the filtered task request information to the server through the general execution engine, and record the first timestamp information corresponding to the filtered task request information.

[0023] In the above scheme,

[0024] The information processing module is used to determine the configuration information of the general execution engine;

[0025] The information processing module is used to determine the probe code corresponding to the function call path of the general execution engine based on the configuration information of the general execution engine;

[0026] The information processing module is used to configure the corresponding data storage structure for the general execution engine based on the detection code.

[0027] In the above scheme,

[0028] The information processing module is used for user-mode application processes to obtain latency parameters and interface address information of the general execution engine's usage environment from the ring buffer area of ​​the general execution engine.

[0029] The information processing module is used to evaluate the online service quality of the server based on the latency parameters and interface address information of the usage environment of the general execution engine.

[0030] In the above scheme,

[0031] The information processing module is used to determine whether the idle node resources in the cluster resources meet the tasks to be processed by using the latency parameters and interface address information of the usage environment of the general execution engine.

[0032] The information processing module is used to process the task to be processed through the idle node resources when the idle node resources in the cluster resources meet the task to be processed.

[0033] The information processing module is used to select the corresponding idle node resources based on the latency parameters of the usage environment of the general execution engine when the idle node resources in the cluster resources do not meet the task to be processed.

[0034] In the above scheme,

[0035] The information processing module is used to parse the task to be processed and obtain the priority identifier of the task to be processed.

[0036] The information processing module is used to sort the priorities of the received tasks according to their priority identifiers.

[0037] The information processing module is used to create a corresponding queue of tasks to be processed based on the priority of the tasks to be processed.

[0038] In the above scheme,

[0039] The information processing module is used to traverse the queue of tasks to be processed and determine the task with the highest priority.

[0040] The information processing module is used to determine the link quality of each link in the network resources;

[0041] The information processing module is configured to configure the highest quality link in the network resources for the highest priority task to be processed, so as to process the tasks in the task queue through the configured link.

[0042] In the above scheme,

[0043] The information processing module is used to send the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters to the blockchain network, so that...

[0044] The nodes of the blockchain network fill the new block with the general execution engine identifier, the first timestamp information, the second timestamp information, and the latency parameters, and when there is consensus on the new block, the new block is appended to the end of the blockchain.

[0045] This invention also provides an electronic device, the electronic device comprising:

[0046] Memory, used to store executable instructions;

[0047] The processor, when running executable instructions stored in the memory, implements the aforementioned delay parameter acquisition method.

[0048] This invention also provides a computer-readable storage medium storing executable instructions, which, when executed by a processor, implement the aforementioned delay parameter acquisition method.

[0049] The embodiments of the present invention have the following beneficial effects:

[0050] This invention obtains the usage environment information of a general execution engine; based on the usage environment information, determines a hook point matching the general execution engine; attaches the general execution engine to the hook point; when a client sends a task request to a server, the general execution engine records a first timestamp; when the server sends a task processing result to the client, the general execution engine records a second timestamp; based on the first and second timestamps, the latency parameters of the general execution engine's usage environment are determined. This not only enables timely and accurate acquisition of latency parameters for monitoring the task processing quality of online service processes, but also avoids intruding into the business processing flow, minimizing the impact on task execution. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of the usage environment of the delay parameter acquisition method provided in the embodiment of the present invention;

[0052] Figure 2 This is a schematic diagram of the composition structure of the time delay parameter acquisition device provided in an embodiment of the present invention;

[0053] Figure 3 This is an optional flowchart illustrating the delay parameter acquisition method provided in an embodiment of the present invention.

[0054] Figure 4This is an optional flowchart illustrating the delay parameter acquisition method provided in an embodiment of the present invention.

[0055] Figure 5 This is an optional flowchart illustrating the delay parameter acquisition method provided in an embodiment of the present invention.

[0056] Figure 6 This is a schematic diagram of the architecture of the target object determination device 100 provided in an embodiment of the present invention;

[0057] Figure 7 This is a schematic diagram of the blockchain structure in the blockchain network 200 provided in this embodiment of the invention;

[0058] Figure 8 This is a schematic diagram of the functional architecture of the blockchain network 200 provided in an embodiment of the present invention;

[0059] Figure 9 This is a schematic diagram of the processing procedure of the delay parameter acquisition method in an embodiment of the present invention;

[0060] Figure 10 This is a schematic diagram illustrating the processing effect of the delay parameter acquisition method in an embodiment of the present invention. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on 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.

[0062] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0063] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0064] Before providing a further detailed description of the embodiments of the present invention, the nouns and terms involved in the embodiments of the present invention will be explained, and the nouns and terms involved in the embodiments of the present invention shall be interpreted as follows.

[0065] 1) The general-purpose execution engine, eBPF (extended Berkeley Packet Filter), provides the general capability to execute specific code efficiently and safely based on system or program events. Users of this general capability are no longer limited to kernel developers. eBPF consists of bytecode instructions, storage objects, and helper functions. Bytecode instructions must be verified by the BPF verifier before being executed by the kernel. In kernels with BPF JIT mode enabled, bytecode instructions are directly converted into kernel-executable native instructions for execution.

[0066] 2) Terminals, including but not limited to: ordinary terminals and dedicated terminals, wherein the ordinary terminals maintain a long connection and / or a short connection with the transmission channel, and the dedicated terminals maintain a long connection with the transmission channel.

[0067] 3) Client: A carrier in a terminal that implements specific functions. For example, a mobile client (APP) is a carrier of specific functions in a mobile terminal, such as performing online live streaming or playing online videos.

[0068] 4) In response to, used to indicate the conditions or states on which the operation performed depends. When the conditions or states on which it depends are met, one or more operations performed may be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0069] 5) Runtime environment, the engine used to interpret and execute code. For example, for the runtime environment of a mini-program, it could be JavaScript Core on the iOS platform or X5 JS Core on the Android platform.

[0070] 6) Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. It encompasses network technologies, information technologies, integration technologies, management platform technologies, and application technologies based on cloud computing business models. These technologies can form resource pools, allowing for flexible and convenient on-demand use. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring data to be transmitted to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will require robust system support, which can only be achieved through cloud computing.

[0071] 7) Cloud gaming: This refers to games that run on cloud server devices. The game screen rendered by the cloud device is encoded and transmitted to the user terminal via the network. The user terminal decodes the encoded file and renders it on the display screen. Thus, users do not need to install the game locally, but only need to establish a communication network connection with the cloud to complete the game interaction process.

[0072] 8) Server clustering refers to a system where many servers are grouped together to provide the same service, appearing to the client as a single server. Server clusters can utilize multiple computers for parallel computing to achieve high computing speeds, and can also use multiple computers for backup, ensuring that the entire system continues to operate normally even if one machine fails. The server cluster hard disk failure handling method provided in this application can be applied to cloud server and distributed server usage scenarios.

[0073] 9) Blockchain is an encrypted, chain-like storage structure for transactions formed by blocks.

[0074] For example, the header of each block can include the hash values ​​of all transactions in the block, as well as the hash values ​​of all transactions in the previous block, thereby preventing tampering and forgery of transactions in the block based on hash values; newly generated transactions are filled into the block and, after consensus among nodes in the blockchain network, are appended to the tail of the blockchain, thus forming a chain-like growth.

[0075] 10) A blockchain network is a collection of nodes that incorporate new blocks into a blockchain through consensus.

[0076] Figure 1 This is a schematic diagram illustrating a usage scenario of the time delay parameter acquisition method provided in this embodiment of the invention. (See attached diagram.) Figure 1The terminals (including terminals 10-1 and 10-2) are equipped with corresponding clients capable of performing different functions. These clients (terminals 10-1 and 10-2) obtain different task processing results from the corresponding servers 200 via network 300. Server 200 can receive task processing requests from different terminals. Terminals connect to server 200 via network 300, which can be a wide area network (WAN), a local area network (LAN), or a combination of both, using a wireless link for data transmission. Server 200 can be part of a server cluster. By using a mixed online and offline deployment, offline tasks are filled during the online job execution, improving resource utilization. However, offline tasks cannot be added indefinitely; online jobs must be unaffected, and their Service Level Loss (SLO) must remain within acceptable limits. Offline jobs must be able to quickly go online and offline, promptly relinquishing resources when needed by online jobs. Furthermore, once offline operations are running, the success rate of offline jobs must be guaranteed; a high failure rate due to frequent resource relinquishing must be avoided. Existing technologies often monitor the quality of online services through hardware metrics such as CPI or online service data collection and reporting. However, hardware metrics like CPI primarily reflect instruction execution efficiency. This method typically requires comparing CPI data with other nodes of the same type of service to determine if the current service is deviating from its normal value, resulting in low detection efficiency and reliance on multiple replicas of the online service. Furthermore, CPI is a hardware metric; if the host machine is a cloud virtual machine, limitations in data pass-through may prevent the acquisition of CPI data. Additionally, online service data collection and reporting schemes may suffer from inconsistent monitoring platforms for different services, and these platforms may not provide APIs for metric queries, thus compromising the timeliness of monitoring.

[0077] As an example, server 200 is used to deploy a latency parameter acquisition and processing device to implement the latency parameter acquisition method provided by this invention. This involves acquiring the usage environment information of a general execution engine; determining a hook point matching the general execution engine based on the usage environment information; attaching the general execution engine to the hook point; recording a first timestamp information through the general execution engine when a client sends a task request to the server; recording a second timestamp information through the general execution engine when the server sends a task processing result to the client; determining the latency parameters of the usage environment of the general execution engine based on the first and second timestamp information; and using the latency parameters of the usage environment of the general execution engine to monitor the task processing quality of the online service process.

[0078] The structure of the delay parameter acquisition device according to an embodiment of the present invention will be described in detail below. The delay parameter acquisition device can be implemented in various forms, such as a dedicated terminal with delay parameter acquisition processing function, or a server or server group equipped with delay parameter acquisition processing function, such as a target system deployed in a target system, such as the preceding one. Figure 1 Server 200 in the middle. Figure 2 This is a schematic diagram of the composition of the time delay parameter acquisition device provided in an embodiment of the present invention. It can be understood that... Figure 2 This is only an exemplary structure of the time delay parameter acquisition device, not the entire structure. Implementation can be carried out as needed. Figure 2 The structure shown may be part or all of the structure.

[0079] The time delay parameter acquisition device provided in this embodiment of the invention includes: at least one processor 201, a memory 202, a user interface 203, and at least one network interface 204. The various components in the time delay parameter acquisition device are coupled together through a bus system 205. It can be understood that the bus system 205 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 205 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 2 The general labeled all buses as Bus System 205.

[0080] The user interface 203 may include a monitor, keyboard, mouse, trackball, click wheel, buttons, touchpad, or touch screen.

[0081] It is understood that memory 202 can be volatile memory or non-volatile memory, or both. In this embodiment of the invention, memory 202 is capable of storing data to support the operation of a terminal (such as 10-1). Examples of this data include any computer programs used to operate on the terminal (such as 10-1), such as operating systems and applications. The operating system includes various system programs, such as the framework layer, core library layer, driver layer, etc., used to implement various basic services and handle hardware-based tasks. Applications can include various applications.

[0082] In some embodiments, the delay parameter acquisition device provided in this invention can be implemented using a combination of hardware and software. For example, the delay parameter acquisition device can be a processor in the form of a hardware decoding processor, programmed to execute the delay parameter acquisition method provided in this invention. For instance, the hardware decoding processor can employ one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0083] As an example of the hardware and software combined implementation of the delay parameter acquisition device provided in this embodiment of the invention, the delay parameter acquisition device provided in this embodiment of the invention can be directly embodied as a combination of software modules executed by the processor 201. The software modules can be located in a storage medium, which is located in the memory 202. The processor 201 reads the executable instructions included in the software modules in the memory 202 and combines them with necessary hardware (e.g., including the processor 201 and other components connected to the bus 205) to complete the delay parameter acquisition method provided in this embodiment of the invention.

[0084] As an example, processor 201 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0085] As an example of the hardware implementation of the delay parameter acquisition device provided in this embodiment of the invention, the device provided in this embodiment of the invention can be directly executed by a processor 201 in the form of a hardware decoding processor. For example, it can be executed by one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components to implement the delay parameter acquisition method provided in this embodiment of the invention.

[0086] In this embodiment of the invention, the memory 202 is used to store various types of data to support the operation of the delay parameter acquisition device. Examples of such data include: any executable instructions for operation on the delay parameter acquisition device, such as executable instructions, whereby a program implementing the delay parameter acquisition method of this embodiment of the invention may be included in the executable instructions.

[0087] In other embodiments, the delay parameter acquisition device provided in this invention can be implemented in software. Figure 2 A time delay parameter acquisition device stored in memory 202 is shown. This device can be software in the form of programs and plug-ins, and includes a series of modules. As an example of a program stored in memory 202, it may include the time delay parameter acquisition device. The time delay parameter acquisition device includes the following software modules: an information transmission module 2081 and an information processing module 2082. When the software modules in the time delay parameter acquisition device are read into RAM and executed by processor 201, the time delay parameter acquisition method provided in this embodiment of the invention will be implemented. The functions of each software module in the time delay parameter acquisition device include:

[0088] Information transmission module 2081 is used to obtain usage environment information of the general execution engine;

[0089] The information processing module is used to determine the hook point that matches the general execution engine based on the usage environment information of the general execution engine.

[0090] The information processing module 2082 is used to mount the general execution engine in the hook point;

[0091] The information processing module 2082 is used to record the first timestamp information through the general execution engine when the client sends task request information to the server.

[0092] The information processing module 2082 is used to record a second timestamp information through the general execution engine when the server sends the task processing result to the client.

[0093] The information processing module 2082 is used to determine the latency parameters of the usage environment of the general execution engine based on the first timestamp information and the second timestamp information.

[0094] Combination Figure 2 The delay parameter acquisition device shown illustrates the delay parameter acquisition method provided in this embodiment of the invention, wherein, it can be understood that, Figure 3 The steps shown can be performed by various electronic devices of the latency parameter acquisition device, such as a dedicated terminal with resource scheduling function, a server or server cluster controller, or a control terminal of a cloud network server. The dedicated terminal with the latency parameter acquisition device can be encapsulated within... Figure 1 In the server 200 shown, to execute the pre-processor Figure 2 The corresponding software modules in the time delay parameter acquisition device shown below. The following section addresses... Figure 3 The steps shown are explained.

[0095] Step 301: The latency parameter acquisition device obtains the usage environment information of the general execution engine.

[0096] Step 302: The latency parameter acquisition device determines the hook point that matches the general execution engine based on the usage environment information of the general execution engine.

[0097] Among these, hook points that match the general execution engine can use hooking technology. After hooking specific system events, once the hooked event occurs, the program that hooked the event will receive a system notification, and the program can then respond to the event immediately. (See reference...) Figure 1The server deploys an open service that communicates with the message processing device. This open server can specifically be a service with interface capabilities. Communication between the server and the message processing device can be achieved through this open service. For example, the server can provide a webhook address through this open service, and the message processing device can pass messages to the server through this webhook address. The interface address is the address provided by the server for communicating with the message processing device. For example, the server can provide a webhook address through the deployed open service, and the message processing device can pass messages to the server through this webhook address. Here, the webhook address is the interface address. The configuration parameters corresponding to the message processing device can specifically include a preset format corresponding to the response message, a virtual user identifier, a network address, a communication token, and an encryption key. The network address is the address used in the message processing service to receive session messages.

[0098] Step 303: The delay parameter acquisition device attaches the general execution engine at the hook point.

[0099] In some embodiments of the present invention, the general execution engine can be eBPF. eBPF is a general execution engine that provides the general capability to execute specific code efficiently and safely based on system or program events. Users of the general capability are no longer limited to kernel developers. eBPF can consist of bytecode instructions, storage objects, and helper functions. The bytecode instructions must be verified by the BPF verifier before being executed by the kernel. At the same time, in a kernel with BPF JIT mode enabled, the bytecode instructions will be directly converted into kernel-executable native instructions for execution.

[0100] When attaching the general execution engine to the hook point, the configuration information of the general execution engine can be determined first. Based on the configuration information of the general execution engine, the probe code corresponding to the function call path of the general execution engine can be determined. Based on the probe code, the corresponding data storage structure for the configuration of the general execution engine can be determined. Specifically, when a user program calls a system call, kprobe or kretprobe probe code can be added to the relevant function call path to record relevant information in the eBPF built-in Map storage structure. Thus, the user-space program can perform task processing and monitoring based on the data in the Map. Among them, kprobe has two main usage methods: one is through module loading, and the other is through the debugfs interface. When using it through module loading, there is a directory sample / kprobes in the kernel source code. This directory contains many kprobe examples. Taking kprobe_example.c as an example, firstly, a kprobe structure is declared, and then several key member variables are defined, including symbol_name, pre_handler, and post_handler. Here, `symbol_name` is the function name (in `kprobe_example.c`, this is `do_fork`), and `pre_handler` and `post_handler` represent the hook functions executed before and after the probe point, respectively. Then, the `register_kprobe` function is used to register the `kprobe`, thereby adding `kprobe` probe code to the relevant function call path.

[0101] Step 304: When the client sends a task request to the server, the latency parameter acquisition device records the first timestamp information through the general execution engine.

[0102] In some embodiments of the present invention, reference is made to Figure 4 , Figure 4 This is a schematic diagram illustrating the process of the general execution engine recording timestamp information in an embodiment of the present invention, specifically including the following steps:

[0103] Step 401: Determine the filtering conditions that match the task request information;

[0104] Step 402: Filter the task request information using filtering conditions that match the task request information to obtain filtered task request information;

[0105] Step 403: The filtered task request information is sent to the server through the general execution engine, and the first timestamp information corresponding to the filtered task request information is recorded.

[0106] Among them, with Figure 4 For example, TCP network communication typically calls the functions skb_copy_datagram_iter and tcp_sendmsg to handle data transfer. The sendmsg system call is used to send messages to another socket.

[0107] Without conditional filtering, the overall protocol stack processing efficiency will be affected. Therefore, conditional filtering is necessary when executing eBPF programs to improve overall execution efficiency. For the latency of requests that need to be captured, the program will use some information as meta information as filtering conditions in the eBPF program, such as the server port number and the request's HTTP method. Specifically, the HTTP method can include the following types:

[0108] 1) GET requests the specified page information and returns the entity body. 2) HEAD is similar to a GET request, but the response does not contain content; it is used to retrieve headers. 3) POST submits data to the specified resource for processing (e.g., submitting a form or uploading a file). The data is included in the request body. POST requests may result in the creation of new resources and / or modification of existing resources. 4) PUT sends data from the client to the server, replacing the content of the specified document. 5) DELETE requests the server to delete the specified page. 6) CONNECT is reserved in the HTTP / 1.1 protocol for proxy servers that can switch to piped connections. 7) OPTIONS allows the client to view server performance. 8) TRACE echoes the request received by the server, primarily used for testing or diagnostics. 9) PATCH contains a table describing the differences from the original content represented by the URI. 10) COPY requests the server to copy the specified page to another network address.

[0109] Step 305: When the server sends the task processing result to the client, the latency parameter acquisition device records the second timestamp information through the general execution engine.

[0110] Step 306: The latency parameter acquisition device determines the latency parameters of the usage environment of the general execution engine based on the first timestamp information and the second timestamp information.

[0111] After determining the latency parameters of the general execution engine's usage environment, the user-space application process can obtain the latency parameters and interface address information of the general execution engine's usage environment from the ring buffer area of ​​the general execution engine; based on the latency parameters and interface address information of the general execution engine's usage environment, the online service quality of the server can be evaluated.

[0112] refer to Figure 5 , Figure 5 This is a schematic diagram illustrating the process by which a user-mode application process evaluates the online service quality of a server in an embodiment of the present invention, specifically including the following steps:

[0113] Step 501: The general execution engine monitors the task processing process of the online service program through hook points.

[0114] exist Figure 5 In the processing illustrated, kernel mode can be a state with abundant resources, or it can access resources in a privileged state. User mode, on the other hand, is a non-privileged state, and its access to resources is restricted. If a program is running in privileged mode, it can access any resource on the computer without any restrictions. If a program runs in user mode, its resource requirements will be subject to various limitations. For example, accessing kernel data structures such as the process table requires special privilege mode. Figure 5 During processing, the general execution engine operates in kernel mode, while user-mode application processes can only obtain latency data from a fixed circular buffer area. When the execution engine's usage environment changes, user-mode application processes can switch from user mode to kernel mode to obtain more data.

[0115] Step 502: The general execution engine records the latency parameters and sends them to the circular buffer area.

[0116] Step 503: The user-mode application process obtains the latency data in the circular buffer area.

[0117] In some embodiments of the present invention, the online service quality of the server can be evaluated by:

[0118] By using the latency parameters and interface address information of the general execution engine's usage environment, it is determined whether the idle node resources in the cluster resources can meet the pending tasks. When the idle node resources in the cluster resources meet the pending tasks, the pending tasks are processed using the idle node resources. When the idle node resources in the cluster resources do not meet the pending tasks, a corresponding idle node resource is selected based on the latency parameters of the general execution engine's usage environment. In some embodiments of the present invention, the pending tasks can be parsed to obtain their priority identifiers. Based on the priority identifiers, the priorities of the received pending tasks are sorted. Based on the priorities of the pending tasks, a corresponding pending task queue is created. This enables differentiated processing for different clients. Simultaneously, the pending task queue is traversed to determine the highest priority pending task; the link quality of each link in the network resources is determined; and the link with the highest link quality in the network resources is configured for the highest priority pending task to enable transmission of pending tasks in the pending task queue through the configured link. This improves resource utilization efficiency, ensures timely processing of high-priority tasks, guarantees data processing speed for cloud server users, and enhances the user experience.

[0119] Further, see Figure 6 , Figure 6 This is a schematic diagram of the architecture of the data processing device 100 provided in an embodiment of the present invention, including a blockchain network 200 (consensus nodes 210-1 to 210-3 are shown as examples), an authentication center 300, a business entity 400 and a business entity 500, which will be described below.

[0120] The types of blockchain networks 200 are flexible and diverse, and can be any of the following: public blockchain, private blockchain, or consortium blockchain. Taking a public blockchain as an example, electronic devices of any business entity, such as user terminals and servers, can access the blockchain network 200 without authorization. Taking a consortium blockchain as an example, after obtaining authorization, the electronic devices (such as terminals / servers) under the business entity can access the blockchain network 200, at which point they become client nodes in the blockchain network 200.

[0121] In some embodiments, client nodes may act only as observers of the blockchain network 200, providing support for business entities to initiate transactions (e.g., for storing data on-chain or querying on-chain data). For the functions of the consensus nodes 210 of the blockchain network 200, such as sorting, consensus services, and ledger functions, client nodes may implement them by default or selectively (e.g., depending on the specific business needs of the business entity). This allows for the maximum migration of business entity data and business processing logic to the blockchain network 200, achieving trustworthiness and traceability of data and business processing through the blockchain network 200.

[0122] Consensus nodes in blockchain network 200 receive data from different business entities (e.g.) Figure 1 The client nodes of business entities 400 and 500 shown in the figure (e.g., Figure 1 Transactions submitted by client node 410 belonging to business entity 400 and client node 510 belonging to database operator system 500 (shown in the figure) are executed to update or query the ledger. Various intermediate or final results of the execution of the transactions can be returned to the client node of the business entity for display.

[0123] For example, client nodes 410 / 510 can subscribe to events of interest in the blockchain network 200, such as transactions occurring in a specific organization / channel within the blockchain network 200. Consensus node 210 then pushes the corresponding transaction notifications to client nodes 410 / 510, thereby triggering the corresponding business logic in client nodes 410 / 510.

[0124] The following example illustrates an exemplary application of blockchain networks, using the scenario of multiple business entities accessing a blockchain network to achieve distributed data processing.

[0125] See Figure 6 The management process involves multiple business entities, such as business entity 400 (which could be a server with data processing capabilities) and business entity 500 (which could be different service cluster front-ends with self-developed resource scheduling systems). Each entity registers with certification center 300 to obtain its own digital certificate. The digital certificate includes the business entity's public key and a digital signature from certification center 300 on the business entity's public key and identity information. This digital signature, along with the business entity's digital signature for the transaction, is attached to the transaction and sent to the blockchain network. The blockchain network then retrieves the digital certificate and signature from the transaction to verify the message's reliability (i.e., whether it has been tampered with) and the identity information of the business entity that sent the message. The blockchain network verifies the identity, such as whether the entity has the authority to initiate the transaction. Clients running on electronic devices (e.g., terminals or servers) under the business entity can request access to the blockchain network 200 and become client nodes.

[0126] The client node 410 of the business entity 400 is used to acquire and receive pending job data and submit the pending job data to the cluster resource manager. Through the cluster resource manager, the corresponding component is triggered according to the pending job data to convert the object-oriented query language instructions in the pending job data into tasks that match the corresponding computing engine, and the job manager of the computing engine is started. Based on the number of resources submitted by the data warehouse tool driver component, the resource request corresponding to the pending job data is sent to the job manager of the self-developed resource scheduling system. The job manager of the self-developed resource scheduling system converts the received resource request to match the resource request with the self-developed resource scheduling system. Based on the converted resource request, the corresponding task execution component is triggered, and the pending job data is processed by the task execution component. The general execution engine identifier, first timestamp information, second timestamp information, and latency parameters are sent to the blockchain network 200.

[0127] The process of sending the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters to the blockchain network 200 can be pre-configured on the client node 410 using business logic. When the corresponding text information is generated, the client node 410 automatically sends the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters to the blockchain network 200. Alternatively, business personnel from the business entity 400 can log in to the client node 410, manually package the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters, and send it to the blockchain network 200. During transmission, the client node 410 generates a corresponding update operation transaction based on the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters. The transaction specifies the smart contract to be invoked to implement the update operation and the parameters to be passed to the smart contract. The transaction also carries the client node 410's digital certificate and a signed digital signature (e.g., obtained by encrypting the transaction digest using the private key in the client node 410's digital certificate), and broadcasts the transaction to the consensus node 210 in the blockchain network 200.

[0128] When consensus node 210 in blockchain network 200 receives a transaction, it verifies the digital certificate and digital signature carried in the transaction. If the verification is successful, it confirms whether business entity 400 has the authority to conduct the transaction based on the identity of the business entity 400 carried in the transaction. Either verification of the digital signature or the authorization will cause the transaction to fail. After successful verification, node 210 signs its own digital signature (e.g., by encrypting the transaction digest using node 210-1's private key) and continues broadcasting it within blockchain network 200.

[0129] After receiving a successfully verified transaction, consensus node 210 in blockchain network 200 populates the transaction into a new block and broadcasts it. When broadcasting a new block, consensus node 210 in blockchain network 200 performs a consensus process on the new block. If the consensus is successful, the new block is appended to the end of its stored blockchain, and the state database is updated according to the transaction results. The transactions in the new block are then executed: for transactions that submit updates to the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters, key-value pairs including the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters are added to the state database.

[0130] Business personnel of business entity 500 log in to client node 510 and enter a query request for target video or text information. Client node 510 generates a corresponding update / query transaction based on the query request. The transaction specifies the smart contract to be called to implement the update / query operation and the parameters to be passed to the smart contract. The transaction also carries the digital certificate of client node 510 and a signed digital signature (for example, obtained by encrypting the transaction digest using the private key in the digital certificate of client node 510), and broadcasts the transaction to consensus node 210 in blockchain network 200.

[0131] When a consensus node 210 in the blockchain network 200 receives a transaction, it verifies the transaction, fills in the block, and reaches consensus. Then, it appends the new block to the end of the blockchain it stores and updates the state database according to the transaction result. It then executes the transactions in the new block: for a transaction that updates the human identification result corresponding to a target video, it updates the key-value pair corresponding to the target video in the state database according to the human identification result; for a transaction that queries a target video, it queries the key-value pair corresponding to the target video in the state database and returns the transaction result.

[0132] It is worth noting that, in Figure 6The example illustrates the process of directly uploading the general execution engine identifier, first timestamp information, second timestamp information, and latency parameters to the blockchain. However, in other embodiments, when the target video data volume is large, the client node 410 can upload the hash of the target video and the hash of the corresponding text information to the blockchain in pairs, storing the original target video and the corresponding text information in a distributed file system or database. After the client node 510 obtains the target video and the corresponding text information from the distributed file system or database, it can verify them by combining the corresponding hash in the blockchain network 200, thereby reducing the workload of uploading to the blockchain.

[0133] As an example of blockchain, see Figure 7 , Figure 7 This is a schematic diagram of the blockchain structure in the blockchain network 200 provided in this embodiment of the invention. The header of each block can include the hash values ​​of all transactions in the block, as well as the hash values ​​of all transactions in the previous block. The record of a newly generated transaction is filled into the block and, after consensus among the nodes in the blockchain network, is appended to the tail of the blockchain to form a chain-like growth. The chain structure between blocks based on hash values ​​ensures the tamper-proof and anti-forgery properties of the transactions in the block.

[0134] The following describes an exemplary functional architecture of the blockchain network provided in the embodiments of the present invention. See also... Figure 8 , Figure 8 This is a functional architecture diagram of the blockchain network 200 provided in an embodiment of the present invention, including an application layer 201, a consensus layer 202, a network layer 203, a data layer 204, and a resource layer 205, which will be described below.

[0135] Resource layer 205 encapsulates the computing resources, storage resources, and communication resources of each node 210 in the blockchain network 200.

[0136] Data layer 204 encapsulates various data structures that implement the ledger, including blockchains implemented as files in a file system, key-value state databases, and proof of existence (such as hash trees of transactions in blocks).

[0137] Network layer 203 encapsulates the functions of point-to-point (P2P) network protocols, data propagation and verification mechanisms, access authentication mechanisms, and business entity identity management.

[0138] Among them, the P2P network protocol enables communication between nodes 210 in the blockchain network 200, the data propagation mechanism ensures the propagation of transactions in the blockchain network 200, the data verification mechanism is used to ensure the reliability of data transmission between nodes 210 based on cryptographic methods (such as digital certificates, digital signatures, public / private key pairs), the access authentication mechanism is used to authenticate the identity of business entities joining the blockchain network 200 according to the actual business scenario, and grant the business entities access to the blockchain network 200 when the authentication is successful, and the business entity identity management is used to store the identity and permissions (such as the types of transactions that can be initiated) of the business entities allowed to access the blockchain network 200.

[0139] The consensus layer 202 encapsulates the mechanisms (i.e., consensus mechanisms) for nodes 210 in the blockchain network 200 to reach consensus on blocks, as well as the functions of transaction management and ledger management. The consensus mechanisms include consensus algorithms such as POS, POW, and DPOS, and support pluggable consensus algorithms.

[0140] Transaction management is used to verify the digital signature carried in the transaction received by node 210, verify the identity information of the business entity, and determine whether it has the authority to conduct the transaction based on the identity information (reading relevant information from the business entity identity management); for business entities that have been authorized to access the blockchain network 200, they all have digital certificates issued by the certification center. The business entity uses the private key in its digital certificate to sign the submitted transaction, thereby declaring its legitimate identity.

[0141] Ledger management is used to maintain the blockchain and state database. For blocks that have reached consensus, they are appended to the end of the blockchain; transactions within consensus-reaching blocks are executed. When a transaction includes an update operation, the key-value pairs in the state database are updated; when a transaction includes a query operation, the key-value pairs in the state database are queried, and the query results are returned to the client nodes of the business entity. Multiple query operations on the state database are supported, including: querying blocks based on block vector numbers (e.g., transaction hashes); querying blocks based on block hashes; querying blocks based on transaction vector numbers; querying transactions based on transaction vector numbers; querying account data of the business entity based on its account (vector number); and querying the blockchain within a channel based on its channel name.

[0142] The application layer 201 encapsulates various business functions that a blockchain network can implement, including transaction tracing, notarization, and verification.

[0143] The following uses the latency parameter collection method provided in this application on a container cloud platform as an example to illustrate the process of achieving latency parameter collection in a full-scenario online and offline mixed deployment. There are several reasons for low cluster utilization, such as: 1) excessive cluster fragmentation; 2) dedicated business clusters that cannot share resources; 3) deploying multiple replicas for disaster recovery; 4) using idle buffer resource pools for temporary expansion; 5) inaccurate user resource estimations, with request volumes exceeding actual resource usage; 6) application resource fluctuations, with users requesting resources based on peak usage times. To improve resource utilization and save on hardware cost increases from hardware expansion, timely and accurate latency parameter collection is necessary.

[0144] refer to Figure 9 , Figure 9 This is a schematic diagram of the processing procedure of the delay parameter acquisition method in an embodiment of the present invention, which specifically includes the following steps:

[0145] Step 901: Based on the usage environment information of the general execution engine, determine the hook point that matches the general execution engine.

[0146] Step 902: Mount the general execution engine at the hook point.

[0147] Step 903: When the client sends a task request to the server, different timestamp information is recorded through the general execution engine.

[0148] Step 904: Determine the delay parameters based on different timestamp information.

[0149] Step 905: Monitor the service process in the full-scene online-offline hybrid deployment scenario based on the latency parameters.

[0150] like Figure 9 As shown, after acquiring latency data using the eBPF acquisition device, the latency data serves as an important indicator of job service quality and is handed over to the mixed deployment component for comprehensive judgment. If the mixed deployment component determines that the currently acquired latency data is too high, exceeding the normally set threshold, or fluctuates significantly within a short period of time, it will impose resource restrictions and adjustments on offline jobs to ensure the service quality of online jobs.

[0151] Step 906: Adjust the cluster resource configuration based on the service process monitoring results.

[0152] refer to Figure 10 , Figure 10This is a schematic diagram illustrating the processing effect of the latency parameter acquisition method in this embodiment of the invention. In the traditional technology, the utilization rate of the online application cluster has always been maintained at 10.500%. By adjusting the cluster resource configuration through the latency parameter acquisition method provided in this application, the CPU utilization rate of the server cluster is increased to 69.875% without expanding the hardware capacity of the server cluster, which shows that the CPU utilization rate of the server cluster has been increased by 60%.

[0153] Beneficial technical effects:

[0154] This invention obtains the usage environment information of a general execution engine; based on the usage environment information, determines a hook point matching the general execution engine; attaches the general execution engine to the hook point; when a client sends a task request to a server, the general execution engine records a first timestamp; when the server sends a task processing result to the client, the general execution engine records a second timestamp; based on the first and second timestamps, the latency parameters of the general execution engine's usage environment are determined. This not only enables timely and accurate acquisition of latency parameters for monitoring the task processing quality of online service processes, but also avoids intruding into the business processing flow, minimizing the impact on task execution.

[0155] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for acquiring time delay parameters, characterized in that, The method includes: Obtain usage environment information for the general execution engine; Based on the usage environment information of the general execution engine, determine the hook points that match the general execution engine; The general execution engine is mounted at the hook point; When a client sends a task request to the server, a filtering condition matching the task request is determined; the task request is filtered using the filtering condition to obtain filtered task request information; the filtered task request is then sent to the server via the general execution engine, and a first timestamp corresponding to the filtered task request is recorded. When the server sends the task processing result to the client, it records the second timestamp information through the general execution engine; Based on the first timestamp information and the second timestamp information, the latency parameters of the usage environment of the general execution engine are determined.

2. The method according to claim 1, characterized in that, The process of attaching the general execution engine at the hook point includes: Determine the configuration information of the general execution engine; Based on the configuration information of the general execution engine, determine the probe code corresponding to the function call path of the general execution engine; Based on the detection code, configure the corresponding data storage structure for the general execution engine.

3. The method according to claim 1, characterized in that, The method further includes: User-mode application processes obtain latency parameters and interface address information of the general execution engine's usage environment from the ring buffer area of ​​the general execution engine; Based on the latency parameters and interface address information of the usage environment of the general execution engine, the online service quality of the server is evaluated.

4. The method according to claim 3, characterized in that, The online service quality of the server is evaluated based on the latency parameters and interface address information of the usage environment of the general execution engine, including: Based on the latency parameters and interface address information of the usage environment of the general execution engine, it is determined whether the idle node resources in the cluster resources meet the needs of the task to be processed. When the idle node resources in the cluster resources meet the task to be processed, the task to be processed is processed through the idle node resources. When the idle node resources in the cluster are insufficient to meet the task to be processed, the corresponding idle node resources are selected based on the latency parameters of the usage environment of the general execution engine.

5. The method according to claim 4, characterized in that, The method further includes: The task to be processed is parsed to obtain its priority identifier; The priorities of the received tasks to be processed are sorted according to their priority identifiers. Based on the priority of the tasks to be processed, a corresponding queue of tasks to be processed is created.

6. The method according to claim 5, characterized in that, The method further includes: Iterate through the queue of tasks to be processed and determine the task with the highest priority. Determine the link quality of each link in the network resources; Configure the highest priority pending task with the highest quality link in the network resources so that the pending tasks in the pending task queue can be processed through the configured link.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The general execution engine identifier, first timestamp information, second timestamp information, and latency parameters are sent to the blockchain network to enable... The nodes of the blockchain network fill the new block with the general execution engine identifier, the first timestamp information, the second timestamp information, and the latency parameters, and when there is consensus on the new block, the new block is appended to the end of the blockchain.

8. The method according to claim 7, characterized in that, The method further includes: Receive data synchronization requests from other nodes in the blockchain network; In response to the data synchronization request, the permissions of the other nodes are verified; When the permissions of the other nodes are verified, the current node is controlled to synchronize data with the other nodes, so that the other nodes can obtain the general execution engine identifier, the first timestamp information, the second timestamp information, and the latency parameters.

9. The method according to claim 7, characterized in that, The method further includes: In response to a query request, the query request is parsed to obtain the corresponding object identifier; Based on the object identifier, obtain the permission information within the target block in the blockchain network; The matching between the permission information and the object identifier is verified; When the permission information matches the object identifier, the corresponding general execution engine identifier, first timestamp information, second timestamp information, and latency parameters are obtained from the blockchain network. In response to the query command, the obtained resource transaction data and the target objects matching the filtering conditions are pushed to the corresponding video playback client so that the client can obtain the corresponding general execution engine identifier, first timestamp information, second timestamp information and latency parameters stored in the blockchain network.

10. A time delay parameter acquisition device, characterized in that, The device includes: The information transmission module is used to obtain the usage environment information of the general execution engine; The information processing module is used to determine the hook point that matches the general execution engine based on the usage environment information of the general execution engine; The information processing module is used to mount the general execution engine at the hook point; The information processing module is used to determine the filtering conditions that match the task request information when the client sends task request information to the server; filter the task request information according to the filtering conditions that match the task request information to obtain filtered task request information; send the filtered task request information to the server through the general execution engine, and record the first timestamp information corresponding to the filtered task request information. The information processing module is used to record a second timestamp information through the general execution engine when the server sends the task processing result to the client. The information processing module is used to determine the latency parameters of the usage environment of the general execution engine based on the first timestamp information and the second timestamp information.

11. The apparatus according to claim 10, characterized in that, The information processing module is used to determine the configuration information of the general execution engine; The information processing module is used to determine the probe code corresponding to the function call path of the general execution engine based on the configuration information of the general execution engine; The information processing module is used to configure the corresponding data storage structure for the general execution engine based on the detection code.

12. The apparatus according to claim 10, characterized in that, The information processing module is used for user-mode application processes to obtain latency parameters and interface address information of the general execution engine's usage environment from the ring buffer area of ​​the general execution engine. The information processing module is used to evaluate the online service quality of the server based on the latency parameters and interface address information of the usage environment of the general execution engine.

13. The apparatus according to claim 12, characterized in that, The information processing module is used to determine whether the idle node resources in the cluster resources meet the tasks to be processed by using the latency parameters and interface address information of the usage environment of the general execution engine. The information processing module is used to process the task to be processed through the idle node resources when the idle node resources in the cluster resources meet the task to be processed. The information processing module is used to select the corresponding idle node resources based on the latency parameters of the usage environment of the general execution engine when the idle node resources in the cluster resources do not meet the task to be processed.

14. The apparatus according to claim 13, characterized in that, The information processing module is used to parse the task to be processed and obtain the priority identifier of the task to be processed. The information processing module is used to sort the priorities of the received tasks according to their priority identifiers. The information processing module is used to create a corresponding queue of tasks to be processed based on the priority of the tasks to be processed.

15. The apparatus according to claim 14, characterized in that, The information processing module is used to traverse the queue of tasks to be processed and determine the task with the highest priority to be processed. The information processing module is used to determine the link quality of each link in the network resources; The information processing module is configured to configure the highest quality link in the network resources for the highest priority task to be processed, so as to process the tasks in the task queue through the configured link.

16. The apparatus according to any one of claims 10 to 15, characterized in that, The information processing module is used to send the general execution engine identifier, first timestamp information, second timestamp information, and delay parameters to the blockchain network, so that the nodes of the blockchain network fill the general execution engine identifier, first timestamp information, second timestamp information, and delay parameters into a new block, and when there is consensus on the new block, append the new block to the end of the blockchain.

17. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable instructions; The processor, when executing executable instructions stored in the memory, implements the delay parameter acquisition method according to any one of claims 1 to 9.

18. A computer-readable storage medium storing executable instructions, characterized in that, When the executable instructions are executed by the processor, they implement the delay parameter acquisition method according to any one of claims 1 to 9.

Images