Transaction execution flow acquisition method, electronic device, storage medium and program product

Abstract

The embodiment of the present application provides a method for acquiring a transaction execution flow, an electronic device, a storage medium, and a program product, including: in response to receiving a transaction processing request of a target transaction, acquiring request metadata of the transaction processing request; in the process of processing the target transaction based on the request metadata, acquiring a system thread event and acquiring the corresponding application thread event at at least one preset event acquisition point, each application thread event including a transaction identifier; determining a target application thread event from each application thread event according to the transaction identifier; generating a transaction execution flow of the target transaction according to the system thread event and the target application thread event. In the embodiment of the present application, in the face of complex transaction processing scenarios such as asynchronous operations between threads or concurrent execution of multiple transactions, it is also possible to accurately track the transaction execution flow of each transaction, thereby ensuring the accuracy and reliability of system performance analysis.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for acquiring a transaction execution flow, an electronic device, a storage medium, and a program product. Background Art

[0002] In today's computer field, system performance is the core indicator for measuring system stability and user experience, especially in e-commerce, financial services, and online games. The quality of system performance is directly related to user experience and results. Therefore, it is particularly important to deeply analyze system performance and optimize it.

[0003] For computer transaction processing scenarios, the execution process of a transaction may need to span multiple threads. In order to implement system performance analysis of transaction processing scenarios, it is necessary to track the execution flow of transactions between threads. Currently, the execution flow of transactions can be tracked by monitoring thread events at the system level. However, when faced with asynchronous operations between threads or complex situations where multiple transactions are executed concurrently and share thread resources, tracking only through thread events at the system level cannot capture the complete execution flow of transactions, nor can it distinguish the execution flows of different transactions. Therefore, in such complex scenarios, traditional tracking methods are difficult to achieve accurate transaction tracking, which in turn affects the accuracy and reliability of performance analysis. Summary of the invention

[0004] Embodiments of the present application provide a method for acquiring a transaction execution flow, an electronic device, a storage medium, and a program product to alleviate or solve one or more technical problems existing in the prior art.

[0005] In a first aspect, an embodiment of the present application provides a method for acquiring a transaction execution flow, comprising: in response to receiving a transaction processing request of a target transaction, acquiring request metadata of the transaction processing request; in the process of processing the target transaction based on the request metadata, acquiring a system thread event and respectively acquiring an application thread event corresponding to at least one preset event acquisition point, each of the application thread events including a transaction identifier, the transaction identifier being used to identify the transaction to which the application thread event belongs, the preset event acquisition point being a plug-in position pre-inserted on the transaction execution path; determining a target application thread event from at least one of the application thread events according to the transaction identifier, the target application thread event being an application thread event belonging to the target transaction; generating a transaction execution flow of the target transaction according to each of the system thread events and the target application thread event, the transaction execution flow being used to characterize the execution process of the target transaction.

[0006] In a second aspect, an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory, and the processor implements any method of the embodiment of the present application when executing the computer program.

[0007] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, any method of the embodiment of the present application is implemented.

[0008] In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements any method of the embodiments of the present application when executed by a processor.

[0009] The method provided by the embodiment of the present application, in the process of processing the target transaction, obtains the system thread event and the application thread event corresponding to at least one preset event acquisition point, and each application thread event contains a transaction identifier for identifying the transaction to which the application thread event belongs. According to the transaction identifier, the target application thread event belonging to the target transaction can be accurately screened out from the obtained application thread events, so that in the scenario where multiple transactions are executed concurrently, the transaction execution flows of different transactions can be accurately distinguished, and the transaction execution flows of different transactions can be accurately tracked; in addition, after obtaining the target application thread event corresponding to the target transaction, by combining the system thread event and the target application thread event, the complete transaction execution flow of the asynchronous operation between threads can be accurately and comprehensively captured, which not only improves the accuracy of transaction tracking, but also enhances the reliability of performance analysis based on the transaction execution flow. Therefore, through the method provided by the embodiment of the present application, the transaction execution flow of each transaction can be accurately tracked, thereby ensuring the accuracy and reliability of system performance analysis.

[0010] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the multiple drawings represent the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments according to the present application and should not be regarded as limiting the scope of the present application.

[0012] Figure 1 One of the schematic diagrams of the transaction execution flow process is shown;

[0013] Figure 2 The second schematic diagram of the transaction execution flow process is shown;

[0014] Figure 3 The third diagram of the transaction execution flow process is shown;

[0015] Figure 4 A schematic diagram showing an application scenario of a method for obtaining a transaction execution flow provided in an embodiment of the present application is shown;

[0016] Figure 5 One of the flow diagrams of the method for obtaining a transaction execution flow provided in an embodiment of the present application is shown;

[0017] Figure 6 A schematic diagram of the data structure of a transaction processing request in a method for acquiring a transaction execution flow provided in an embodiment of the present application is shown;

[0018] Figure 7 The fourth diagram of the transaction execution flow process is shown;

[0019] Figure 8 The second flowchart of the method for obtaining the transaction execution flow provided in the embodiment of the present application is shown;

[0020] Fig. 9 A schematic diagram showing the module composition of a device for acquiring a transaction execution flow provided in an embodiment of the present application is shown;

[0021] Fig.10 A block diagram of an electronic device provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the concept or scope of the present application. Therefore, the drawings and descriptions are considered to be exemplary in nature and not restrictive.

[0023] To facilitate understanding of the technical solutions of the embodiments of the present application, the following describes the related technologies of the embodiments of the present application. The following related technologies can be combined with the technical solutions of the embodiments of the present application as optional solutions, and they all belong to the protection scope of the embodiments of the present application.

[0024] In today's computer field, system performance is the core indicator for measuring system stability and user experience, especially in e-commerce, financial services, and online games. The quality of system performance is directly related to user experience and results. Therefore, it is particularly important to deeply analyze system performance and optimize it.

[0025] Whether in a scenario where a single computer processes transactions, or in a distributed transaction processing environment where each computing node processes its assigned portion of a transaction, the execution of a transaction may need to span multiple threads. That is, the execution process of a transaction needs to be coordinated between multiple threads to ensure the integrity and consistency of the transaction. In order to implement system performance analysis in the above transaction processing scenarios, it is necessary to track the execution flow of transactions between threads.

[0026] Currently, the execution flow of transactions can be tracked by monitoring thread events at the operating system level. Figure 1 In the transaction execution flow shown in the figure, the transaction starts and ends in the input / output (I / O) thread. When the transaction starts, the I / O thread first receives the transaction processing request from the client. After the I / O thread performs preliminary processing on the transaction processing request, it passes the request after preliminary processing to the backend thread. In order to complete this step, the backend thread needs to be awakened, and the I / O thread will be scheduled out. The backend thread takes over the transaction processing request and processes it. After the processing is completed, the processing result is returned to the I / O thread. In this process, the I / O thread also needs to be awakened, and the backend thread will be scheduled out. Finally, the I / O thread feeds back the processing result to the client, marking the end of the transaction. In the entire transaction execution process, there are two execution flow transfers: one is to wake up the backend thread to receive the transaction processing request, and the other is to wake up the I / O thread to return the transaction processing result. In the above process, each transaction processing transfer is performed synchronously, and each transfer is accompanied by a thread wake-up event. Therefore, by capturing the key system thread event of thread wake-up, the transaction execution flow of the transaction can be effectively tracked.

[0027] However, in some complex transaction processing scenarios, tracing only through system-level thread events may not capture the complete transaction execution flow. Figure 2 The transaction execution flow process shown in the figure, in which the threads are transferred through asynchronous processes. Figure 2 In the transaction transfer process shown, the transaction starts with thread 1, that is, thread 1 receives a transaction processing request, partially processes the transaction processing request, and then asynchronously transfers it to thread 2. For example, thread 1 may put the transaction processing request into the work queue of thread 2, and when the trigger condition is met, thread 2 executes a check to see whether there is a transaction processing request that needs to be processed in the queue. The trigger condition may be reaching a preset event interval. During this process, thread 1 did not "notify" thread 2. Afterwards, thread 2 may asynchronously transfer the transaction processing request to thread 3 in the same way. Figure 2In the thread transfer process shown, the communication between threads is realized through message queues, rather than through system thread events such as thread wake-up and thread scheduling. Therefore, the activity of thread 2 does not trigger any system-level thread events. In other words, the existence of thread 2 cannot be perceived based on system-level thread events alone, and the complete transaction execution flow of the transaction cannot be captured.

[0028] In another transaction processing scenario, such as a complex scenario where multiple transactions are executed concurrently and share thread resources, tracing only through system-level thread events may not be able to distinguish the transaction execution flows of different transactions. Figure 3 The transaction execution flow process shown involves the I / O thread, backend thread 1, and backend thread 2, and transactions 1, 2, and 3 are executed simultaneously, and the three transactions share the I / O thread. After receiving the transaction processing requests of transactions 1, 2, and 3, the I / O thread performs preliminary processing on the transaction processing request, and transfers the processed transaction processing request to backend thread 1 or backend thread 2 for subsequent processing. In this scenario, even if the I / O thread uses a synchronous method when transferring threads to backend thread 1 and backend thread 2, the collected system thread events only indicate which thread wakes up which thread, but cannot distinguish which transaction the thread wake-up operation corresponds to, that is, different transactions cannot be distinguished based on system-level thread events alone.

[0029] Therefore, based on the above analysis, it can be seen that in complex transaction processing scenarios such as asynchronous operations between threads or multiple transactions executing concurrently and sharing thread resources, traditional tracing methods are difficult to achieve accurate transaction tracking, which in turn affects the accuracy and reliability of performance analysis.

[0030] Based on this technical problem, the embodiment of the present application provides a method for obtaining a transaction execution flow. In the process of processing a target transaction based on at least two threads, a system thread event is obtained and an application thread event corresponding to at least one preset event acquisition point is obtained respectively, and each application thread event contains a transaction identifier for identifying the transaction to which the application thread event belongs. According to the transaction identifier, the target application thread event belonging to the target transaction can be accurately screened out from the obtained application thread event, so that in the scenario where multiple transactions are executed concurrently, the transaction execution flows of different transactions can be accurately distinguished, and the transaction execution flows of different transactions can be accurately tracked; in addition, after obtaining the target application thread event corresponding to the target transaction, by combining the system thread event and the target application thread event, the complete transaction execution flow of the asynchronous operation between threads can be accurately and comprehensively captured, which not only improves the accuracy of transaction tracking, but also enhances the reliability of performance analysis based on the transaction execution flow. Therefore, through the method provided by the embodiment of the present application, in the face of complex transaction processing scenarios such as asynchronous operations between threads or multiple transactions executed concurrently and sharing thread resources, the transaction execution flow of each transaction can also be accurately tracked, thereby ensuring the accuracy and reliability of system performance analysis.

[0031] In order to facilitate the understanding of the embodiments of the present application, the application scenario of the method for obtaining the transaction processing flow provided in the embodiments of the present application is first briefly described. Figure 4 The following is a schematic diagram showing an application scenario of the method for obtaining a transaction processing flow provided in an embodiment of the present application. Figure 4 As shown, the application scenario includes a client 110 and a computing node 120, and the computing node 120 and the client 110 perform data communication. The client 110 can be deployed on a computing device such as a mobile phone, a computer, a tablet computer, etc. The specific form of the computing node 120 can be a physical machine, a virtual machine or a container, etc.

[0032] In an application example, a user sends a transaction processing request for a target transaction to a computing node 120 through a client 110. After receiving the transaction processing request, the computing node 120 obtains the request metadata of the transaction processing request. The computing node 120 processes the target transaction based on the request metadata. In the process of the computing node 120 processing the target transaction, the computing node 120 obtains a system thread event and obtains the corresponding application thread event at at least one preset event acquisition point. Each application thread event contains a transaction identifier for identifying the transaction to which the target application thread event belongs. Based on the transaction identifier, each target application thread event belonging to the target transaction is determined from each application thread event. Finally, the transaction execution flow of the target transaction is generated based on the system thread event and the target application thread event.

[0033] It should be noted that the above application scenarios or application examples provided in the embodiments of the present application are for ease of understanding, and the embodiments of the present application do not specifically limit the application of the technical solution. In addition, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application 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 provide corresponding operation entrances for users to choose to authorize or refuse.

[0034] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The several specific embodiments listed can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0035] Figure 5 One of the flow diagrams of the method for obtaining the transaction execution flow provided in the embodiment of the present application is shown. The method can be applied to Figure 4 The computing node 120 in the application scenario shown. Figure 5 As shown, the method may include step S501, step S502, step S503 and step S504.

[0036] Step S501: In response to receiving a transaction processing request of a target transaction, obtaining request metadata of the transaction processing request.

[0037] Step S502: In the process of processing the target transaction based on the request metadata, a system thread event is obtained and an application thread event corresponding to at least one preset event acquisition point is obtained respectively. Each application thread event includes a transaction identifier, which is used to identify the transaction to which the application thread event belongs. The above-mentioned preset event acquisition point refers to an insertion position that is pre-inserted on the transaction execution path.

[0038] Step S503: Determine a target application thread event from at least one application thread event according to the transaction identifier, where the target application thread event refers to an application thread event belonging to the target transaction.

[0039] Step S504: Generate a transaction execution flow of the target transaction according to each system thread event and the target application thread event, where the transaction execution flow is used to characterize the execution process of the target transaction.

[0040] Exemplarily, the transaction processing request may be sent by a client, or may be sent by an upstream computing node of the node 120 in a distributed transaction processing system.

[0041] In one embodiment, in the above step S501, obtaining the request metadata of the transaction processing request may be to extract the metadata fields in the transaction processing request, and construct the above request data based on the metadata fields. Exemplarily, for any transaction processing request, the transaction processing request usually carries information such as the user information initiating the request, the request time, the request parameters, and the request identification (ID). Therefore, a possible form of the obtained request metadata is {request ID, user information, request time, request parameters}.

[0042] Generally, the computing node 120 needs to call a series of functions in the process of processing the target transaction, and these functions constitute the function call sequence for executing the target transaction, which can also be called the transaction execution path. In this implementation process, the request metadata is encapsulated as function parameters and passed between each function in sequence, so that each function can access the key information required by the target transaction in the process of processing the target transaction, thereby collaboratively completing complex transaction processing tasks.

[0043] In one embodiment, the preset event acquisition point is located on the transaction execution path of the target transaction, that is, on the function call sequence. Therefore, the preset event acquisition point can be located at the entry of each function in the function call sequence. In order to achieve the ability to obtain the corresponding application thread event at each preset event acquisition point, a stub can be pre-inserted at each preset event acquisition point, so that when the preset event acquisition point is executed, the stub code is automatically executed to obtain the application thread event.

[0044] In the process of processing the target transaction, the computing node may process other transactions in parallel. Therefore, the application thread event obtained at each preset event acquisition point in the above step S502 may be the application thread event corresponding to the target transaction, or it may be the application thread event corresponding to other transactions. Therefore, in order to realize the division of application transactions into corresponding transactions, in an embodiment of the present application, each application thread event obtained carries a transaction identifier for identifying the transaction to which the application thread event belongs. Usually, the same transaction corresponds to the same transaction identifier, and different transactions correspond to different transaction identifiers. In this way, based on the transaction identifier contained in each application thread event, the target application thread event corresponding to the target transaction can be screened out from each obtained application thread event.

[0045] It should be noted that the above-mentioned application thread event refers to a thread-related event generated at the application level. Exemplarily, in addition to the transaction identifier, the above-mentioned application thread event may also include any one or more of the following event information: thread ID, thread name, timestamp when the event occurs, location information of the preset event acquisition point for acquiring the event, and call stack information corresponding to the event. Among them, the location information of the preset event acquisition point may refer to the function information corresponding to the preset event acquisition point.

[0046] In the embodiment of the present application, the system thread event refers to a thread-related event generated at the operating system level, and the system thread event can be obtained by an event acquisition tool provided by the operating system. For example, if the operating system is a Linux system, the event acquisition tool can be a static tracking mechanism or Kprobe.

[0047] Among them, the static tracing mechanism allows developers to declare some hook points at fixed locations in the kernel code. When these hook points are triggered, the corresponding tracing code can be executed to obtain the corresponding system thread events. Kprobe is a dynamic tracing mechanism that allows dynamic insertion of probe points in the running kernel and performs user-defined operations to obtain the corresponding system thread events.

[0048] Exemplarily, the system thread event may be any one or more of a thread scheduling event, a thread wakeup event, a thread message passing event, and an inter-thread interrupt event, etc. Of course, when implementing the solution, the system thread event may also be other thread-related events, which will not be described one by one here.

[0049] Generally speaking, a thread scheduling event refers to a thread being scheduled to execute on a processor (Central Processing Unit, CPU) or a thread being scheduled out of the CPU and stopping execution. The above-mentioned thread wake-up event refers to a thread waking up another thread. Thread message passing events can be futex or pipe message passing events, where futex is an efficient user space synchronization mechanism, usually used to implement thread synchronization, such as mutex and read-write lock (rwlock). When a thread tries to acquire a futex lock already held by other threads, it will enter a waiting state until the lock is released. Pipe is the most basic inter-process communication mechanism, allowing two processes to communicate bidirectionally through a pipe. Of course, in addition to futex and pipe, thread message passing events can also be other inter-thread communication mechanisms such as message queues and signals, which will not be repeated here. The above-mentioned inter-thread interrupt event can be an inter-core interrupt (Inter Processor Interrupt, IPI event).

[0050] In an embodiment of the present application, the system thread event obtained above may include any one or more of the following event information: event name, thread ID, thread name, timestamp when the event occurs, call stack corresponding to the event, and other information. If the system thread event is a wake-up event, the system thread event also includes the following event information: the wake-up thread ID and the awakened thread ID of the wake-up event. For example, if the wake-up event is thread A waking up thread B, thread A is the wake-up thread and thread B is the awakened thread.

[0051] After obtaining the system thread event and the target application thread event corresponding to the target transaction, the transaction execution flow of the target transaction in each thread is generated based on the system thread event and the target application thread event. In one embodiment, the thread boundary event when the thread transfer occurs can be determined based on the above system thread event and the target application thread event, so as to obtain the event information corresponding to each thread based on the boundary event, and then obtain the transaction execution flow corresponding to each thread.

[0052] In an embodiment of the present application, in the process of processing a target transaction, a system thread event is obtained and an application thread event corresponding to at least one preset event acquisition point is obtained respectively, and each application thread event contains a transaction identifier for identifying the transaction to which the application thread event belongs. According to the transaction identifier, the target application thread event belonging to the target transaction can be accurately screened out from the obtained application thread events, so that in a scenario where multiple transactions are executed concurrently, the transaction execution flows of different transactions can be accurately distinguished, and the transaction execution flows of different transactions can be accurately tracked; in addition, after obtaining the target application thread event corresponding to the target transaction, by combining the system thread event and the target application thread event, the complete transaction execution flow of the asynchronous operation between threads can be accurately and comprehensively captured, which not only improves the accuracy of transaction tracking, but also enhances the reliability of performance analysis based on the transaction execution flow. Therefore, through the method provided in the embodiment of the present application, the transaction execution flow of each transaction can be accurately tracked, thereby ensuring the accuracy and reliability of system performance analysis.

[0053] In one embodiment, the above-mentioned preset event acquisition point can be obtained by tracking the application to which the target transaction belongs. Therefore, the method provided in the embodiment of the present application also includes the following steps: during the operation of the application to which the target transaction belongs, tracking the process of the application executing the target transaction to obtain the function call sequence of the application; classifying the functions in the function call sequence according to the request metadata carried in the parameters of each function in the function call sequence, and setting the above-mentioned preset event acquisition point according to the classified functions.

[0054] Exemplarily, the above-mentioned preset event acquisition point refers to each function in a function call sequence. Furthermore, the above-mentioned preset event acquisition point is set at the function entry of each function.

[0055] In one embodiment, a path tracing tool in the prior art can be used to track the running process of an application. Exemplarily, the path tracing tool can be perf or function tracing. Perf or function tracing is a tool built into the Linux kernel and does not need to be installed separately. Perf is a command line tool set based on the kernel performance event subsystem, which can be used to collect information such as events. Function tracing is a lightweight tracing framework that comes with the Linux kernel, mainly used to track kernel function calls and other kernel events. When implementing the solution, the path tracing tool is run by inputting commands to collect the function call sequence of the application.

[0056] In addition, it should be noted that the above-mentioned application may execute multiple transactions in parallel during operation. Therefore, after obtaining the above-mentioned function call sequence through the tracing tool, the function call sequence corresponding to the target transaction is obtained by classifying it according to the request metadata carried in the parameters corresponding to each function in the function call sequence, and then each function in the function call sequence corresponding to the target transaction is used as the above-mentioned preset event acquisition point, or, the function at the top of the call stack in the function call sequence corresponding to the target transaction can be used as the above-mentioned preset event acquisition point.

[0057] Exemplarily, the corresponding application thread event can be obtained at each preset event acquisition point by inserting a stub at each function entrance. In implementation, the stub can be inserted at each function entrance by static insertion or dynamic insertion. In implementation, the corresponding insertion method can be selected according to actual needs, which will not be described here.

[0058] In one implementation, the above-mentioned operation of setting a preset event acquisition point may be performed before step S501.

[0059] In an embodiment of the present application, the function call sequence of the target transaction is obtained by using a tracing tool, thereby achieving automated acquisition of the function call sequence without the need for human involvement or in-depth understanding of the application. This not only significantly improves the efficiency of obtaining the function call sequence, but also ensures the accuracy and reliability of the data.

[0060] In an embodiment of the present application, the transaction identifier can be directly obtained from the request metadata, or it can be generated at each preset event acquisition point. Therefore, the method provided in the embodiment of the present application also includes the following steps: in the case where the request metadata includes a target identifier and a metadata field, the target identifier is obtained in the request metadata, and the target identifier is determined as the transaction identifier, and the target identifier is generated by encoding the metadata field; or, in the case where the request metadata includes a metadata field, the non-pointer field in the metadata field is encoded, and the encoding result is determined as the transaction identifier.

[0061] In one embodiment, the request metadata carries a target identifier that can be used as a transaction identifier. In this case, the target identifier is passed between functions along with the request metadata, so that at each preset event acquisition point, the target identifier carried by the request metadata is obtained from the request metadata as the transaction identifier of the application thread event. For this implementation scheme, when obtaining the request metadata of a transaction processing request, the target identifier is generated based on the metadata field extracted from the transaction processing request. Exemplarily, the metadata field in the transaction processing request can be first extracted, the metadata field can be encoded to obtain a target identifier, and the target identifier and the metadata field can be used as the request metadata.

[0062] For example, a common way to encode the metadata field is to calculate the metadata field through a hash algorithm to generate a corresponding hash value, and use the hash value as the target identifier. The hash algorithm can be Message Digest Algorithm 5 (MD5) or Secure Hash Algorithm (SHA).

[0063] Normally, if you insert the tracking code for obtaining the application thread events into the target application by static stubbing, you need to modify the source code of the application. In this case, you need to insert the tracking code at each preset event acquisition point in the source code of the application and compile it. In this case, you can modify the source code of the application so that when obtaining the request metadata of the transaction processing request, the target identifier is generated at the same time, as one of the data contents of the request metadata, and is passed between various functions along with the request metadata.

[0064] Alternatively, in another embodiment, when the request metadata does not include the target identifier, a corresponding transaction identifier may be generated at each preset event acquisition point. Exemplarily, the request metadata includes a metadata field, and a corresponding transaction identifier may be generated at each preset event acquisition point based on a non-pointer field in the request metadata transmitted to the preset event acquisition point.

[0065] For example, a common way to encode the non-pointer field in the request metadata is to calculate the non-pointer field through a hash algorithm, generate a corresponding hash value, and use the hash value as a transaction identifier. The hash algorithm can be an MD5 algorithm or a SHA algorithm.

[0066] In some application scenarios, the request metadata may contain pointers to point a metadata field in the request metadata to other metadata fields or resources. In this case, the pointer and non-pointer fields in the request metadata may form a complex tree structure. Figure 6 As shown, in Figure 6 In the request metadata structure shown, the box represents a non-pointer field, and the arrow represents a pointer, which points a non-pointer field to another or more non-pointer fields. When the request metadata is passed along with the function, the pointer in the request metadata may be modified. Therefore, if the transaction identifier is generated based on the request metadata, the transaction identifiers corresponding to the same transaction at different preset event acquisition points may be different, and thus the application thread event corresponding to the same transaction cannot be accurately identified.

[0067] Therefore, in the embodiment of the present application, the above transaction identifier is generated based on the non-pointer field in the request metadata, so as to ensure that the same thing has the same transaction identifier at each preset event acquisition point. Exemplarily, each field in the metadata can be read one by one through a breadth-first search (BFS) algorithm, and all non-pointer fields can be extracted therefrom. These fields will be arranged in order to form a serialized data processing flow, and then the corresponding transaction identifier is generated based on the data processing flow.

[0068] It should be noted that in the embodiment of the present application, if the application thread event is obtained at each preset event acquisition point by means of dynamic plugging, there is no need to modify the source code of the application. In this case, it is impossible to generate the above-mentioned target identifier when obtaining the request metadata of the transaction processing request, and pass it between various functions as one of the data contents of the request metadata. Therefore, for the dynamic plugging solution, the acquisition of the transaction identifier can be achieved by generating the transaction identifier at each preset event acquisition point.

[0069] Exemplarily, a possible implementation method of obtaining application thread events at each preset event acquisition point by dynamic instrumentation is as follows: adding the tracing code for obtaining application thread events to the memory of the application, and modifying the program execution function of the application so that the above tracing code is run when the application runs to each preset event acquisition point to obtain the application thread events at the preset event acquisition point.

[0070] In addition, it should be noted that, for the case of static instrumentation, the corresponding transaction identifier can also be obtained by generating a transaction identifier based on the non-pointer field in the request metadata at each preset event acquisition point. For the case of static instrumentation, the corresponding transaction identifier acquisition method can be selected according to actual needs during implementation.

[0071] In the embodiment of the present application, by encoding the metadata field in the request metadata or by encoding the non-pointer field in the request metadata to generate a transaction identifier, it can be ensured that each transaction has a unique identifier, and the possibility of identifier conflicts between different transactions can be reduced, thereby ensuring the accuracy of event distinction, and then ensuring the accuracy of tracking the transaction execution flow of each transaction, thereby ensuring the accuracy and reliability of system performance analysis.

[0072] Generally, when a target transaction is processed based on multiple threads, the transaction execution flow of the target transaction can be determined from which thread to which thread based on the application thread event, but the boundary event of the thread transfer cannot be determined, that is, which event causes the transaction to switch from one thread to another. For example, Figure 7 As shown, assuming that the target application thread event 1 corresponds to the I / O thread and the target application thread event 2 corresponds to the backend thread, it can be determined that the target transaction is transferred from the I / O thread to the backend thread through the target application thread event 1 and the target application thread event 2, but it is not clear when the transfer is performed. It may occur at any time between the target application thread event 1 and the target application thread event 2. However, determining when the thread transfer is performed is crucial for system performance analysis, such as latency analysis.

[0073] Therefore, in the embodiment of the present application, for the case where a target transaction is processed based on multiple threads, the boundary event of the thread transfer can be determined with the help of a system thread event between two application thread events where the thread transfer occurs. Therefore, in the case where there are multiple target application events and the target transaction is processed based on multiple threads, the above-mentioned step S504, generating the transaction execution flow of the target transaction according to each system thread event and the target application thread event, may include the following steps: for any two threads among the multiple threads, determining two target application thread events in the target application thread event that belong to the two threads respectively and are adjacent, the two adjacent target application thread events refer to two target application thread events that are adjacent in event occurrence time; determining a boundary event between the two threads according to the target system thread event between the two target application thread events, the target system thread event is a system thread event related to the two threads in each system thread event, the occurrence time of the target system thread event is between the occurrence times of the two target application thread events, the above-mentioned boundary event refers to a marker event that the target transaction is transferred from one thread to another thread of the two threads; determining the system thread events and the target application thread events that belong to the two threads respectively according to the boundary event; for any thread among the two threads, determining the transaction sub-execution flow of the target transaction in the thread according to the system thread event and the target application thread event belonging to the thread, the above-mentioned transaction execution flow includes the transaction sub-execution flow of the target transaction in each thread.

[0074] In one embodiment, two application thread events where thread transfer occurs can be found based on the target application thread events. For example, the target application thread events can be sorted according to the event occurrence time, and two target application thread events that belong to two threads and are adjacent can be found from the obtained target application sequence. Alternatively, in another embodiment, the target application thread events can be directly searched for two target application thread events that belong to two threads and are adjacent in event occurrence time without sorting the target application thread events.

[0075] To facilitate understanding, the following examples are given to illustrate.

[0076] Exemplarily, in one implementation, the acquired target application thread events include target application thread event 1, target application thread event 2, target application thread event 3, target application thread event 4, and target application thread event 5. The above target application thread events are sorted in the order of the time of event occurrence, and it is assumed that the obtained event sequence is: target application thread event 2, target application thread event 3, target application thread event 1, target application thread event 4, and target application thread event 5.

[0077] The occurrence time of the above events can be represented by the timestamp of each event, and this information is carried in the event information of each event.

[0078] Based on the event information of each event, the threads corresponding to the above-mentioned target application thread events can be determined. Assuming that the target application thread event 2 corresponds to thread 1, and the target application thread event 3 corresponds to thread 3, it can be determined that thread transfer has occurred between the target application thread event 2 and the target application thread event 3, that is, the target application thread event 2 and the target application thread event 3 can be used as the above-mentioned two target application thread events.

[0079] In the embodiment of the present application, the boundary event between the two threads can be determined by means of the system thread event located between the two target application thread events. Exemplarily, in one implementation, according to the event occurrence time of the two target application thread events, the event occurrence time of each system thread event, and the thread corresponding to each system thread event, a target system thread event whose occurrence time is between the occurrence time of the two target application thread events and is related to the two threads can be selected from each system thread event.

[0080] Exemplarily, the system thread event related to the threads corresponding to the two target application thread events can be selected from the system thread events according to the thread identifier in the system thread event and the thread identifier corresponding to the two target application thread events. For example, the thread identifier corresponding to the system thread event may be consistent with the thread identifier corresponding to the two target application thread events, or the thread identifier corresponding to the system thread event may include the thread identifiers corresponding to the two target application thread events.

[0081] After determining the target system thread event, the boundary event between the two threads is determined based on the target system thread event. It should be noted that the boundary event can be an event in the target system thread event or an event in the two target application thread events.

[0082] After the boundary event is obtained, the system thread event and the target application thread event belonging to each of the two threads are determined based on the boundary event, thereby obtaining the transaction sub-execution flow belonging to the thread.

[0083] In an embodiment of the present application, for two target application thread events that belong to two threads and are adjacent in event occurrence time, with the help of a target system thread event that is located between the two target application thread events and is related to the two threads, the boundary event between the two threads can be accurately determined, that is, the event at which the thread transfer occurs can be accurately determined, so that the transaction sub-execution flows corresponding to each thread can be accurately distinguished, thereby achieving in-depth analysis of system performance and improving the reliability and accuracy of system performance analysis.

[0084] In one embodiment, the above-mentioned determination of the boundary event between two threads based on the target system thread event between the two target application thread events may include the following steps: searching for a thread synchronization event in the target system thread event, and if a thread synchronization event exists in the target thread event, using the thread synchronization event as the above-mentioned boundary event; if there is no thread synchronization event in the target system thread event, searching for a thread scheduling event in the target system thread event, and if there is a thread scheduling event in the target system thread event, using the thread scheduling event as the above-mentioned boundary event; if there is no thread scheduling event in the target system thread event, searching for a message passing event in the target system thread event, and if there is a message passing event in the target system thread event, using the message passing event as the above-mentioned boundary event; if there is no message passing event in the target system thread event, determining the target application thread event that occurs earlier in the two target application thread events as the above-mentioned boundary event.

[0085] In an embodiment of the present application, system thread events can be divided into three categories, namely thread synchronization events, thread scheduling events and message passing events. Exemplarily, the above-mentioned thread synchronization events refer to mechanisms or events used to coordinate the execution order of multiple threads in a multi-threaded scenario. For example, the above-mentioned thread synchronization events may be thread wake-up events or thread interrupt events. The above-mentioned thread scheduling events refer to a series of actions and decisions that occur when the operating system schedules thread execution. In a multi-threaded environment, the scheduler of the operating system is responsible for managing the execution order of multiple threads to ensure that each thread can use processor resources as needed. For example, the above-mentioned thread scheduling events may include threads being scheduled out of the CPU or threads being scheduled into the CPU, etc. The above-mentioned message passing events refer to events that occur when threads communicate through a message passing mechanism. For example, the above-mentioned message passing events may be futex or pipe message passing events.

[0086] When determining the boundary events between threads based on the above three types of system thread events, the priorities of thread synchronization events, thread scheduling events and message passing events are not the same. Thread synchronization events can be used as clear boundaries between threads, so they have the highest priority, that is, when determining the boundary events between threads based on the target system thread events, it is preferred to find out whether there are thread synchronization events in the target system thread events. If there are thread synchronization events, the thread synchronization events are directly used as the boundary events between threads. Secondly, thread scheduling events can also indirectly reflect the temporary start or end of thread tasks. The deviation of using thread scheduling events as the boundary between threads will not be too large, that is, the priority of thread scheduling events is lower than that of thread synchronization events. Therefore, if there are no thread synchronization events in the target system thread events, it is possible to find out whether there are thread scheduling events. If there are thread scheduling events, the thread scheduling events are used as the boundary events between the above threads. Furthermore, when a thread transfer occurs in the transaction execution flow, based on the fact that the synchronization between threads is not performed directly, it is very likely that some messages will also be transmitted with the help of the operating system, that is, the priority of message passing events is lower than that of thread synchronization events and thread scheduling events, but they can also be used as boundary events between threads. Therefore, if there is no thread scheduling event in the target system thread event, then find out whether there is a message passing event in the target system thread event. If so, then use the message passing event as the boundary event between threads.

[0087] In some application scenarios, the target system thread event may not contain any of the above thread synchronization events, thread scheduling events, and message passing events. In this case, considering that the last action of the previous thread is to send the request metadata to the next thread, this event is likely to be captured, and the subsequent actions of the previous thread have little impact on the overall execution of the transaction. Therefore, in this case, the target application thread event that occurs earlier in the two target application thread events can be determined as the above boundary event.

[0088] It should be noted that the first thread mentioned above refers to the thread corresponding to the earlier target application thread event of the two target application thread events, and the second thread refers to the thread corresponding to the later target application thread event of the two target application thread events.

[0089] In the embodiment of the present application, the boundary events between threads are determined by hierarchically searching for different types of system thread events in the target system thread events, thereby improving the accuracy of the boundary events between threads determined, and also ensuring that when certain types of system thread events are true, the boundary events between threads can still be determined through other types of events, thereby enhancing the robustness of the solution. Through the above solution, the boundary events between threads can be accurately determined, thereby ensuring the accuracy and reliability of system performance analysis in a multi-threaded environment.

[0090] Generally, there may be multiple thread synchronization events in the obtained system thread events. Therefore, in the embodiment of the present application, if multiple thread synchronization events are found, any thread synchronization event can be used as the boundary event between threads. Alternatively, different priorities can be set for each thread synchronization event according to its importance and significance in characterizing the boundary between threads, and the boundary event between threads can be determined according to the priority.

[0091] Therefore, in one embodiment, the above-mentioned thread synchronization events include thread wake-up events and thread interrupt events. The thread wake-up event refers to an event in which the first thread wakes up the second thread. The first thread refers to a thread corresponding to a target application thread event that occurs earlier in two target application events, and the second thread refers to a thread corresponding to a target application thread event that occurs later in two target application events. The thread interrupt event refers to the first thread sending an IPI event to the second thread. Accordingly, searching for thread synchronization events in the target system thread events, and if there are thread synchronization events in the target thread events, taking the thread synchronization events as boundary events can include the following steps: searching for thread wake-up events in the target system thread events, and if there are thread wake-up events in the target system thread events, taking the thread wake-up events as the above-mentioned boundary events; if there are no thread wake-up events in the target system thread events, searching for inter-thread interrupt events in the target system thread events, and if there are inter-thread interrupt events in the target system thread events, taking the inter-thread interrupt events as the above-mentioned boundary events.

[0092] For example, it is assumed that the two target application thread events are event 1 and event 2, event 1 corresponds to thread 1, event 2 corresponds to thread 2, and the occurrence of event 1 is earlier than the occurrence of event 2. Therefore, the wake-up event refers to the event that thread 1 wakes up thread 2, and the thread interrupt event refers to the event that thread 1 sends an IPI to thread 2.

[0093] In an embodiment of the present application, when searching for thread synchronization events in the target system thread events, first search whether there is a thread wake-up event in the target system thread events. If there is a thread wake-up event, the thread wake-up event is used as the boundary event between threads. If there is no thread wake-up event, continue to search whether there is an interrupt event between threads. If so, the interrupt event between threads is used as the boundary event between threads.

[0094] In the embodiment of the present application, different priorities are assigned to different thread synchronization events, and boundary events between threads are matched in the target system thread events according to the priorities, so that those key events that can most significantly characterize thread switching can be more effectively located in the target system thread events. This not only improves the accuracy of the determined boundary events, but also avoids determining thread synchronization events that cannot obviously characterize thread switching as boundary events between threads, thereby significantly improving the accuracy and reliability of performance analysis.

[0095] Similarly, in the embodiment of the present application, there may be multiple thread scheduling events in the obtained system thread events. Therefore, in the embodiment of the present application, if multiple thread scheduling events are found, any thread scheduling event can be used as the boundary event between threads. Alternatively, different priorities can be set for each thread scheduling event according to its importance and significance in characterizing the boundary between threads, and the boundary event between threads can be determined according to the priority.

[0096] Therefore, in one embodiment, the above-mentioned thread scheduling events include thread scheduling-out events and thread scheduling-in events. The thread scheduling-out event refers to the event that the thread corresponding to the previous event of the two target application thread events is scheduled out of the CPU, and the thread scheduling-in event refers to the event that the thread corresponding to the latter event of the two target application thread events is scheduled into the CPU; accordingly, the above-mentioned searching for thread scheduling events in the target system thread events, and if there are thread scheduling events in the target system thread events, using the thread scheduling events as boundary events, can include the following steps: searching for thread scheduling-in events in the target system thread events, and if there are thread scheduling-in events in the target system thread events, using the thread scheduling-in events as the above-mentioned boundary events; if there are no thread scheduling-in events in the target system thread events, searching for thread scheduling-out events in the target system thread events, and if there are thread scheduling-out events in the target system thread events, using the thread scheduling-out events as the above-mentioned boundary events.

[0097] Exemplarily, assume that the two target application thread events are event 1 and event 2, event 1 corresponds to thread 1, event 2 corresponds to thread 2, and the occurrence event of event 1 is earlier than the occurrence event of event 2. The above-mentioned thread dispatch-out event refers to the event of thread 1 dispatching out of the CPU, and the above-mentioned thread dispatch-in event refers to the event of thread 2 dispatching into the CPU. Among them, the event of thread 1 dispatching out of the CPU means that in a multi-threaded operating system, thread 1 has completed its CPU time slice or needs to suspend execution for some reason, and is thus removed from the CPU by the scheduler of the operating system so that other threads can use CPU resources. The event of thread 2 dispatching into the CPU refers to the event that the scheduler of the operating system decides to assign the control of the CPU back to thread 2, so that it changes from a waiting or ready state to an execution state.

[0098] In an embodiment of the present application, when searching for a thread scheduling event in a target system thread event, first search in the target system thread event to see whether there is a thread scheduling in event. If there is a thread scheduling in event, the thread scheduling in event is used as the boundary event between threads. If there is no thread scheduling in event, continue to search for whether there is a thread scheduling out event. If so, the thread scheduling out event is used as the boundary event between threads.

[0099] In the embodiment of the present application, different priorities are assigned to different thread scheduling events, and boundary events between threads are matched in the target system thread events according to the priorities, so that those key events that can most significantly characterize thread switching can be more effectively located in the target system thread events. This not only improves the accuracy of the determined boundary events, but also avoids determining thread scheduling events that cannot obviously characterize thread switching as boundary events between threads, thereby significantly improving the accuracy and reliability of performance analysis.

[0100] To facilitate understanding of the above method for determining the boundary between threads, a specific embodiment will be described below. Figure 8 The second flow chart of the method for obtaining the transaction execution flow provided in the embodiment of the present application is shown as follows: Figure 8 As shown, the method includes the following steps S801 to S813.

[0101] Step S801: In response to receiving a transaction processing request of a target transaction, obtaining request metadata of the transaction processing request.

[0102] The request metadata includes metadata fields and target identifiers.

[0103] Step S802: In the process of processing the target transaction based on the above request metadata, obtain the system thread event and the corresponding application thread event at at least one preset event acquisition point respectively, and obtain the target identifier in the request metadata at each preset event acquisition point as the transaction identifier of the application thread event.

[0104] Step S803: Determine a target application program thread event belonging to the target transaction from at least one application program thread event according to the transaction identifier.

[0105] Step S804: For any two threads among the multiple threads, determine two target application program thread events in the target application program thread events that belong to the two threads respectively and are adjacent.

[0106] Step S805: Search the target system thread events between the two target application thread events to see whether there is a thread wakeup event. If yes, execute step S811; otherwise, execute step S806.

[0107] Step S806: Search the target system thread events to see if there is a thread interruption event. If so, execute step S811; otherwise, execute step S807.

[0108] Step S807: Search in the target system thread events whether there is a thread scheduling event, if so, execute step S811; otherwise, execute step S808.

[0109] Step S808: Search in the target system thread events whether there is a thread dispatching event, if so, execute step S811; otherwise, execute step S809.

[0110] Step S809: Search in the target system thread event whether there is a message passing event, if so, execute step S811; otherwise, execute step S810.

[0111] Step S810: Determine the target application program thread event that occurs earlier of the two target application program thread events as an inter-thread boundary event.

[0112] Step S811: Determine it as a boundary event between threads.

[0113] Step S812: Determine the system thread event and the target application thread event belonging to the two threads respectively according to the boundary event.

[0114] Step S813: For any thread of the two threads, determine the transaction sub-execution flow of the target transaction in the thread according to the system thread event and the target application thread event belonging to the thread.

[0115] In an embodiment of the present application, after determining the boundary event between any two threads, the system thread event and the target application thread event corresponding to each thread can be determined according to the boundary event. Exemplarily, in one embodiment, the above-mentioned determination of the transaction sub-execution flow of the target transaction in the thread according to the system thread event and the target application thread event belonging to the thread can include the following steps: sorting the target application thread events belonging to the thread from early to late according to the first timestamp to obtain a first event sequence; inserting the system thread event into the first event sequence according to the first timestamp and the second timestamp of the system thread event belonging to the thread to obtain a second event sequence; obtaining the above-mentioned transaction sub-execution flow based on the second event sequence.

[0116] The event information of each target application thread event includes the first timestamp corresponding to the application thread event. Therefore, in one embodiment, the first timestamp corresponding to each target application thread event is obtained from the event information of each target application thread event, and the target application thread events are sorted in order from the earliest to the latest according to the first timestamps, so as to obtain the first event sequence including the target application thread events.

[0117] For each system thread event, according to the thread corresponding to each system thread event, the system thread event belonging to the thread is respectively inserted into the corresponding position of the first event sequence according to the second timestamp corresponding to the thread, so as to obtain a second event sequence including the system thread event and the target application thread event. The second timestamp corresponding to the system thread event can be obtained from the event information of the system thread event.

[0118] For ease of understanding, the following examples are given to illustrate.

[0119] Assume that the system thread event corresponding to thread 1 is system thread event 1, and the target application thread events corresponding to thread 1 include target application thread event 1, target application thread event 2, target application thread event 3, target application thread event 4 and target application thread event 5.

[0120] The above target application thread events are sorted in order from early to late according to the first timestamps corresponding to each target application thread event, and the obtained first event sequence is: target application thread event 2, target application thread event 4, target application thread event 5, target application thread event 3, target application thread event 1.

[0121] Assuming that the second timestamp corresponding to the system thread event 1 is within the occurrence time range of the target application thread event 2 and the target application 4, the system thread event 1 is inserted between the target application thread event 2 and the target application 4. Therefore, the obtained second event sequence is: target application thread event 2, system thread event 1, target application thread event 4, target application thread event 5, target application thread event 3, target application thread event 1.

[0122] After obtaining the second event sequence, the transaction sub-execution flow of the target transaction in the thread is obtained based on the second event sequence. Exemplarily, the second event sequence can be directly used as the transaction sub-execution flow of the target transaction in the thread, or the second event sequence can be processed accordingly according to the performance analysis required to obtain the transaction sub-execution flow.

[0123] In an embodiment of the present application, by sorting the target application thread events and system thread events in order from early to late according to the timestamps, the transaction sub-execution flow of the target transaction in each thread can be accurately reconstructed, thereby enabling detailed analysis of the thread performance, resource optimization and fault diagnosis, which not only improves the accuracy of the system performance analysis, but also realizes the management and optimization of the multi-threaded system.

[0124] After obtaining the transaction sub-execution flow of the target transaction in each thread through the method provided in the embodiment of the present application, the operating system or application can be subjected to performance analysis based on the transaction sub-execution flow, such as delay analysis. For this case, the transaction sub-execution flow obtained above needs to include corresponding execution time information in addition to each event. Therefore, in one embodiment, the transaction sub-execution flow obtained based on the second event sequence may include the following steps: dividing the second event sequence into multiple event segments according to a preset division rule; for any event segment, calculating the execution time of the event segment according to the event timestamp of the start event and the event timestamp of the end event in the event segment; and determining each event segment and the execution time corresponding to each event segment as the above-mentioned transaction sub-execution flow.

[0125] Exemplarily, the preset division rule may be that every two events are divided into one event segment, or every three events are divided into one event segment. In implementation, the specific division rule of the preset division rule may be set according to actual needs, which is only an exemplary description and does not constitute a limitation on the embodiments of the present application.

[0126] In one implementation, the difference between the event timestamp of the termination event and the event timestamp of the start event may be used as the execution time of the event segment.

[0127] To facilitate understanding, the following examples are given to illustrate.

[0128] Continuing with the above example, it is assumed that the obtained second event sequence is: target application thread event 2, system thread event 1, target application thread event 4, target application thread event 5, target application thread event 3, target application thread event 1.

[0129] The second event sequence is divided into segments, and the obtained event segments may be:

[0130] Event fragment 1: target application thread event 2, system thread event 1; event fragment 2: target application thread event 4, target application thread event 5; event fragment 3: target application thread event 3, target application thread event 1.

[0131] For event fragment 1, the corresponding execution time may be the time difference between the event timestamp of system thread event 1 and the event timestamp of target application thread event 2. For event fragment 2, the corresponding execution time may be the time difference between the event timestamp of target application thread event 5 and the event timestamp of target application thread event 4. For event fragment 3, the corresponding execution time may be the time difference between the event timestamp of target application thread event 1 and the event timestamp of target application thread event 3.

[0132] A possible form of the resulting transaction sub-execution flow may be:

[0133] Event fragment 1: target application thread event 2, system thread event 1, execution time 1; event fragment 2: target application thread event 4, target application thread event 5, execution time 2; event fragment 3: target application thread event 3, target application thread event 1, execution time 3.

[0134] In an embodiment of the present application, by dividing the second event sequence into multiple event segments and calculating the execution time of each event segment, it is possible to analyze the performance of each event segment. Through such an operation, it is not only helpful to accurately identify abnormal situations in each event segment, but also to effectively locate inefficient operations or processes, so as to perform targeted optimization to improve the overall performance of the system.

[0135] Corresponding to the application scenario and method of the method provided in the embodiment of the present application, the embodiment of the present application also provides a device for obtaining a transaction execution flow. Fig. 9 The schematic diagram of the module composition of the transaction execution flow acquisition device provided in the embodiment of the present application is shown as follows: Fig. 9As shown, the device includes: a first acquisition module 901, which is used to obtain request metadata of the transaction processing request in response to receiving a transaction processing request of a target transaction; a second acquisition module 902, which is used to obtain system thread events and respectively obtain application thread events corresponding to at least one preset event acquisition point in the process of processing the target transaction based on the request metadata, each of the application thread events includes a transaction identifier, the transaction identifier is used to identify the transaction to which the application thread event belongs, and the preset event acquisition point refers to an insertion position pre-inserted on the transaction execution path; a determination module 903, which is used to determine a target application thread event from at least one of the application thread events according to the transaction identifier, and the target application thread event refers to an application thread event belonging to the target transaction; a generation module 904, which is used to generate a transaction execution flow of the target transaction according to the system thread event and the target application thread event, and the transaction execution flow is used to characterize the execution process of the target transaction.

[0136] In one embodiment, the device provided by the embodiment of the present application also includes: a third acquisition module, which is used to obtain the target identifier in the request metadata when the request metadata includes a target identifier and a metadata field, and determine the target identifier as the transaction identifier, and the target identifier is generated by encoding the metadata field; or, an encoding module, which is used to encode a non-pointer field in the metadata field when the request metadata includes a metadata field, and determine the encoding result as the transaction identifier.

[0137] In one embodiment, when there are multiple target application thread events and the target transaction is processed based on multiple threads, the generation module 904 is specifically used to: determine, for any two threads among the multiple threads, two target application thread events that belong to the two threads respectively and are adjacent to each other in the target application thread events, wherein the two adjacent target application thread events refer to two target application thread events that are adjacent in event occurrence time; determine, based on a target system thread event between the two target application thread events, a boundary event between the two threads, wherein the target system thread event is a system thread event related to the two threads in each of the system thread events, wherein the occurrence time of the target system thread event is between the occurrence times of the two target application thread events, and wherein the boundary event refers to a marker event that the target transaction is transferred from one of the two threads to another; determine, based on the boundary event, system thread events and target application thread events that belong to the two threads respectively; and determine, for any one of the two threads, a transaction sub-execution flow of the target transaction in the thread according to the system thread event and the target application thread event that belong to the thread, wherein the transaction execution flow includes the transaction sub-execution flows of the target transaction in each thread.

[0138] In one embodiment, the above-mentioned generation module 904 is also specifically used to: search for thread synchronization events in the target system thread events, and if the thread synchronization event exists in the target thread events, use the thread synchronization event as the boundary event; if the thread synchronization event does not exist in the target system thread events, search for thread scheduling events in the target system thread events, and if the thread scheduling event exists in the target system thread events, use the thread scheduling event as the boundary event; if the thread scheduling event does not exist in the target system thread events, search for message passing events in the target system thread events; if the message passing event exists in the target system thread events, use the message passing event as the boundary event; if the message passing event does not exist in the target system thread events, determine the target application thread event that occurs earlier among the two target application thread events as the boundary event.

[0139] In one implementation, the thread synchronization event includes a thread wake-up event and a thread interruption event, wherein the thread wake-up event refers to an event in which a first thread wakes up a second thread, wherein the first thread refers to a thread corresponding to a target application thread event that occurs earlier of the two target application events, and the second thread refers to a thread corresponding to a target application thread event that occurs later of the two target application events, and the thread interruption event refers to the first thread sending an IPI event to the second thread; the above-mentioned generation module 904 is further specifically used for:

[0140] Search for the thread wake-up event in the target system thread event; if the thread wake-up event exists in the target system thread event, use the thread wake-up event as the boundary event; if the thread wake-up event does not exist in the target system thread event, search for the inter-thread interrupt event in the target system thread event; if the inter-thread interrupt event exists in the target system thread event, use the inter-thread interrupt event as the boundary event.

[0141] In one embodiment, the thread scheduling event includes a thread scheduling-out event and a thread scheduling-in event, wherein the thread scheduling-out event refers to an event in which the thread corresponding to the first event of the two target application thread events is scheduled out of the processor CPU, and the thread scheduling-in event refers to an event in which the thread corresponding to the second event of the two target application thread events is scheduled into the CPU; the above-mentioned generation module 904 is also specifically used to: search for the thread scheduling-in event in the target system thread event, and if the thread scheduling-in event exists in the target system thread event, use the thread scheduling-in event as the boundary event; if the thread scheduling-in event does not exist in the target system thread event, search for the thread scheduling-out event in the target system thread event; if the thread scheduling-in event exists in the target system thread event, use the thread scheduling-out event as the boundary event.

[0142] In one embodiment, the above-mentioned generation module 904 is also specifically used to: sort the target application thread events belonging to the thread from early to late according to the first timestamp to obtain a first event sequence; insert the system thread event into the first event sequence according to the first timestamp and the second timestamp of the system thread event belonging to the thread to obtain a second event sequence; and obtain the transaction sub-execution flow based on the second event sequence.

[0143] In one embodiment, the above-mentioned generation module 904 is also specifically used to: divide the second event sequence into multiple event segments according to a preset division rule; for any event segment, calculate the execution time of the event segment according to the event timestamp of the starting event and the event timestamp of the ending event in the event segment; determine each of the event segments and the execution time corresponding to each event segment as the transaction sub-execution flow.

[0144] In one embodiment, the device provided by the embodiment of the present application also includes: a tracking module, which is used to track the process of the application executing the target transaction during the operation of the application to which the target transaction belongs, so as to obtain the function call sequence of the application; a classification module, which is used to classify the functions in the function call sequence according to the request metadata carried in the parameters of each function in the function call sequence, and set the preset event acquisition point according to the classified functions.

[0145] The functions of each module in each device in the embodiments of the present application can be found in the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.

[0146] Fig.10 FIG. 1 is a block diagram of an electronic device used to implement an embodiment of the present application. Fig.10 As shown, the electronic device includes: a memory 1001 and a processor 1002, and the memory 1001 stores a computer program that can be run on the processor 1002. When the processor 1002 executes the computer program, the method in the above embodiment is implemented. The number of the memory 1001 and the processor 1002 can be one or more. In a specific implementation, the electronic device may also include a communication interface 1003 for communicating with an external device and performing data exchange transmission.

[0147] In specific implementation, if the memory 1001, the processor 1002 and the communication interface 1003 are implemented independently, the memory 1001, the processor 1002 and the communication interface 1003 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.10 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0148] Optionally, in a specific implementation, if the memory 1001, the processor 1002 and the communication interface 1003 are integrated on a chip, the memory 1001, the processor 1002 and the communication interface 1003 can communicate with each other through an internal interface.

[0149] An embodiment of the present application provides a computer-readable storage medium storing a computer program, which implements the method provided in the embodiment of the present application when the program is executed by a processor.

[0150] An embodiment of the present application provides a computer program product, including a computer program, which implements the method provided in the embodiment of the present application when executed by a processor.

[0151] An embodiment of the present application also provides a chip, which includes a processor for calling and executing instructions stored in the memory from the memory, so that a communication device equipped with the chip executes the method provided by the embodiment of the present application.

[0152] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method provided in the embodiment of the application.

[0153] It should be understood that the processor may be a CPU, or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor supporting the Advanced RISC Machines (ARM) architecture.

[0154] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of exemplary but not limiting description, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct memory bus random access memory (DR RAM).

[0155] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0156] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.

[0157] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0158] Any process or method described in the flow chart or otherwise described herein can be understood as a module, fragment or portion of a code representing one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiment of the present application includes other implementations, in which the functions may not be performed in the order shown or discussed, including in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0159] The logic and / or steps described in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, which can be embodied in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processor or other system that can fetch instructions from an instruction execution system, apparatus or device and execute instructions), or used in combination with these instruction execution systems, apparatuses or devices.

[0160] It should be understood that the various parts of the present application can be implemented with hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented with software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above embodiment method can be completed by instructing the relevant hardware through a program, which can be stored in a computer-readable storage medium, and when the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0161] In addition, each functional unit in each embodiment of the present application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a disk or an optical disk, etc.

[0162] The above is only an exemplary embodiment of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various changes or substitutions within the technical scope recorded in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A method for acquiring a transaction execution flow, characterized in that: include: In response to receiving a transaction processing request for a target transaction, obtaining request metadata of the transaction processing request; In the process of processing the target transaction based on the request metadata, a system thread event is obtained and an application thread event corresponding to at least one preset event acquisition point is respectively obtained, each of the application thread events includes a transaction identifier, and the transaction identifier is used to identify the transaction to which the application thread event belongs. The preset event acquisition point refers to an insertion position pre-inserted on the transaction execution path; Determine a target application thread event from at least one of the application thread events according to the transaction identifier, wherein the target application thread event refers to an application thread event belonging to the target transaction; Generate a transaction execution flow of the target transaction according to the system thread event and the target application thread event, wherein the transaction execution flow is used to characterize the execution process of the target transaction; Wherein, in the case that the request metadata includes a metadata field, a non-pointer field in the metadata field is encoded, and the encoding result is determined as the transaction identifier.

2. The method according to claim 1, characterized in that The method further comprises: In the case that the request metadata includes a target identifier and a metadata field, the target identifier is obtained from the request metadata and is determined as the transaction identifier. The target identifier is generated by encoding the metadata field.

3. The method according to claim 1 or 2, characterized in that: In the case that there are multiple target application thread events and the target transaction is processed based on multiple threads, generating a transaction execution flow of the target transaction according to the system thread event and the target application thread event includes: For any two threads among the multiple threads, determine two target application thread events in the target application thread events that belong to the two threads respectively and are adjacent, wherein the two adjacent target application thread events refer to two target application thread events that are adjacent in event occurrence time; Determining a boundary event between the two threads according to a target system thread event between the two target application thread events, wherein the target system thread event is a system thread event related to the two threads among the system thread events, an occurrence time of the target system thread event is between the occurrence times of the two target application thread events, and the boundary event is a marker event for transferring the target transaction from one of the two threads to another; Determine, according to the boundary event, a system thread event and a target application thread event respectively belonging to each of the two threads; For any thread of the two threads, a transaction sub-execution flow of the target transaction in the thread is determined according to a system thread event and a target application thread event belonging to the thread, wherein the transaction execution flow includes the transaction sub-execution flows of the target transaction in each thread.

4. The method according to claim 3, characterized in that The step of determining the boundary event between the two threads according to the target system thread event between the two target application thread events includes: Searching for a thread synchronization event in the target system thread events, and if the thread synchronization event exists in the target system thread events, using the thread synchronization event as the boundary event; If the thread synchronization event does not exist in the target system thread event, searching for a thread scheduling event in the target system thread event, and if the thread scheduling event exists in the target system thread event, using the thread scheduling event as the boundary event; If the thread scheduling event does not exist in the target system thread event, searching for a message transfer event in the target system thread event; If the message passing event exists in the target system thread event, use the message passing event as the boundary event; If the message transfer event does not exist in the target system thread event, the target application thread event that occurs earlier in the two target application thread events is determined as the boundary event.

5. The method according to claim 4, characterized in that The thread synchronization event includes a thread wake-up event and a thread interruption event. The thread wake-up event refers to an event in which a first thread wakes up a second thread. The first thread refers to a thread corresponding to a target application thread event that occurs earlier of the two target application events. The second thread refers to a thread corresponding to a target application thread event that occurs later of the two target application events. The thread interruption event refers to an IPI event sent by the first thread to the second thread. The searching for a thread synchronization event in the target system thread event, and if the thread synchronization event exists in the target system thread event, taking the thread synchronization event as the boundary event, includes: Searching for the thread wake-up event in the target system thread events, and if the thread wake-up event exists in the target system thread events, taking the thread wake-up event as the boundary event; If the thread wake-up event does not exist in the target system thread event, searching for the inter-thread interrupt event in the target system thread event; If the inter-thread interrupt event exists in the target system thread event, the inter-thread interrupt event is used as the boundary event.

6. The method according to claim 4, characterized in that The thread scheduling event includes a thread scheduling out event and a thread scheduling in event, wherein the thread scheduling out event refers to an event in which the thread corresponding to the first event of the two target application thread events is scheduled out of the processor CPU, and the thread scheduling in event refers to an event in which the thread corresponding to the second event of the two target application thread events is scheduled into the CPU; The searching for a thread scheduling event in the target system thread event, and if the thread scheduling event exists in the target system thread event, taking the thread scheduling event as the boundary event, includes: Searching for the thread scheduling event in the target system thread events, and if the thread scheduling event exists in the target system thread events, using the thread scheduling event as the boundary event; If the thread dispatch-in event does not exist in the target system thread event, searching for the thread dispatch-out event in the target system thread event; If the thread dispatch out event exists in the target system thread event, the thread dispatch out event is used as the boundary event.

7. The method according to claim 3, characterized in that The determining the transaction sub-execution flow of the target transaction in the thread according to the system thread event and the target application thread event belonging to the thread comprises: Sort target application thread events belonging to the thread from earliest to latest according to the first timestamp to obtain a first event sequence; inserting the system thread event into the first event sequence according to the first timestamp and a second timestamp of a system thread event belonging to the thread to obtain a second event sequence; The transaction sub-execution flow is obtained based on the second event sequence.

8. The method according to claim 7, characterized in that The obtaining the transaction sub-execution flow based on the second event sequence includes: Dividing the second event sequence into a plurality of event segments according to a preset division rule; For any event segment, the execution time of the event segment is calculated according to the event timestamp of the start event and the event timestamp of the end event in the event segment; Each of the event fragments and the execution time corresponding to each of the event fragments are determined as the transaction sub-execution flow.

9. The method according to any one of claims 1 to 8, characterized in that: Also includes: During the operation of the application program to which the target transaction belongs, tracking the process of the application program executing the target transaction to obtain a function call sequence of the application program; The functions in the function call sequence are classified according to the request metadata carried in the parameters of each function in the function call sequence, and the preset event acquisition point is set according to the classified functions.

10. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 9 when executing the computer program.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

12. A computer program product, characterized in that A computer program is included which, when executed by a processor, implements the method according to any one of claims 1 to 9.

Images