Delay determination method, computing device and computer program product

Abstract

The embodiment of the invention provides a time delay determination method, computing equipment and a computer storage medium. The time delay determination method is applied to a kernel mode, and comprises the following steps: receiving a task processing request; calling at least two processing components to process the task processing request; and calling a time delay determination program running in the kernel mode, reading a task processing log, and determining time delay data respectively generated when the at least two processing components process the task processing request by utilizing timestamps recorded by the task processing log. According to the technical scheme provided by the embodiment of the invention, the time delay data of the plurality of processing components involved in the processing process of the task processing request can be respectively determined, so that the time delay of the kernel during task processing can be determined in a fine-grained manner.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technologies, and in particular, to a method for determining time delay, a computing device, and a computer storage medium. Background Art

[0002] Time delay may refer to the time consumed from receiving a task processing request to completing the processing of the task processing request.

[0003] In related technologies, usually, the time delay of this task processing is measured by separately recording the timestamps when the task processing request is received and when the processing of the task processing request is completed.

[0004] In the process of implementing the inventive concept of the present invention, the inventors found that the time delay measurement method in related technologies can only determine the total time delay when processing a task processing request. However, when the kernel mode receives a task processing request from an application program and processes the task processing request, it often needs to call multiple processing components for processing. For example, it needs to call a network component to implement data transmission and network communication functions, call a storage component to provide functions such as reading, writing, and access control of files, call a lock to protect shared resources and prevent multiple threads from accessing and modifying shared resources simultaneously, and so on.

[0005] In the process of implementing the inventive concept of the present invention, the inventors found that when performing time delay analysis currently, it is not only necessary to determine the total time delay of task processing, but also necessary to determine the distribution of the total time delay among each processing component. Summary of the Invention

[0006] Embodiments of the present invention provide a method for determining time delay, an apparatus, a computing device, and a computer storage medium.

[0007] In a first aspect, an embodiment of the present invention provides a method for determining time delay, which is applied to the kernel mode. The method includes:

[0008] Receiving a task processing request;

[0009] In the kernel mode, processing the task processing request, where at least two processing components are called by the kernel mode to process the task processing request;

[0010] Calling a time delay determination program running in the kernel mode, reading task processing logs, and using the timestamps recorded in the task processing logs to determine the time delay data respectively generated by the at least two processing components when processing the task processing request.

[0011] In a second aspect, an embodiment of the present invention provides a method for determining time delay, which is applied to a time delay determination program. The method includes:

[0012] Receive the latency determination instruction sent by the kernel mode. The latency determination instruction is generated after the kernel mode receives a task processing request and invokes at least two processing components to process the task processing request.

[0013] In response to the latency determination instruction, read the task processing log, and use the timestamps recorded in the task processing log to determine the latency data respectively generated by the at least two processing components when processing the task processing request.

[0014] In a third aspect, an embodiment of the present invention provides a latency determination method, which is applied to an application program. The method includes:

[0015] Receive a task processing instruction, where the task processing instruction is used to instruct the application program to perform task processing.

[0016] In response to the task processing instruction, generate a task processing request, and send the task processing request to the kernel mode, so that after the kernel mode receives the task processing request, it invokes at least two processing components to process the task processing request, and invokes a latency determination program running in the kernel mode to read the task processing log, and use the timestamps recorded in the task processing log to determine the latency data respectively generated by the at least two processing components when processing the task processing request.

[0017] In a fourth aspect, an embodiment of the present invention provides a latency determination device, which is applied to the kernel mode. The device includes:

[0018] A request receiving module, configured to receive a task processing request.

[0019] A task processing module, configured to process the task processing request in the kernel mode, where the kernel mode invokes at least two processing components to process the task processing request.

[0020] A latency determination module, configured to invoke a latency determination program running in the kernel mode, read the task processing log, and use the timestamps recorded in the task processing log to determine the latency data respectively generated by the at least two processing components when processing the task processing request.

[0021] In a fifth aspect, an embodiment of the present invention provides a latency determination device, which is applied to the latency determination program. The device includes:

[0022] A first instruction receiving module, configured to receive the latency determination instruction sent by the kernel mode. The latency determination instruction is generated after the kernel mode receives a task processing request and invokes at least two processing components to process the task processing request.

[0023] A log reading module, configured to read a task processing log in response to the latency determination instruction, and determine the latency data respectively generated by the at least two processing components when processing the task processing request by using the timestamps recorded in the task processing log.

[0024] In a sixth aspect, an embodiment of the present invention provides a latency determination device, which is applied to an application program. The device includes:

[0025] A second instruction receiving module, configured to receive a task processing instruction, where the task processing instruction is used to instruct the application program to perform task processing;

[0026] A request generating module, configured to generate a task processing request in response to the task processing instruction, and send the task processing request to the kernel mode, so that after receiving the task processing request, the kernel mode calls at least two processing components to process the task processing request, and calls a latency determination program running in the kernel mode to read a task processing log, and determine the latency data respectively generated by the at least two processing components when processing the task processing request by using the timestamps recorded in the task processing log.

[0027] In a seventh aspect, an embodiment of the present invention provides a computing device, including a processing component and a storage component;

[0028] The storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement the latency determination method provided by the embodiment of the present invention

[0029] In an eighth aspect, an embodiment of the present invention provides a computer storage medium, storing a computer program, where when the computer program is executed by a computer, the latency determination method provided by the embodiment of the present invention is implemented.

[0030] In a ninth aspect, an embodiment of the present invention provides a computer program product, including a computer program, where when the computer program is executed by a processor, the latency determination method provided by the embodiment of the present invention is implemented.

[0031] An embodiment of the present invention provides a latency determination method, which adopts the following technical solutions: receiving a task processing request; processing the task processing request in the kernel mode, where the kernel mode calls at least two processing components to process the task processing request; calling a latency determination program running in the kernel mode to read a task processing log, and determining the latency data respectively generated by the at least two processing components when processing the task processing request by using the timestamps recorded in the task processing log. By adopting this technical solution, the latency data of multiple processing components involved in the processing process of the task processing request can be determined respectively, so that the latency of the kernel when performing task processing can be determined in a fine-grained manner.

[0032] These aspects or other aspects of the present invention will be more clearly understood in the following description of the embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0034] Figure 1 The flowchart of a method for determining time delay provided by an embodiment of the present invention is schematically shown;

[0035] Figure 2 The schematic diagram of the method for determining time delay provided by an embodiment of the present invention is schematically shown;

[0036] Figure 3 The flowchart of a method for determining time delay provided by another embodiment of the present invention is schematically shown;

[0037] Figure 4 The flowchart of a method for determining time delay provided by another embodiment of the present invention is schematically shown;

[0038] Figure 5 The block diagram of a device for determining time delay provided by an embodiment of the present invention is schematically shown;

[0039] Figure 6 The block diagram of a device for determining time delay provided by another embodiment of the present invention is schematically shown;

[0040] Figure 7 The block diagram of a device for determining time delay provided by another embodiment of the present invention is schematically shown;

[0041] Figure 8 The block diagram of a computing device provided by an embodiment of the present invention is schematically shown. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0042] In order to enable those skilled in the art to better understand the solutions of the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention.

[0043] In some of the processes described in the specification, claims, and above-mentioned drawings of the present invention, a plurality of operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order in which they appear herein or may be executed in parallel. The operation numbers such as 101 and 102 are only used to distinguish different operations, and the numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions such as "first" and "second" herein are used to distinguish different messages, devices, modules, etc., do not represent a sequence, and do not limit that "first" and "second" are of different types.

[0044] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present invention are all information and data authorized by the user or fully authorized by all parties. And the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0045] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of the present invention.

[0046] Figure 1 A flowchart of a method for determining delay provided by an embodiment of the present invention is schematically shown. The method for determining delay can be applied to the kernel state, such as Figure 1 shown, the method for determining delay may specifically include the following steps:

[0047] 101, receiving a task processing request;

[0048] 102, calling at least two processing components to process the task processing request;

[0049] 103, calling a delay determination program running in the kernel state, reading the task processing log, and using the timestamps recorded in the task processing log to determine the delay data respectively generated by at least two processing components when processing the task processing request.

[0050] In an embodiment of the present invention, the kernel mode is a part of the operating system and has full access rights to system resources. The kernel is responsible for managing the system's hardware and software resources, providing control and management of peripherals, memory, process scheduling, file systems, etc. The code running in kernel mode is usually a component of the operating system kernel, and these codes perform system-level tasks and interact directly with the hardware.

[0051] An application is a software program written by a user or developer to perform specific tasks or provide specific functions. Applications run in user mode with lower privileges and restrictions on accessing system resources. They communicate with the operating system through application programming interfaces (APIs) to access underlying hardware and perform system-level tasks.

[0052] Applications usually require services and resources provided by the operating system to complete various tasks, such as file reading and writing, network communication, memory management, etc. When an application needs to perform these tasks, it makes a system call (syscall), transferring control to the kernel mode. After receiving the system call, the kernel will perform corresponding operations according to the type and parameters of the requested task and return the result to the application.

[0053] When the kernel mode processes task processing requests from applications, it usually needs to mobilize multiple processing components. Processing component tasks can include, for example, network components, storage components, locks, etc.

[0054] For example, the kernel usually needs to call network protocol stack components, which are responsible for handling network layer, transport layer, and application layer protocols to implement data transmission and network communication functions. For example, the TCP / IP protocol stack is a common network component that is responsible for handling TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) protocols to achieve reliable data transmission and network connection management.

[0055] The kernel may also usually need to call storage components such as file systems and block device drivers. The file system is responsible for managing files and directories, providing functions such as file reading and writing and access control. The block device driver is responsible for managing disks and other block devices, providing functions such as data reading and writing and device control.

[0056] The kernel needs to call synchronization primitive components such as semaphores, mutexes, and read-write locks. These components are used to protect shared resources, prevent multiple threads from accessing and modifying shared resources simultaneously, and thus avoid problems such as data competition and deadlocks.

[0057] According to an embodiment of the present invention, a latency determination program can be injected into the kernel of an operating system by means of code injection to determine the latency data of multiple processing components in the kernel state.

[0058] In some embodiments, the latency determination program can be implemented as an Extended Berkeley Packet Filter (eBPF). Among them, code injection can be a technique for inserting and running independent code into a target process. Using eBPF, it is possible to introduce new functions into the kernel without modifying the kernel code. The basic idea of eBPF is to load the BPF bytecode provided by the user (i.e., the eBPF program) into the kernel so that the kernel can receive and process these programs. These programs can intercept various events in the kernel (such as network packets, system calls, signals, etc.), and can use the APIs provided by the kernel to access system resources (such as memory, file system, etc.). In the embodiment of the present invention, the function of separately counting the processing latency of each processing component is introduced into the kernel through eBPF.

[0059] According to an embodiment of the present invention, after the latency determination program is injected into the kernel of the operating system, it can identify and track the process of the kernel processing requests according to the preset processing logic and custom functions, and record the processing time.

[0060] According to an embodiment of the present invention, the processing timestamp of a task by the kernel can be determined by the processing time of each function for processing the task in the kernel.

[0061] The task processing log can record information such as timestamps, request types, and identifiers of processing components.

[0062] After the latency determination program reads the task processing log, it can respectively determine the time point when each processing component starts to process the request and the time point when the request is completed, and then the latency data of each processing component when processing the task processing request can be calculated respectively.

[0063] The latency data can be calculated by the following formula:

[0064] Latency data = completion time point - start time point.

[0065] According to an embodiment of the present invention, in the kernel state, the processing of task processing requests can be specifically implemented as:

[0066] In response to receiving a task processing request, scheduling the task processing request to the central processing unit;

[0067] When it is determined that a task processing request needs to call a task processing component during the process of the central processing unit handling the task processing request, the task processing request is scheduled to at least two processing components respectively, so as to utilize the at least two processing components to assist the central processing unit in handling the task processing request.

[0068] According to an embodiment of the present invention, after the kernel mode receives a task processing request, it usually schedules the task processing request to the central processing unit for processing. When the task processing request is being executed by the central processing unit instead of being in a waiting or blocked state, the task processing request is in the On CPU state.

[0069] During the process of the central processing unit handling the task processing request, it often needs to call other processing components to handle the task processing request. At this time, the central processing unit suspends the task processing request and schedules the task processing request to the required processing component so that the processing component can continue to handle the task processing request. In this case, the task processing request can be considered to be in the Off CPU state.

[0070] Figure 2 A schematic diagram showing the method for determining delay provided by an embodiment of the present invention is schematically shown.

[0071] As Figure 2 shown, 201 may represent a time slice of the central processing unit, and this time slice is allocated to the task processing request to process the task processing request.

[0072] At time period 2011 of time slice 201, the task processing request is in the On CPU state, that is, the task processing request is being executed by the central processing unit. At time point 2012, it is monitored that a network protocol stack component needs to be called to implement data transmission and network communication functions. At this time, the task processing request can be suspended, so that the task processing request is in the Off CPU state, and the task processing request is scheduled to the network protocol stack component 202. At time period 2013, the task processing component is executed by the network protocol stack component 202. At this time, time period 2013 is the delay data of the network protocol stack.

[0073] After the network protocol stack 202 finishes executing the task processing request, at time period 2024, the task processing request is scheduled back to the central processing unit for execution. At this time, the task processing request switches from the Off CPU state back to the On CPU state.

[0074] According to an embodiment of the present invention, the method for determining delay further includes:

[0075] Recording each scheduling operation to generate a task processing log.

[0076] According to an embodiment of the present invention, the scheduling operation may include the operation of transferring a task processing request away from the current processing component each time. For example, it is scheduled from the central processing unit to the network component, from the network component to the storage component, from the storage component to the central processing unit, etc.

[0077] According to an embodiment of the present invention, recording each scheduling operation to generate a task processing log can be specifically implemented as follows:

[0078] Record the timestamp of each scheduling operation and the scheduling direction, where the scheduling direction is used to represent the scheduling order of the task processing request between different processing components;

[0079] Generate a task processing log based on the timestamp and the scheduling direction.

[0080] According to an embodiment of the present invention, the task processing log may include, for example, the following log: 202311291625, processing component A, processing component B. This log may indicate that at the timestamp 202311291625, the task processing request was scheduled from processing component A to processing component B. The scheduling from processing component A to processing component B can be the scheduling direction.

[0081] According to an embodiment of the present invention, determining the latency data respectively generated by at least two processing components when processing a task processing request by using the timestamp recorded in the task processing log can be specifically implemented as follows:

[0082] Read the task processing log to determine the timestamp and the scheduling direction corresponding to each scheduling operation;

[0083] Determine the latency data of each processing component according to the timestamps corresponding to two adjacent scheduling operations respectively and the scheduling direction.

[0084] According to an embodiment of the present invention, the processing latency of a processing component can be determined according to the timestamp when the task processing request is scheduled to a certain processing component and the timestamp when it is transferred away from the processing component.

[0085] According to an embodiment of the present invention, the task processing log may include, for example, the following log A: 202311291625, processing component A, processing component B. This log may indicate that at the timestamp 202311291625, the task processing request was scheduled from processing component A to processing component B. It also includes the following log B: 202311291626, processing component B, processing component C. This log may indicate that at the timestamp 202311291626, the task processing request was scheduled from processing component B to processing component C.

[0086] From the above two adjacent schedules, it can be known that at timestamp 202311291625, the task processing request was scheduled to processing component B, and at timestamp 202311291626, the task processing request was removed from processing component B. Then, the difference between these two timestamps is the time consumed by processing component B when processing the task processing request, which is the latency data of processing component B.

[0087] According to an embodiment of the present invention, the latency determination method further includes:

[0088] Receiving a latency determination instruction, where the latency determination instruction carries an application identifier of the application to be determined;

[0089] After receiving a task processing request, the latency determination method further includes:

[0090] Determining the target application for which the task processing request is directed;

[0091] In the case where the target application matches the application identifier, the processing latency of the kernel state for the task processing request is statistically analyzed.

[0092] According to an embodiment of the present invention, in a multi-task operating system, multiple application programs can run on the same kernel. However, there is no latency determination requirement for all application programs.

[0093] Therefore, before performing latency determination, a latency determination instruction can be received first. The latency determination instruction is used to indicate which application program running on the kernel to determine the latency data for. Specifically, the latency determination instruction can carry an application identifier, which is used to identify at least one application to be determined running on the kernel.

[0094] After the kernel receives the latency determination instruction, it can detect the application to be determined indicated by the application identifier. When a task processing request from the application to be determined is detected, the latency data generated by each processing component when processing the task processing request is statistically analyzed in the kernel state.

[0095] According to an embodiment of the present invention, the latency determination method further includes:

[0096] Obtaining a latency analysis request, where the latency analysis request includes the component identifiers of at least one processing component;

[0097] Based on the component identifiers, the latency data corresponding to the processing components corresponding to the component identifiers is filtered out from the latency determination results of the latency determination component, and a latency analysis log is generated.

[0098] According to an embodiment of the present invention, a user can submit a latency analysis request through a system interface or a command-line tool. The request includes the component identifiers of the processing components for which latency analysis is required.

[0099] According to an embodiment of the present invention, the component identifier submitted by a user through a system interface or a command-line tool may be the component identifier of a processing component for which the user expects to perform latency analysis.

[0100] According to an embodiment of the present invention, after obtaining the component identifiers of at least one processing component by parsing a latency analysis request, the component identifiers may be matched with the processing components included in the latency determination result, so as to determine at least one processing component that matches the component identifier from the latency determination result, and the latency data corresponding to the at least one processing component.

[0101] According to an embodiment of the present invention, the latency statistics instruction also carries a latency statistics time;

[0102] According to an embodiment of the present invention, the latency determination method further includes:

[0103] During the time period indicated by the latency statistics time, the processing latency of the kernel state for task processing requests is statistically analyzed.

[0104] According to an embodiment of the present invention, through the latency statistics time carried in the latency statistics instruction, the time period for latency statistics can be defined, and this time period may be a period of time starting from system startup, or a time period when a specific event or person occurs.

[0105] According to an embodiment of the present invention, through the latency statistics time, the statistics of task processing latency can be flexibly performed within a specified time period.

[0106] Figure 3 Schematically shows a flowchart of a latency determination method provided by another embodiment of the present invention, and this latency determination method can be applied to a latency determination program, such as Figure 3 As shown, the latency determination method may specifically include the following steps:

[0107] 301. Receive a latency determination request sent by the kernel state, where the latency determination request is generated after the kernel state receives a task processing request and invokes at least two processing components to process the task processing request;

[0108] 302. In response to the latency determination instruction, read the task processing log, and use the timestamps recorded in the task processing log to determine the latency data respectively generated by at least two processing components when processing the task processing request.

[0109] In an embodiment of the present invention, the kernel mode is a part of the operating system and has full access rights to system resources. The kernel is responsible for managing the system's hardware and software resources, providing control and management of peripherals, memory, process scheduling, file systems, etc. The code running in the kernel mode is usually a component of the operating system kernel, and these codes execute system-level tasks and directly interact with the hardware.

[0110] An application is a software program written by a user or developer to perform specific tasks or provide specific functions. Applications run in the user mode with lower privileges and restrictions on accessing system resources. They communicate with the operating system through application programming interfaces (APIs) to access underlying hardware and execute system-level tasks.

[0111] Applications usually require services and resources provided by the operating system to complete various tasks, such as file reading and writing, network communication, memory management, etc. When an application needs to perform these tasks, it issues a system call (syscall), transferring control to the kernel mode. After receiving the system call, the kernel will perform corresponding operations according to the type and parameters of the requested task and return the result to the application.

[0112] When the kernel mode processes task processing requests from applications, it usually needs to mobilize multiple processing components. Processing component tasks can include, for example, network components, storage components, locks, etc.

[0113] For example, the kernel usually needs to call network protocol stack components, which are responsible for processing network layer, transport layer, and application layer protocols to implement data transmission and network communication functions. For example, the TCP / IP protocol stack is a common network component that is responsible for processing TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) protocols to achieve reliable data transmission and network connection management.

[0114] The kernel may also usually need to call storage components such as file systems and block device drivers. The file system is responsible for managing files and directories, providing functions such as file reading, writing, and access control. The block device driver is responsible for managing disks and other block devices, providing functions such as data reading, writing, and device control.

[0115] The kernel needs to call synchronization primitive components such as semaphores, mutexes, and read-write locks, etc. These components are used to protect shared resources, prevent multiple threads from accessing and modifying shared resources simultaneously, and thus avoid problems such as data competition and deadlocks.

[0116] According to an embodiment of the present invention, a latency determination program can be injected into the kernel of an operating system by means of code injection to realize the determination of latency data of multiple processing components in the kernel state.

[0117] In some embodiments, the latency determination program can be implemented as an Extended Berkeley Packet Filter (eBPF). Among them, code injection can be a technique for inserting and running independent code into a target process. With eBPF, it is possible to introduce new functions to the kernel without modifying the kernel code. The basic idea of eBPF is to load the BPF bytecode (i.e., the eBPF program) provided by the user into the kernel so that the kernel can receive and process these programs. These programs can intercept various events (such as network packets, system calls, signals, etc.) in the kernel and can use the APIs provided by the kernel to access system resources (such as memory, file system, etc.). In the embodiments of the present invention, the function of separately counting the processing latency of each processing component is introduced into the kernel through eBPF.

[0118] According to an embodiment of the present invention, after the latency determination program is injected into the kernel of the operating system, it can identify and track the process of the kernel processing requests according to the preset processing logic and custom functions, and record the processing time.

[0119] According to an embodiment of the present invention, the processing timestamp of a task by the kernel can be determined by the processing times of the various functions for processing the task in the kernel.

[0120] Information such as timestamps, request types, and identifiers of processing components can be recorded in the task processing log.

[0121] After the latency determination program reads the task processing log, it can respectively determine the time point when each processing component starts to process the request and the time point when the request is completed, and then the latency data of each processing component when processing the task processing request can be calculated respectively.

[0122] The latency data can be calculated by the following formula:

[0123] Latency data = completion time point - start time point.

[0124] Figure 4 Schematically shows a flowchart of a latency determination method provided by another embodiment of the present invention. It is characterized in that the latency determination method can be applied to an application program, such as Figure 4 As shown, the latency determination method can specifically include the following steps:

[0125] 401. Receive a task processing instruction, where the task processing instruction is used to instruct the application program to perform task processing;

[0126] 402. In response to a task processing instruction, generate a task processing request and send the task processing request to the kernel mode, so that after receiving the task processing request, the kernel mode calls at least two processing components to process the task processing request, and calls a latency determination program running in the kernel mode to read the task processing log, and uses the timestamps recorded in the task processing log to determine the latency data respectively generated by the at least two processing components when processing the task processing request.

[0127] An application is a software program written by a user or developer to perform specific tasks or provide specific functions. Applications run in user mode with lower privileges and restrictions on accessing system resources. They communicate with the operating system through application programming interfaces (APIs) to access underlying hardware and perform system-level tasks.

[0128] Applications usually require services and resources provided by the operating system to complete various tasks, such as file reading and writing, network communication, memory management, etc. When an application needs to perform these tasks, it issues a system call (syscall), transferring control to the kernel mode. After receiving the system call, the kernel performs corresponding operations according to the type and parameters of the requested task and returns the result to the application.

[0129] In an embodiment of the present invention, the kernel mode is a part of the operating system and has full access rights to system resources. The kernel is responsible for managing the hardware and software resources of the system, providing control and management of peripherals, memory, process scheduling, file systems, etc. The code running in the kernel mode is usually a component of the operating system kernel, and these codes perform system-level tasks and interact directly with the hardware.

[0130] When the kernel mode processes a task processing request from an application, it usually needs to mobilize multiple processing components. Processing component tasks can include, for example, network components, storage components, locks, and so on.

[0131] For example, the kernel usually needs to call network protocol stack components, which are responsible for processing network layer, transport layer, and application layer protocols to implement data transmission and network communication functions. For example, the TCP / IP protocol stack is a common network component that is responsible for processing TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) protocols to achieve reliable data transmission and network connection management.

[0132] The kernel may also typically need to call storage components such as file systems and block device drivers. The file system is responsible for managing files and directories and provides functions such as reading, writing, and access control of files. The block device driver is responsible for managing disks and other block devices and provides functions such as reading, writing, and device control of data.

[0133] The kernel needs to call synchronization primitive components such as semaphores, mutexes, and read-write locks. These components are used to protect shared resources and prevent multiple threads from accessing and modifying shared resources simultaneously, thus avoiding problems such as data races and deadlocks.

[0134] According to an embodiment of the present invention, a latency determination program can be injected into the kernel of an operating system by code injection to implement the determination of latency data of multiple processing components in the kernel state.

[0135] In some embodiments, the latency determination program can be implemented as an Extended Berkeley Packet Filter (eBPF). Among them, code injection can be a technique for inserting independent running code into a target process and making it run. Using eBPF, it is possible to introduce new functions into the kernel without modifying the kernel code. The basic idea of eBPF is to load the BPF bytecode provided by the user (i.e., the eBPF program) into the kernel so that the kernel can receive and process these programs. These programs can intercept various events in the kernel (such as network packets, system calls, signals, etc.) and can use the APIs provided by the kernel to access system resources (such as memory, file system, etc.). In the embodiment of the present invention, that is, the function of separately counting the processing latency of each processing component is introduced into the kernel through eBPF.

[0136] According to an embodiment of the present invention, after the latency determination program is injected into the kernel of the operating system, it can identify and track the process of the kernel processing requests according to the preset processing logic and custom functions, and record the processing time.

[0137] According to an embodiment of the present invention, the processing timestamp of a task by the kernel can be determined by the processing time of each function for processing the task in the kernel.

[0138] Information such as timestamps, request types, and identifiers of processing components can be recorded in the task processing log.

[0139] After the latency determination program reads the task processing log, it can respectively determine the time point when each processing component starts to process the request and the time point when the request is completed, and then the latency data of each processing component when processing the task processing request can be calculated respectively.

[0140] The latency data can be calculated by the following formula:

[0141] Latency data = Completion time point - Start time point.

[0142] Figure 5 Schematically shows a block diagram of a latency determination device provided by an embodiment of the present invention. The latency determination device 500 can be applied to the kernel mode, such as Figure 5 as shown, the latency determination device may specifically include:

[0143] A request receiving module 501, configured to receive a task processing request;

[0144] A task processing module 502, configured to call at least two processing components to process the task processing request;

[0145] A latency determination module 503, configured to call a latency determination program running in the kernel mode, read the task processing log, and use the timestamps recorded in the task processing log to determine the latency data respectively generated by at least two processing components when processing the task processing request.

[0146] According to an embodiment of the present invention, the task processing module 502 includes:

[0147] A first task scheduling sub-module, configured to, in response to receiving a task processing request, schedule the task processing request to a central processing unit;

[0148] A second task scheduling sub-module, configured to, when it is determined that the central processing unit needs to call a task processing component during the process of processing the task processing request, schedule the task processing request to at least two processing components respectively, so as to use the at least two processing components to assist the central processing unit in processing the task processing request.

[0149] According to an embodiment of the present invention, the latency determination device 500 further includes:

[0150] A recording module, configured to record each scheduling operation and generate a task processing log.

[0151] According to an embodiment of the present invention, the recording module includes:

[0152] A recording unit, configured to record the timestamp of each scheduling operation and the scheduling direction, and the scheduling direction is used to represent the scheduling order of the task processing request between different processing components;

[0153] A log generation unit, configured to generate a task processing log according to the timestamp and the scheduling direction.

[0154] According to an embodiment of the present invention, the latency determination module 503 includes:

[0155] A log reading unit for reading task processing logs and determining the time stamp and scheduling direction corresponding to each scheduling operation;

[0156] A latency determination unit for determining the latency data of each processing component according to the time stamps corresponding to two adjacent scheduling operations and the scheduling direction.

[0157] According to an embodiment of the present invention, the latency determination device 500 further includes:

[0158] An instruction receiving module for receiving a latency determination instruction, where the latency determination instruction carries an application identifier of an application to be determined.

[0159] According to an embodiment of the present invention, the request receiving module 501 includes:

[0160] An application determination sub-module for determining a target application targeted by a task processing request;

[0161] A matching sub-module for statistically analyzing the processing latency of the kernel state for the task processing request when the target application matches the application identifier.

[0162] According to an embodiment of the present invention, the latency determination device 500 further includes:

[0163] An analysis request acquisition module for acquiring a latency analysis request, where the latency analysis request includes component identifiers of at least one processing component;

[0164] A screening module for screening out the latency data corresponding to the processing component corresponding to the component identifier from the latency determination results of the latency determination component based on the component identifier, and generating a latency analysis log.

[0165] According to an embodiment of the present invention, the latency statistics instruction further carries a latency statistics time.

[0166] According to an embodiment of the present invention, the latency determination device 500 further includes:

[0167] A time determination module for statistically analyzing the processing latency of the kernel state for the task processing request within the time period indicated by the latency statistics time.

[0168] Figure 5 The latency determination device can execute Figure 1 The latency determination method of the embodiment shown, and its implementation principle and technical effects will not be elaborated. For the latency determination device in the above embodiment, the specific manners in which each module and unit perform operations have been described in detail in the embodiment related to the method, and will not be elaborated here.

[0169] Figure 6Schematically shown is a block diagram of a latency determination device provided in another embodiment of the present invention. This latency determination device can be applied to a latency determination program, such as Figure 6 As shown, the latency determination device 600 may include:

[0170] A first instruction receiving module 601, configured to receive a latency determination request sent by the kernel mode. The latency determination request is generated after the kernel mode receives a task processing request and invokes at least two processing components to process the task processing request;

[0171] A log reading module 602, configured to, in response to a latency determination instruction, read a task processing log and determine latency data respectively generated by at least two processing components when processing the task processing request by using timestamps recorded in the task processing log.

[0172] Figure 6 The latency determination device can execute Figure 3 The latency determination method of the embodiment shown. Its implementation principle and technical effects will not be elaborated again. For the latency determination device in the above embodiment, the specific manners in which each module and unit perform operations have been described in detail in the embodiment related to the method, and will not be elaborated here.

[0173] Figure 7 Schematically shown is a block diagram of a latency determination device provided in another embodiment of the present invention. This latency determination device can be applied to an application program, such as Figure 7 As shown, the latency determination device 700 includes:

[0174] A second instruction receiving module 701, configured to receive a task processing instruction, where the task processing instruction is used to instruct the application program to perform task processing;

[0175] A request generation module 702, configured to, in response to the task processing instruction, generate a task processing request and send the task processing request to the kernel mode, so that after the kernel mode receives the task processing request, it invokes at least two processing components to process the task processing request, and invokes a latency determination program running in the kernel mode to read a task processing log and determine latency data respectively generated by at least two processing components when processing the task processing request by using timestamps recorded in the task processing log.

[0176] Figure 7 The latency determination device can execute Figure 4 The latency determination method described in the embodiment shown. Its implementation principle and technical effects will not be elaborated again. For the latency determination device in the above embodiment, the specific manners in which each module and unit perform operations have been described in detail in the embodiment related to the method, and will not be elaborated here.

[0177] In a possible design, the latency determination device provided by the embodiments of the present invention may be implemented as a computing device, such as Figure 8 shown, the computing device may include a storage component 801 and a processing component 802;

[0178] The storage component 801 stores one or more computer instructions, and among them, the one or more computer instructions are called and executed by the processing component 802 to implement the latency determination method provided by the embodiments of the present invention.

[0179] Of course, the computing device may also necessarily include other components, such as an input / output interface, a communication component, etc. The input / output interface provides an interface between the processing component and the peripheral interface module, and the above peripheral interface module may be an output device, an input device, etc. The communication component is configured to facilitate communication between the computing device and other devices in a wired or wireless manner, etc.

[0180] Among them, the computing device may be a physical device or an elastic computing host provided by a cloud computing platform, etc. At this time, the computing device may refer to a cloud server, and the above processing component, storage component, etc. may be basic server resources rented or purchased from a cloud computing platform.

[0181] When the computing device is a physical device, it may be implemented as a distributed cluster composed of multiple servers or terminal devices, or may be implemented as a single server or a single terminal device.

[0182] The embodiments of the present invention also provide a computer-readable storage medium storing a computer program, and when the computer program is executed by a computer, it can implement the latency determination method provided by the embodiments of the present invention.

[0183] The embodiments of the present invention also provide a computer program product including a computer program, and when the computer program is executed by a computer, it can implement the latency determination method provided by the embodiments of the present invention.

[0184] Among them, the processing component in the corresponding embodiments above may include one or more processors to execute computer instructions to complete all or part of the steps in the above method. Of course, the processing component may also be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components for executing the above method.

[0185] The storage component is configured to store various types of data to support operations in the device. The storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0186] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0187] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement it without creative work.

[0188] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the essence of the above technical solution or the part that contributes to the prior art can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0189] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments or equivalently replace some of the technical features. These modifications or replacements 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.

Claims

1. A method for determining time delay, characterized in that, Applied to the kernel mode, the method includes: Receiving a task processing request; Invoking at least two processing components to process the task processing request; Invoking a latency determination program running in the kernel mode to read the task processing log; Using the timestamps recorded in the task processing log to determine the latency data respectively generated by the at least two processing components when processing the task processing request.

2. The method according to claim 1, wherein The invoking at least two processing components to process the task processing request includes: In response to receiving the task processing request, scheduling the task processing request to the central processing unit; When it is determined that the central processing unit needs to invoke a task processing component during the process of processing the task processing request, scheduling the task processing request to the at least two processing components respectively, so as to use the at least two processing components to assist the central processing unit in processing the task processing request.

3. The method according to claim 2, wherein The method further includes: Recording each scheduling operation to generate the task processing log.

4. The method according to claim 3, characterized in that, The recording each scheduling operation to generate the task processing log includes: Recording the timestamp of each scheduling operation and the scheduling direction, where the scheduling direction is used to characterize the scheduling order of the task processing request between different processing components; Generating the task processing log according to the timestamp and the scheduling direction.

5. The method according to claim 4, wherein The using the timestamps recorded in the task processing log to determine the latency data respectively generated by the at least two processing components when processing the task processing request includes: Reading the task processing log to determine the timestamp and the scheduling direction corresponding to each scheduling operation; Determining the latency data of each processing component according to the timestamps respectively corresponding to two adjacent scheduling operations and the scheduling direction.

6. The method according to claim 1, wherein The method further includes: Receiving a latency determination instruction, where the latency determination instruction carries the application identifier of the application to be determined; After receiving the task processing request, the method further includes: Determining the target application for which the task processing request is directed; When the target application matches the application identifier, statistically analyzing the processing latency of the task processing request.

7. The method according to claim 5, characterized in that The method further includes: Obtaining a latency analysis request, where the latency analysis request includes the component identifiers of at least one processing component; Based on the component identifiers, filtering out the latency data corresponding to the processing components corresponding to the component identifiers from the latency determination results of the latency determination component to generate a latency analysis log.

8. The method according to claim 6, characterized in that, The latency statistical instruction further carries a latency statistical time; The method further includes: During the time period indicated by the latency statistical time, statistically analyzing the processing latency of the task processing request in the kernel mode.

9. A method for determining a time delay, characterized in that, Applied to a latency determination program, the method includes: Receiving a latency determination request sent by the kernel mode, where the latency determination request is generated after the kernel mode receives a task processing request and invokes at least two processing components to process the task processing request; In response to the latency determination request, reading the task processing log and using the timestamps recorded in the task processing log to determine the latency data respectively generated by the at least two processing components when processing the task processing request.

10. A method for determining time delay, characterized in that, Applied to an application program, the method includes: Receiving a task processing instruction for instructing the application program to perform task processing; In response to the task processing instruction, generating a task processing request and sending the task processing request to the kernel mode, so that after receiving the task processing request, the kernel mode invokes at least two processing components to process the task processing request, and invokes a latency determination program running in the kernel mode to read the task processing log, and determines the latency data respectively generated by the at least two processing components when processing the task processing request by using the timestamps recorded in the task processing log.

11. A time delay determination device, characterized in that, Applied to the kernel mode, the device includes: A request receiving module for receiving a task processing request; A task processing module for processing the task processing request in the kernel mode, where the kernel mode invokes at least two processing components to process the task processing request; A latency determination module for invoking a latency determination program running in the kernel mode to read the task processing log, and determining the latency data respectively generated by the at least two processing components when processing the task processing request by using the timestamps recorded in the task processing log.

12. A device for determining time delay, characterized in that Applied to the latency determination program, the device includes: A first instruction receiving module for receiving a latency determination instruction sent by the kernel mode, where the latency determination instruction is generated after the kernel mode receives a task processing request and invokes at least two processing components to process the task processing request; A log reading module for, in response to the latency determination instruction, reading the task processing log, and determining the latency data respectively generated by the at least two processing components when processing the task processing request by using the timestamps recorded in the task processing log.

13. A time delay determination device, characterized in that Applied to the application program, the device includes: A second instruction receiving module for receiving a task processing instruction for instructing the application program to perform task processing; A request generating module for, in response to the task processing instruction, generating a task processing request and sending the task processing request to the kernel mode, so that after receiving the task processing request, the kernel mode invokes at least two processing components to process the task processing request, and invokes a latency determination program running in the kernel mode to read the task processing log, and determines the latency data respectively generated by the at least two processing components when processing the task processing request by using the timestamps recorded in the task processing log.

14. A computing device, characterized in that, Including a processing component and a storage component; The storage component stores one or more computer instructions; the one or more computer instructions are used to be invoked and executed by the processing component to implement the latency determination method according to any one of claims 1 to 8, or the latency determination method according to claim 9, or the latency determination method according to claim 10.

15. A computer storage medium, characterized in that, Stored with a computer program, when the computer program is executed by a computer, it implements the latency determination method according to any one of claims 1 to 8, or the latency determination method according to claim 9, or the latency determination method according to claim 10.

16. A computer program product, characterized in that, Comprising a computer program which, when executed by a processor, implements the time delay determination method according to any one of claims 1 to 8, or the time delay determination method according to claim 9, or the time delay determination method according to claim 10.

Images