Transaction processing method, electronic device, storage medium and program product

Abstract

The embodiment of the present application provides a transaction processing method, electronic device, storage medium and program product, including: in response to receiving a transaction processing request of a target transaction, in the process of processing the target transaction, obtaining at least one system thread event and at least one application thread event, the application thread event including a transaction boundary event; generating a valid event sequence based on at least one system thread event and at least one application thread event; generating a transaction execution sequence of the target transaction according to the valid event sequence; the transaction execution sequence is used to perform performance analysis on an operating system and / or an application, the application being an application that executes the target transaction. The technical solution provided by the present application can accurately generate a transaction execution sequence, thereby ensuring the reliability and accuracy of the performance analysis of the operating system and / or the application.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a transaction processing method, electronic equipment, storage medium and program product. Background Art

[0002] In today's computing field, system performance, especially the latency of transaction execution, has become a core indicator for measuring system stability and user experience. For example, in e-commerce, financial services, and online games, the quality of system performance is directly related to user experience and service results. Therefore, it is particularly important to deeply analyze system performance and optimize it.

[0003] At present, when performing system performance analysis, each event in the transaction execution process is usually collected and analyzed separately. Although this can achieve system performance analysis, it does not consider the interaction and influence of these events in the entire transaction execution sequence, thus affecting the accuracy and reliability of performance analysis. At present, there is no effective means to obtain the overall execution process of the transaction. Therefore, how to generate the transaction execution sequence has become a technical problem that needs to be solved urgently. Summary of the invention

[0004] The embodiments of the present application provide a transaction processing method, 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 transaction processing method, the method comprising: in response to receiving a transaction processing request of a target transaction, obtaining at least one system thread event and at least one application thread event in the process of processing the target transaction, the application thread event including a transaction boundary event; generating a valid event sequence based on the at least one system thread event and the at least one application thread event, the valid events in the valid event sequence refer to system thread events and / or application thread events whose occurrence times are within the occurrence time range of the transaction boundary event, and are also within the occurrence time range of the system thread event; generating a transaction execution sequence of the target transaction according to the valid event sequence, the transaction execution sequence being used to perform performance analysis on an operating system and / or an application, the application referring to an application that executes 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 in the embodiment of the present application, in response to receiving a transaction processing request of a target transaction, obtains at least one system thread event and at least one application thread event in the process of processing the target transaction, wherein the application thread event includes a transaction boundary event. In this way, the time range of the occurrence of the event can be captured by setting the transaction boundary event, so that events within the time range of the occurrence of the transaction boundary event and outside the time range of the occurrence of the system thread event can be excluded. In addition, by defining clear transaction boundary events and using them as reference points, it is possible to assist in the event collection in the operating system and the application, thereby avoiding the problem of missing events caused by incomplete synchronization of the event collection of the operating system and the application, thereby ensuring the accuracy of the generated transaction execution sequence, and thereby improving the reliability and accuracy of the performance analysis of the operating system and / or application.

[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 A schematic diagram of an application scenario of the transaction processing method provided in an embodiment of the present application is shown;

[0013] Figure 2 One of the flow diagrams of the transaction processing method provided in the embodiment of the present application is shown;

[0014] Figure 3 The second flowchart of the transaction processing method provided in the embodiment of the present application is shown;

[0015] Figure 4One of the schematic diagrams of the display interface of the performance analysis result in the transaction processing method provided in the embodiment of the present application is shown;

[0016] Figure 5 A second schematic diagram of a display interface for the performance analysis results in the transaction processing method provided in an embodiment of the present application is shown;

[0017] Figure 6 The third schematic diagram of the display interface of the performance analysis result in the transaction processing method provided in the embodiment of the present application is shown;

[0018] Figure 7 A fourth schematic diagram of a display interface for performance analysis results in a transaction processing method provided in an embodiment of the present application is shown;

[0019] Figure 8 The third flowchart of the transaction processing method provided in the embodiment of the present application is shown;

[0020] Fig. 9 A schematic diagram showing the module composition of a transaction processing device 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 computing field, system performance, especially the latency of transaction execution, has become a core indicator for measuring system stability and user experience. For example, in e-commerce, financial services, and online games, the quality of system performance is directly related to user experience and service results. Therefore, it is particularly important to deeply analyze system performance and optimize it.

[0025] Currently, in the field of performance analysis, the Extended Berkeley Packet Filter (eBPF)-based technology and the wait performance analysis tool (wPerf) are widely used to analyze the execution delay of the system.

[0026] When using eBPF technology to analyze the execution delay of the system, the execution delay analysis of the system is usually achieved by analyzing thread blocking. When implementing this related technology, the eBPF technology can be used to insert the kernel function of the operating system, such as the Linux system. The kernel function can be a function executed when the thread scheduling is completed, such as the finish taskswitch function. In this way, during the operation of the system, the timestamp and call stack when the function is called can be obtained by running the inserted code. Among them, the function is called, which means that the current thread is scheduled out of the processor (Central Processing Unit, CPU) and the next thread is scheduled into the CPU. Therefore, by collecting the timestamp when the above function is called, the time when the current thread is scheduled out of the CPU and the time when it is scheduled into the CPU again can be obtained at the same time. Therefore, the off-CPU running time (off-CPU) of each thread can be calculated, that is, the time period when the thread does not occupy the CPU while waiting for resources or conditions to be met, that is, the time when the thread is blocked. Among them, the period when the condition is met refers to the time period from when the thread starts waiting for a certain condition to when the condition is finally met.

[0027] Furthermore, in this related technology, each off-CPU time can also be bound to the call stack to merge the thread blocking time corresponding to all related call stacks, and generate an off-CPU time flame graph to analyze the cause of thread blocking, thereby realizing execution delay analysis of the system.

[0028] However, based on the above description, although eBPF provides detailed timestamp and call stack information, it mainly focuses on the off-CPU time statistics of a single thread, and fails to fully consider the interaction and impact of the off-CPU time of these single threads in the entire transaction execution sequence, which may affect the accuracy and reliability of performance analysis.

[0029] In addition, when analyzing system performance through the wPerf tool, it mainly focuses on analyzing wait events in multi-threaded applications. When implementing this technology, the kernel dynamic tracking tool collects thread events at the operating system level, such as thread scheduling, thread wakeup, thread interruption, and input / output, and builds a wait graph based on the collected events to analyze the impact of each event on latency. This technology helps to identify key events that cause execution delays. However, although this technology can also realize latency analysis of system execution transactions, it still mainly focuses on the analysis of each independent event, and does not consider their mutual influence and role in the entire transaction execution sequence, which in turn affects the accuracy and reliability of performance analysis.

[0030] Therefore, based on the above analysis, it can be seen that when performing performance analysis, the interaction and influence of various events in the entire transaction execution sequence are not taken into account, which affects the accuracy and reliability of performance analysis. At present, there is no effective means to obtain the overall execution process of the transaction. Therefore, in the current performance analysis practice, how to generate the transaction execution sequence has become a technical problem that needs to be solved urgently.

[0031] Based on this technical problem, an embodiment of the present application provides a transaction processing method. When the method is implemented, in response to receiving a transaction processing request of a target transaction, at least one system thread event and at least one application thread event are obtained in the process of processing the target transaction, wherein the application thread event includes a transaction boundary event. In this way, the time range of the occurrence of the event can be captured by setting the transaction boundary event, so that events within the time range of the occurrence of the transaction boundary event and outside the time range of the occurrence of the system thread event can be excluded. In addition, by defining clear transaction boundary events and using them as reference points, event collection in the operating system and the application can be assisted, thereby avoiding the problem of missing events caused by incomplete synchronization of event collection between the operating system and the application, thereby ensuring the accuracy of the generated transaction execution sequence, and thereby improving the reliability and accuracy of the performance analysis of the operating system and / or application.

[0032] In order to facilitate the understanding of the embodiments of the present application, the application scenario of the transaction processing method provided in the embodiments of the present application is first briefly described. Figure 1 The following is a schematic diagram showing an application scenario of the transaction processing method provided in the embodiment of the present application. Figure 1 As shown, the application scenario includes a first client 110, a computing node 120, and a second client 130, and the computing node 120 communicates data with the first client 110 and the second client 130 respectively. The first client 110 and the second client 130 can be deployed on computing devices such as mobile phones, computers, and tablet computers. The specific form of the computing node 120 can be a physical machine, a virtual machine, or a container.

[0033] In an application example, a user sends a transaction processing request for a target transaction to a computing node 120 through a first client 110. After receiving the transaction processing request, the computing node 120 processes the target transaction according to the transaction processing request. In addition, the computing node 120 obtains at least one system thread event and at least one application thread event in the process of processing the target transaction, wherein the application thread event includes a transaction boundary event. In addition, it should be noted that the above-mentioned system thread event refers to an event related to a thread generated at the operating system level, and the above-mentioned application thread event refers to an event related to a thread generated at the application level. Afterwards, the computing node 120 generates a valid event sequence based on the above-mentioned at least one system thread event and at least one application thread event, wherein the valid events in the valid event sequence refer to system thread events and / or application thread events whose occurrence time is within the occurrence time range of the transaction boundary event, and are simultaneously within the occurrence time range of the system thread event. The computing node 120 generates a transaction execution sequence of the target transaction according to the above-mentioned valid event sequence and stores it. When the user needs to perform system performance analysis, the second client 130 sends a performance analysis request to the computing node 120. After receiving the performance analysis request, the computing node 120 obtains the transaction execution sequence corresponding to the performance analysis request and performs performance analysis based on the obtained transaction execution sequence. Exemplarily, the performance analysis may be an analysis of the execution delay of the operating system and / or application program.

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

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

[0036] Figure 2 A flowchart of a transaction processing method provided in an embodiment of the present application is shown, which can be applied to Figure 1 The computing node 120 in the application scenario shown. Figure 2 As shown, the method may include step S201, step S202 and step S203.

[0037] Step S201: in response to receiving a transaction processing request of a target transaction, obtaining at least one system thread event and at least one application thread event, wherein the application thread event includes a transaction boundary event.

[0038] Step S202: Generate a valid event sequence based on at least one system thread event and at least one application thread event, wherein the valid events in the valid event sequence refer to system thread events and / or application thread events whose occurrence times are within the occurrence time range of transaction boundary events and are simultaneously within the occurrence time range of system thread events.

[0039] Step S203: Generate a transaction execution sequence of the target transaction according to the valid event sequence, wherein the transaction execution sequence is used to perform performance analysis on the operating system and / or application program, where the application program refers to an application program that executes 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 computing node 120 in a distributed transaction processing system.

[0041] In one embodiment, after receiving a transaction processing request for a target transaction, the computing node 120 executes the target transaction through a corresponding thread. In the process of executing the target transaction through each thread, the generated system thread event and application thread event are obtained.

[0042] It should be noted that the system thread event refers to a thread-related event generated at the operating system level, and the system thread event can be obtained through 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.

[0043] Among them, the static tracing mechanism allows developers to declare some hook points at fixed locations in the operating system 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 operating system and executes user-defined operations to obtain the corresponding system thread events.

[0044] Alternatively, in some implementations, the collection of system thread events can also be implemented by inserting a stub into the source code of the operating system, that is, inserting code for obtaining system thread events into the source code of the operating system, and implementing the collection of system thread events by running the inserted code.

[0045] Exemplarily, the above-mentioned system thread event can be a thread scheduling event or a thread wake-up event. During implementation, other thread-related events can also be obtained according to actual needs. Here, several possible system thread events are only listed as examples, which is not a limitation to the application scheme. Usually, a thread scheduling event refers to an event in which a thread is scheduled into the CPU or an event in which a thread is scheduled out of the CPU. The above-mentioned thread wake-up event refers to a thread waking up another thread.

[0046] 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 identification (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.

[0047] It should be noted that the above application thread event refers to a thread-related event generated at the application level. Exemplarily, the above application thread event may include any one or more of the following event information: thread ID, thread name, timestamp when the event occurs, location information of a preset insertion point for obtaining the event, and call stack information corresponding to the event.

[0048] In one embodiment, the collection of application thread events can be achieved by plugging in. Usually, when the computing node 120 processes the target transaction, it needs to call a series of functions, which constitute the function call sequence for executing the target transaction, which can also be called the transaction execution path. Therefore, plugging points can be set in advance on the transaction execution path. Usually, the above plugging points can be located at the entrance of each function in the function call sequence, and plugging is performed at each plugging point. In this way, when the program runs to the plugging point, the plugging code is automatically executed to obtain the application thread event.

[0049] In addition, when the application is a binary file program, the collection of application thread events can also be achieved through the Uprobe technology. Among them, Uprobe is a user space probe technology that allows probes to be added at the entry and exit of specific functions in user space programs. These probes can be dynamically inserted into the compiled binary file without modifying the application source code to monitor its runtime behavior. Specifically, the addition of Uprobe can be achieved with the help of perf, eBPF or Java Virtual Machine (JVM).

[0050] Exemplarily, in one embodiment, the above-mentioned application thread event at least includes a transaction boundary event. The transaction boundary event is used to characterize the start and end of the target transaction. In an embodiment of the present application, the above-mentioned transaction boundary event may include a transaction start event of the target transaction. In this case, the transaction start event of the next transaction of the target transaction is used as the transaction end event of the target transaction, wherein the next transaction of the target transaction refers to a transaction whose transaction occurrence event is after the target transaction and adjacent to the target transaction. Alternatively, in another embodiment, the above-mentioned transaction boundary event may include both the transaction start event and the transaction end event of the target transaction.

[0051] Generally speaking, for a complete transaction, the transaction start event of the transaction is usually the event that the input / output (I / O) thread receives the transaction processing request, and the transaction end event is usually the event that the I / O thread feedbacks the transaction processing result. Of course, this is just an exemplary description of the above transaction boundary events. When actually implementing this solution, the specific events corresponding to the transaction boundary events can be set according to the actual application scenario.

[0052] In addition, it should be noted that in the embodiment of the present application, the collected application thread events include at least transaction boundary events. In addition to these, other application thread events may also be collected. When implementing this solution, other application thread events in addition to transaction boundary events may be set according to actual needs, which will not be described one by one here.

[0053] Based on the above description, it can be known that the application thread events and system thread events obtained in the embodiment of the present application all contain event timestamps, that is, the time when the event occurred. Therefore, in the above step S202, events can be filtered from at least one system thread event and at least one application thread event obtained in step S201 based on the time of occurrence of each event to obtain the above valid event sequence.

[0054] Exemplarily, the occurrence time range of the system thread event in the above step S202 refers to the time range formed by the earliest occurrence time and the latest occurrence time of the occurrence time corresponding to the above at least one system thread event. The occurrence time range of the above transaction boundary event refers to the time range formed by the occurrence time corresponding to the transaction start event of the target transaction and the occurrence time corresponding to the transaction end event of the target transaction. Alternatively, the occurrence time range of the above transaction boundary event may also refer to the time range formed by the occurrence time corresponding to the transaction start event of the target transaction and the occurrence time of the transaction start event of the next transaction of the target transaction.

[0055] In addition, it should be noted that, in an embodiment of the present application, when generating the above-mentioned valid event sequence, the above-mentioned at least one system thread event and at least one application thread event can be first screened based on the occurrence time range of the transaction boundary event, and then the screening result can be screened again based on the occurrence time range of the system thread event to obtain the above-mentioned valid event sequence. Alternatively, in another embodiment, the above-mentioned at least one system thread event and at least one application thread event can be first screened based on the occurrence time range of the system thread event, and then the screening result can be screened again based on the occurrence time range of the transaction boundary event to obtain the above-mentioned valid event sequence. Alternatively, in another embodiment, the above-mentioned at least one system thread event and at least one application thread event can be screened based on the occurrence time range of the transaction boundary event and the occurrence time range of the system thread event, respectively, and the intersection of the two screening results can be used as the valid event sequence.

[0056] After obtaining the valid event sequence, a transaction execution sequence of the target transaction is formed based on the valid event sequence. Exemplarily, in one implementation, the valid events may be sorted according to the order in which the events occur to obtain the transaction execution sequence.

[0057] In one embodiment, after obtaining the transaction execution sequence of the target transaction, the transaction execution sequence is stored for use in performance analysis of the operating system and / or application program, for example, analysis of transaction delay of the operating system and / or application program in executing the transaction.

[0058] The method provided in the embodiment of the present application, in response to receiving a transaction processing request of a target transaction, obtains at least one system thread event and at least one application thread event from the thread processing the target transaction during the processing of the target transaction, wherein the application thread event includes a transaction boundary event. In this way, the time range of event occurrence can be captured by setting the transaction boundary event, thereby excluding events within the time range of transaction boundary event occurrence and outside the time range of system thread event occurrence. In addition, by defining clear transaction boundary events and using them as reference points, event collection in the kernel and application can be assisted, thereby avoiding the problem of missing events caused by incomplete synchronization of event collection between the kernel and application, thereby ensuring the accuracy of the generated transaction execution sequence, thereby improving the reliability and accuracy of operating system and / or application performance analysis.

[0059] Normally, the execution of the target transaction may involve multiple threads, and the execution process may involve thread transfer operations, so there will inevitably be some cross-thread events. However, considering that some cross-thread transactions cannot be identified. Therefore, in an embodiment of the present application, in order to avoid the impact of the inability to identify cross-thread events on transaction analysis, the acquired at least one system thread event and at least one application thread event can be analyzed according to the thread dimension. In one embodiment, in the above step S202, generating a valid event sequence based on at least one system thread event and at least one application thread event may include the following steps: grouping at least one system thread event and at least one application thread event to obtain at least one event group, one event group corresponding to one thread; for any group of event groups, determining a valid event subsequence in the event group, and each valid event subsequence forms the above valid event sequence.

[0060] That is, in an embodiment of the present application, the at least one system thread event and the at least one application thread event can be grouped from the dimension of the thread, and a group of event groups can be obtained for one thread. Among them, the events in the event group can include application thread events and / or system thread events. It should be noted that, in an embodiment of the present application, the event information of the at least one system thread event and the at least one application thread event obtained contains the thread ID corresponding to the event, and the at least one system thread event and the at least one application thread event are grouped according to the thread ID.

[0061] In addition, it should be noted that there may be thread awakening events in the collected system thread events, such as the event of thread A awakening thread B. Thread A is called the awakening thread and thread B is called the awakened thread. For this type of event, when grouping events according to thread ID, the event can be grouped by the thread ID of the awakened thread. That is, for the event of thread A awakening thread B, the event is divided into the event group corresponding to thread B.

[0062] After obtaining the event groups corresponding to each thread, determine the valid event subsequences in each event group, so as to form the above-mentioned valid event sequence. For any group of event groups, the valid event subsequence corresponding to the event group refers to the inter-system and / or application thread events in the event group whose occurrence time is within the occurrence time range of the above-mentioned transaction boundary event and at the same time within the occurrence time range of the above-mentioned at least one system thread event.

[0063] In addition, it should be noted that when filtering any group of event groups based on the occurrence time range of transaction boundary events and the occurrence time range of system thread events respectively, the filtering based on the occurrence time range of transaction boundary events and the filtering based on the occurrence time range of system thread events can be performed simultaneously or in a certain order. The specific implementation process can be referred to the above description and will not be repeated here.

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

[0065] For example, in one implementation, it is assumed that the events included in any one event group include system thread event 1, system thread event 2, system thread event 3, system thread event 4, application thread event 1, and application thread event 2. It is assumed that the earliest occurrence time corresponding to the at least one system thread event is time 1, and the latest occurrence time is time 2. Therefore, the time range corresponding to the system thread event is time 1 to time 2, and the time range of the transaction boundary event of the target transaction is time 3 to time 4. It is assumed that the system thread event 1, system thread event 3, system thread event 4, and application thread event 1 are located between time 1 and time 2, and are located between time 3 and time 4. Then, the valid event subsequence corresponding to the event group is system thread event 1, system thread event 3, system thread event 4, and application thread event 1.

[0066] In an embodiment of the present application, at least one system thread event and at least one application thread event obtained are grouped according to the dimension of the thread, and the event group corresponding to each thread is obtained, and the valid event subsequence corresponding to each event group is determined, that is, the valid event subsequence corresponding to each thread is finally obtained, and the events related to the same thread can be grouped together, ensuring that all events related to the same thread are grouped together, thereby achieving efficient management and processing of these events, and then facilitating in-depth analysis of the operating system and / or application performance from the dimension of the thread. Grouping events according to the dimension of the thread not only simplifies data management, but also makes performance bottlenecks easier to identify and understand. In addition, by analyzing the events according to the dimension of the thread, it is only necessary to divide them according to the thread to which each event belongs, and there is no need to consider the boundary events of thread transfer in the cross-thread event. Therefore, it is also possible to avoid transaction analysis errors caused by the inability to identify the boundary events of the cross-thread event or the inaccurate identification of the boundary events of the cross-thread event, thereby improving the reliability and accuracy of the performance analysis.

[0067] In one embodiment, the above-mentioned determination of the valid event subsequence of the event group can be achieved through the following steps: determining the earliest occurrence time and the latest occurrence time among the occurrence times corresponding to at least one system thread event; filtering out each target event whose occurrence time is between the earliest occurrence time and the latest occurrence time from the event group; and filtering out valid events whose occurrence time is within the occurrence time range of the transaction boundary event from each target event to form the above-mentioned valid event subsequence.

[0068] Exemplarily, the earliest occurrence time and the latest occurrence time among the occurrence times corresponding to the system thread events can be determined by the following process: obtaining the timestamp of the event from the event information of the at least one system thread event, sorting the at least one system thread event in the order of the timestamps from earliest to latest, and taking the timestamp corresponding to the first system thread event as the earliest occurrence time, and taking the timestamp corresponding to the last system thread event as the latest occurrence time. Alternatively, in another embodiment, the earliest timestamp and the latest timestamp can also be directly searched from the event information of at least one system thread event, taking the earliest timestamp as the earliest occurrence time, and taking the latest timestamp as the latest occurrence time.

[0069] After obtaining the earliest occurrence time and the latest occurrence time, for any group of event groups, the target event whose occurrence time is within the range of the earliest occurrence time and the latest occurrence time is filtered out from the group of event groups, wherein the target event can be an application thread event or a system thread event. Then, the valid events whose occurrence time is within the range of the occurrence time of the transaction boundary event are filtered out from the target events to form a valid event subsequence corresponding to the event group.

[0070] In addition, it should be noted that this is only an exemplary example of a possible implementation method for determining a valid event subsequence of a time group. In addition, when implementing this solution, the event group can be preliminarily screened based on the time range of the transaction boundary event, and then the preliminary screening results can be further screened based on the earliest occurrence time and the latest occurrence time of the system thread event to obtain a valid event subsequence. Alternatively, when implementing this solution, the event group can be screened based on the earliest occurrence time and the latest occurrence time of the system thread event, and the event group can be screened based on the time range of the transaction boundary event at the same time, and the intersection of the two screening results can be used as the final valid event subsequence.

[0071] In this embodiment, each event group is initially screened based on the earliest and latest occurrence times of the system thread events. This step can not only accurately identify events that occur within a specific time window, but also reduce the number of events that need to be further screened based on the time range of transaction boundary events, effectively improving the efficiency of generating valid event subsequences.

[0072] Usually, during the execution of a transaction, there may be nested transactions. The so-called nested transactions refer to the process of executing another transaction within the scope of a transaction. This mechanism allows a large transaction to contain multiple small transactions, each of which can have its own commit or rollback operations, but in the end they are all committed or rolled back together with the outer transaction to which they belong. For example, assuming that the target transaction above is transaction A, transaction B is executed during the execution of transaction A, and transaction A ends only after transaction B ends. In this case, transaction A is considered to have transaction B nested in it.

[0073] Therefore, considering that other transactions may be nested during the execution of the target transaction, when generating the transaction execution sequence of the target transaction based on the valid event sequence, it is necessary to further filter out the events belonging to the target transaction from the valid event sequence. In addition, as introduced in the previous embodiment, the transaction boundary event of the target transaction may only include the transaction start event of the target transaction, or may also include the transaction start event and the transaction end event of the target transaction. For different situations of the above-mentioned transaction boundary events, the specific process of generating the transaction execution sequence of the target transaction is not the same. The following will introduce the situation in detail.

[0074] In one embodiment, when the transaction boundary event includes a transaction start event but does not include a transaction end event, the step S203 of generating the transaction execution sequence of the target transaction according to the valid event sequence may include the following steps: determining a target event segment corresponding to the target transaction from the valid event sequence, the target event segment refers to an event segment whose occurrence time is between the transaction start event of the target transaction and the next transaction start event, the next transaction start event refers to the first transaction start event in the valid event sequence whose occurrence time is after the transaction start event of the target transaction; determining the next event to be executed after each event in the target event segment; and generating the transaction execution sequence according to each event in the target event segment and the next event corresponding to each event.

[0075] For example, if the transaction boundary event includes the transaction start event of the target transaction but does not include the transaction end event of the target transaction, in this case, the transaction start event of the next transaction of the target transaction is used as the transaction end event of the target transaction. The next transaction described above refers to a transaction that occurs after the target transaction in the valid event sequence.

[0076] Generally, in a scenario where transactions are nested, there may be multiple transaction start events in the valid event sequence obtained above. In order to eliminate the impact of nested transactions, in this case, the segment between the transaction start event of the target transaction and the next adjacent transaction start event can be directly used as the target event segment belonging to the target transaction.

[0077] In this case, even if there is transaction nesting, the events between the transaction start event of the target transaction and the next transaction start event all belong to the target transaction. Therefore, the target event fragment of the target transaction can be formed based on the events between the transaction start event of the target transaction and the next adjacent transaction start event in the valid event sequence.

[0078] Among them, the event between the transaction start event of the target transaction and the adjacent next transaction start event refers to an event whose occurrence time is between a first occurrence time and a second occurrence time, the first occurrence time refers to the occurrence time of the transaction start event of the target transaction, and the second occurrence time refers to the event occurrence time of the adjacent next transaction start event.

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

[0080] For example, in one implementation, assuming that the target transaction is transaction A, and transaction B is nested and executed during the execution of transaction A, the collected transaction boundary events include the transaction start event of transaction A and the transaction start event of transaction B. Therefore, the events occurring between the transaction start event of transaction A and the transaction start event of transaction B can be determined as events belonging to transaction A.

[0081] After determining the target event segment corresponding to the target transaction, for each event in the target event segment, determine the next event that needs to be executed after the event, thereby generating the above-mentioned transaction execution sequence based on the target event segment and the next event that needs to be executed after each event in the target event segment.

[0082] Exemplarily, the events in the target event segment may be sorted in order of their occurrence time from earliest to latest, and the latter of two adjacent events is the next event that needs to be executed after the former event.

[0083] In an embodiment of the present application, for the situation where the transaction boundary event includes a transaction start event but does not include a transaction end event, the event fragment between the transaction start event and the adjacent next transaction start event is used as a target transaction fragment belonging to the target transaction, and the transaction execution sequence of the target transaction is generated based on the target transaction fragment. This can exclude events of nested transactions in the target transaction, avoid the influence of these nested transactions on the transaction execution sequence of the target transaction, ensure the accuracy and reliability of the generated transaction execution sequence of the target transaction, and help improve the reliability of subsequent performance analysis.

[0084] In one embodiment, the acquired transaction boundary event may include both the transaction start event of the target transaction and the transaction end event of the target transaction. In this case, it is not possible to simply regard the event between the transaction start event of the target transaction and the transaction end event of the target transaction as the target transaction fragment belonging to the target transaction, and there may be transaction events of nested transactions in between. Therefore, in order to eliminate the impact of nested transactions in this case. In an embodiment of the present application, in the case where the above-mentioned transaction boundary event includes both the transaction start event and the transaction end event, the above-mentioned step S203, generating the transaction execution sequence of the target transaction according to the valid event sequence, may include the following steps: reading each valid event in sequence according to the arrangement order of each valid event in the valid event sequence, and in the case where the read valid event is a transaction start event, adding the transaction start event to the stack data structure, and adding the transaction start event to the transaction cache area; in the case where the read valid event is a non-transaction boundary event, adding the read valid event to the transaction cache area, and the valid events in the transaction cache area are arranged according to the arrangement order of the events in the valid event sequence; in the case where the read valid event is a transaction end event, detecting the transaction end event and the stack data structure whether the transaction start event at the top of the stack belongs to the same transaction; popping the transaction start event belonging to the same transaction as the transaction end event from the stack data structure, and deleting the event fragment between the transaction start event at the top of the stack and the transaction end event belonging to the same transaction in the transaction cache area; when the read transaction end event and the transaction start event at the bottom of the stack in the stack data structure belong to the same transaction, taking the events in the transaction cache area between the transaction start event at the bottom of the stack and the transaction end event belonging to the same transaction as the transaction start event at the bottom of the stack as the target valid events corresponding to the target transaction; determining the next target valid event that needs to be executed after each target valid event among the target valid events; generating the above-mentioned transaction execution sequence according to each target valid event and the next target valid event that needs to be executed after each target valid event.

[0085] Among them, the stack is a linear data structure that follows the Last In First Out (LIFO) principle, that is, the last element added to the stack will be the first element to be removed. The two basic operations of the stack are "pushing" and "popping". The LIFO feature of the stack matches the logical order of processing nested transactions. For example, for a transaction start event, it can be pushed into the stack. If other transactions are nested inside this transaction, the transaction start events of these nested transactions will also be pushed into the stack. The LIFO feature of the stack ensures that the innermost transaction (the last one pushed into the stack) will be popped out first. When a transaction ends, the transaction start event that matches the transaction end event of the transaction will be popped out from the stack, symbolizing that the transaction has been removed from the execution queue until all transaction end events are matched.

[0086] In one implementation, each valid event in the valid event sequence can be read in sequence according to the occurrence time sequence of each event in the valid event sequence. For any valid event read, it is determined whether the valid event read is a transaction start event. If so, the transaction start event is added to the stack data structure, and the transaction start event is placed in the transaction cache area (buf); if the valid event read is not a transaction boundary event, that is, the valid event read is neither a transaction start event nor a transaction end event, then the valid event read is directly added to the transaction cache area. In addition, it should be noted that in the embodiment of the present application, each valid event added to the transaction cache area is arranged according to the order of the event in the valid event sequence. In the case that the valid event read is not a transaction start event but a transaction end event, the transaction end event is matched with the transaction start event at the top of the stack in the above stack data structure. If the transaction end event and the transaction start event at the top of the stack are the same event, the transaction start event is popped out of the stack data structure, and at the same time, each event between the transaction start event at the top of the stack and the transaction end event belonging to the same event in the transaction cache area is deleted, that is, the event belonging to the nested transaction in the valid event sequence is removed.

[0087] In addition, it should be noted that if the transaction end event and the transaction start event at the top of the stack do not belong to the same event, that is, they do not match, the transaction start event at the top of the stack will be removed from the stack data structure, and the next top element of the stack will be matched with the current transaction end event until a transaction start event that matches the transaction end event is determined.

[0088] In an embodiment of the present application, any transaction end event read needs to be matched in the stack data structure through the above process until the last transaction end event is read. If it matches the transaction start event at the bottom of the stack, the event between the transaction start event at the bottom of the stack and the matching transaction end event is obtained from the transaction cache area as the target event fragment belonging to the target transaction.

[0089] After determining the target event segment corresponding to the target transaction, for each event in the target event segment, determine the next event that needs to be executed after the event, thereby generating the above-mentioned transaction execution sequence based on the target event segment and the next event that needs to be executed after each event in the target event segment.

[0090] Exemplarily, the events in the target event segment may be sorted in order of their occurrence time from earliest to latest, and the latter of two adjacent events is the next event that needs to be executed after the former event.

[0091] In the embodiment of the present application, for the situation where the transaction boundary event includes both the transaction start event and the transaction end event, the transaction start event in the valid event sequence is added to the stack data structure, and the transaction start events are sequentially placed in the stack data structure in the order of the valid event sequence. In this way, for nested transactions, the transaction start event of the nested transaction is later than the transaction start event of the transaction to which it belongs, and therefore, it is located in the upper layer of the stack data structure. In this way, the last-in-first-out feature of the stack data structure is utilized to pop up the transaction start event at the top of the stack first, so that the events of the nested transactions in the target transaction can be excluded, thereby solving the problem of nesting other transactions in the target transaction, avoiding the influence of these nested transactions on the transaction execution sequence of the target transaction, ensuring the accuracy and reliability of the generated transaction execution sequence of the target transaction, and facilitating improving the reliability of subsequent performance analysis.

[0092] In an embodiment of the present application, the purpose of generating a transaction execution sequence is to subsequently perform a performance analysis of the operating system and / or application. Therefore, after generating the transaction execution sequence, the transaction execution sequence needs to be stored so that when the performance analysis is received later, the transaction execution sequence of each transaction that has been generated can be obtained. Therefore, in one embodiment, the method provided in the embodiment of the present application may also include the following steps: constructing a transaction table according to the execution order of the transaction execution sequence, the transaction table including each target valid event belonging to the target transaction, each target valid event including a target field, the target field is used to indicate the next target valid event that needs to be executed after the target valid event; storing the transaction table in a database, wherein a transaction table is stored in the database, and one transaction table corresponds to the transaction execution sequence of multiple transactions.

[0093] Exemplarily, the field name of the target field may be a next field, and the field value of the field may be an event identifier of the next target valid event that needs to be executed.

[0094] Therefore, in one implementation, in the transaction table of the target transaction, event information of each target valid event belonging to the target transaction may be recorded, wherein the above-mentioned next field is one of the information of the event information.

[0095] Alternatively, in another embodiment, the transaction table includes two types of tables, one is a first list for recording the event list corresponding to the transaction, and the other is a second list for recording the event information of each event in the event list. Exemplarily, for this situation, only the event list corresponding to the target transaction can be recorded in the first list, and then the event information corresponding to each event and the next field corresponding to each event can be recorded in the second list. Exemplarily, the information recorded in the first list may include the following information: transaction name (Name), thread ID to which the transaction start event belongs, overall transaction delay, transaction start timestamp, transaction end timestamp, ID of the first event to which the transaction belongs in the event table, and ID of the last event to which the transaction belongs in the event table. Then, the event information of each event from the ID of the first event to which the transaction belongs in the event table to the ID of the last event to which the transaction belongs in the event table is recorded in the second list.

[0096] Exemplarily, for each event information, the next field corresponding to each event can be recorded. In addition, any one or more of the following event information can be recorded: the thread ID corresponding to the event, the thread name corresponding to the event, the event name, the timestamp of the event, the call stack information corresponding to the application, the call stack information corresponding to the operating system, the CPU to which the event belongs, and the event type, etc. If the above event is a thread wakeup event, the thread ID of the waker also needs to be recorded.

[0097] In an embodiment of the present application, by storing the transaction execution sequence in the form of a transaction table and marking the next event to be executed for each event through the next field, the execution order and process of the transaction can be clearly displayed, thereby improving the transparency, traceability, manageability and performance of transaction processing, and facilitating subsequent performance analysis and problem tracking.

[0098] To facilitate understanding of the generation process of the above-mentioned transaction execution sequence in the embodiment of the present application, the following will be explained in conjunction with a specific embodiment. Figure 3 FIG. 2 shows a second flow chart of a transaction processing method provided in an embodiment of the present application. Figure 3 As shown, the method includes the following steps.

[0099] Step S301: In response to receiving a transaction processing request of a target transaction, obtaining at least one system thread event and at least one application thread event from a process of processing the target transaction, wherein the application thread event includes a transaction boundary event.

[0100] Step S302: Group the at least one system thread event and the at least one application thread event to obtain at least one event group, where one event group corresponds to one thread.

[0101] Step S303: For any event group, filter out target events whose occurrence time is between the earliest occurrence time and the latest occurrence time corresponding to at least one system thread event from the event group.

[0102] Step S304: Filter valid events whose occurrence time is within the occurrence time range of the transaction boundary event from each target event to obtain a valid event subsequence corresponding to the event group.

[0103] Step S305: Determine whether the transaction boundary event includes a transaction end event; if not, execute step S306; if included, execute step S307.

[0104] Step S306: For any valid event subsequence, according to the transaction start event of the target transaction and the adjacent next transaction start event, determine the target event segment corresponding to the target transaction from the valid event group sequence.

[0105] Step S307: For any valid event subsequence, read each valid event in sequence according to the arrangement order of each valid event in the valid event subsequence. When the valid event read is a transaction start event, add the transaction start event to the stack data structure. When the valid event read is a transaction end event, match it in the stack data structure based on the transaction end event to obtain the target event fragment corresponding to the target transaction.

[0106] The specific implementation process of obtaining the target event fragment corresponding to the target transaction by matching the transaction end event in the stack data structure can be referred to the description of the above embodiment and will not be repeated here.

[0107] Step S308: Determine the next event that needs to be executed after each event in the target transaction segment.

[0108] Step S309: construct a transaction table according to each event in the target event segment and the next event corresponding to each event, and store the transaction table in the database.

[0109] In one embodiment, when it is necessary to perform performance analysis on the operating system and / or application, the user can send a performance analysis request, and the computing device 120, upon receiving the performance analysis request, obtains the transaction execution sequence from the database to perform the corresponding performance analysis. Therefore, the method provided in the embodiment of the present application may also include the following steps: in response to receiving a performance analysis request for analyzing the target performance, obtain the transaction execution sequence to be analyzed from the database, the transaction execution sequence to be analyzed refers to the transaction execution sequence of the transaction used to perform the target performance analysis; based on the above performance analysis request, the transaction execution sequence to be analyzed is processed to obtain the performance analysis result for the target performance.

[0110] Exemplarily, the target performance may be a performance analysis related to execution delay, for example, the execution delay may be analyzed from the dimension of threads, the execution delay may be analyzed from the dimension of transaction types, or the proportion of the execution delay corresponding to each transaction fragment in the transaction execution sequence in the entire transaction execution delay may be analyzed, etc. For different target performances, the number of transaction execution sequences to be analyzed is different, and different analyses are performed.

[0111] In an embodiment of the present application, after receiving a performance analysis request, the corresponding transaction execution sequence to be analyzed is obtained from the database for corresponding analysis according to the target performance that needs to be analyzed. First, it is possible to obtain and analyze data in a targeted manner for different performances, thereby improving the accuracy of the performance analysis. In addition, the database stores the transaction execution sequence of each transaction. After receiving the performance analysis request, the performance analysis result can be quickly obtained by directly obtaining the transaction execution sequence to be analyzed from the database and processing the transaction execution sequence. This helps to timely discover and resolve performance bottlenecks and improve system efficiency.

[0112] In one embodiment, when the above-mentioned target performance is thread delay performance, the transaction execution sequence to be analyzed includes multiple transaction execution sequences. Accordingly, the above-mentioned processing of the transaction execution sequence to be analyzed based on the performance analysis request to obtain the performance analysis result for the target performance may include the following steps: screening out the transaction execution sequence to be analyzed of the transaction executed by each thread from the multiple transaction execution sequences; for any thread, generating delay analysis data of the thread according to the transaction execution sequence of the transaction executed by the thread, as the above-mentioned performance analysis result, the delay analysis data includes at least one of the following data: the number of transactions executed by the thread, the minimum transaction delay in the transactions executed by the thread, the maximum transaction delay in the transactions executed by the thread, the average transaction delay of the transactions executed by the thread, and the delay value corresponding to the preset transaction proportion in the transactions executed by the thread.

[0113] Exemplarily, the event information includes the thread ID to which the event belongs. Therefore, after obtaining multiple transaction execution sequences to be analyzed, for each transaction execution sequence to be analyzed, according to the thread ID to which the event belongs contained in the transaction execution sequence to be analyzed, the number of transactions executed by each thread ID is counted, and based on the transaction information executed by the thread ID, the execution delay data is counted, such as the minimum transaction delay, the maximum transaction delay, the average transaction delay, and the delay value corresponding to the preset transaction ratio, etc. Among them, the delay value corresponding to the preset transaction ratio can be the delay value corresponding to 30% of the transactions, the delay value corresponding to 50% of the transactions, the delay value corresponding to 70% of the transactions, the delay value corresponding to 90% of the transactions, the delay value corresponding to 99% of the transactions, the delay value corresponding to 99.9% of the transactions, etc.

[0114] For example, after obtaining the above delay analysis data, the transaction delay analysis result can be displayed on the interface of the device used by the user. For example, a possible display interface of the transaction delay analysis result is as follows: Figure 4 As shown. Figure 4 In the interface shown, one line corresponds to the delay analysis result of one thread.

[0115] In an embodiment of the present application, by analyzing the delay data corresponding to each thread according to the thread dimension and intuitively displaying the performance delay of each thread according to the thread dimension, it is helpful to quickly find the key threads that affect performance in a complex multi-threaded environment, so that it can be accurately identified which thread is the source of the performance bottleneck, so as to perform targeted performance optimization.

[0116] In one embodiment, in the case where the target performance is transaction delay performance, the transaction execution sequence to be analyzed includes transaction execution sequences of multiple transactions. Accordingly, the above-mentioned processing of the transaction execution sequence to be analyzed based on the performance analysis request to obtain the performance analysis result for the target performance may include the following steps: screening out the transaction execution sequence to be analyzed of each type of transaction from the multiple transaction execution sequences; for any type of transaction, generating delay analysis data of the type of transaction according to the transaction execution sequence of the type of transaction, as the above-mentioned performance analysis result, the delay analysis data includes at least one of the following data: the number of transactions of the type of transaction, the minimum transaction delay in the type of transaction, the maximum transaction delay in the type of transaction, the average transaction delay of the type of transaction, the delay value corresponding to the preset transaction proportion in the type of transaction, and the distribution data of the type of transaction in each delay interval.

[0117] In one embodiment, the delay performance analysis can also be performed according to different types of transaction classification. Exemplarily, the transaction information includes the transaction name. Therefore, after obtaining multiple transaction execution sequences to be analyzed, for each transaction execution sequence to be analyzed, the transaction type corresponding to the transaction execution sequence to be analyzed is determined according to the transaction name included in the transaction execution sequence to be analyzed, and then the number of transactions corresponding to each type of transaction is counted. Generally, the transaction name refers to the specific representation of the transaction, which is used to distinguish different transaction instances, and the transaction type is a classification of transaction functions or operation scopes, etc. The transaction name usually includes information about the transaction type. Therefore, based on the transaction type, the transaction type to which the transaction belongs can be analyzed. After obtaining the number of transactions corresponding to each type of transaction, based on the transaction information corresponding to the transaction type, the execution delay data is counted. For example, for the data of the target type, the above-mentioned transaction information can be the number of transactions of this type, the minimum transaction delay in this type of transaction, the maximum transaction delay in this type of transaction, the average transaction delay of this type of transaction, the delay value corresponding to the preset transaction proportion in this type of transaction, and the distribution data of this type of transaction in each delay interval. The delay value corresponding to the preset transaction ratio may be the delay value corresponding to 30% of transactions, the delay value corresponding to 50% of transactions, the delay value corresponding to 70% of transactions, the delay value corresponding to 90% of transactions, the delay value corresponding to 99% of transactions, the delay value corresponding to 99.9% of transactions, etc. The delay intervals may be the delay intervals obtained by dividing the overall delay range corresponding to such transactions, and the distribution data corresponding to the delay intervals may be the transaction ratios within each delay interval.

[0118] For example, after obtaining the above delay analysis data, the transaction delay analysis result can be displayed on the interface of the device used by the user. For example, a possible display interface of the transaction delay analysis result is as follows: Figure 5 As shown. Figure 5 In the shown interface, one row corresponds to one type of delay analysis result.

[0119] Among them, in the selected Figure 5 After any line in Figure 6 The distribution of this type of transaction in each delay interval is shown in Figure 1. Figure 6 In the interface shown, each row corresponds to the transaction ratio of a delay interval.

[0120] In an embodiment of the present application, by analyzing the delay data corresponding to each transaction according to the transaction dimension and intuitively displaying the performance delay of each type of transaction according to the thread dimension, it is helpful to accurately analyze the delay of each transaction.

[0121] In one embodiment, when the above-mentioned target performance is the delay performance of the target transaction, the above-mentioned transaction execution sequence to be analyzed is the transaction execution sequence of the target transaction. Accordingly, the above-mentioned processing of the transaction execution sequence to be analyzed based on the performance analysis request to obtain the performance analysis result for the target performance may include the following steps: dividing the transaction execution sequence to be analyzed 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; calculating the ratio of the execution time of the event segment to the total execution time of the target transaction as the above-mentioned performance analysis result.

[0122] Exemplarily, the preset division rule may be that any two adjacent events are divided into one event segment, or any three adjacent 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.

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

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

[0125] Assume that the obtained transaction execution sequence to be analyzed 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.

[0126] The above transaction execution sequence to be analyzed is divided into segments, and the obtained event segments can be:

[0127] Event fragment 1: target application thread event 2, system thread event 1;

[0128] Event fragment 2: system thread event 1, target application thread event 4;

[0129] Event fragment 3: target application thread event 4, target application thread event 5;

[0130] Event fragment 4: target application thread event 5, target application thread event 3;

[0131] Event fragment 5: target application thread event 3, target application thread event 1.

[0132] 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 event difference between the event timestamp of target application thread event 4 and system thread event 1. For event fragment 3, 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 4, the corresponding execution time may be the event difference between the event timestamp of target application thread event 3 and the event timestamp of target application thread event 5. For event fragment 5, 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.

[0133] After the execution time corresponding to each event segment is obtained, the ratio of the execution time of each event segment to the total execution time of the target transaction is calculated as the above performance analysis result.

[0134] That is, in the embodiment of the present application, by calculating the ratio of the execution time of each event fragment to the total execution time of the target, the impact of each event fragment on the total delay of the target transaction can be reflected as a whole.

[0135] In one embodiment, the influence of each delay influencing factor that affects the transaction execution delay on the overall transaction delay can also be analyzed separately, so as to facilitate the intuitive reflection of the influence of each delay influencing factor from the overall perspective. Therefore, in an embodiment of the present application, when the above-mentioned target performance is the delay performance of the target transaction, the above-mentioned transaction execution sequence to be analyzed is the transaction execution sequence of the target transaction, and accordingly, the above-mentioned performance analysis request is based on the processing of the transaction execution sequence to be analyzed to obtain the performance analysis result for the target performance, which can include the following steps: dividing the transaction execution sequence to be analyzed into multiple event segments according to any two adjacent events; for any event segment, according to the event type of the event whose occurrence time in the event segment is after the event, determining the delay influencing factor corresponding to the event segment; for any delay influencing factor, counting the superimposed execution time corresponding to each event segment belonging to the delay influencing factor, and calculating the ratio of the above-mentioned superimposed execution time to the total execution time of the target transaction as the above-mentioned performance analysis result.

[0136] Exemplarily, if the transaction execution sequence to be analyzed includes event 1, event 2, event 3 and event 4, it is divided into multiple event fragments according to any two adjacent events. The obtained event fragments can be: event fragment 1: event 1, event 2; event fragment 2: event 2, event 3; event fragment 3: event 3, event 4.

[0137] The event type may include a thread wake-up event or a thread scheduling event, and the thread scheduling event may include a thread being scheduled into a CPU event or a thread being scheduled out of a CPU event. The delay influencing factors may include scheduling delay, resource waiting delay, and on-CPU delay.

[0138] In one embodiment, for any event segment, the delay influencing factor causing the delay of the event segment can be determined based on the event type of an event that occurs later in the event segment. Exemplarily, if an event that occurs later is an event that is scheduled into a CPU, the delay influencing factor corresponding to the event segment can be determined to be a CPU scheduling delay. If an event that occurs later is a thread wake-up event, and the resource of the wake-up event is any one of a network card network, a timer, or a hard disk I / O, the delay influencing factor corresponding to the event segment can be determined to be a resource waiting delay, and the remaining event segments are all considered to be on-CPU delays by the corresponding delay influencing factors.

[0139] Exemplarily, after determining the delay influencing factors corresponding to each event segment, the event segments corresponding to each delay influencing factor are counted. For any delay influencing factor, the superimposed execution time corresponding to the event segment is calculated, wherein the superimposed execution time represents the sum of the execution times of the event segments corresponding to the delay influencing factor. The calculation method of the execution time of each event segment can refer to the description of the aforementioned embodiment, which will not be repeated here.

[0140] After obtaining the superimposed execution time corresponding to each delay influencing factor, the ratio of the superimposed execution time corresponding to each delay influencing factor to the total execution time of the target transaction is calculated as the influence degree of the corresponding delay influencing factor on the total execution delay of the target transaction.

[0141] In an embodiment of the present application, by calculating the degree of influence of each delay influencing factor on the total execution delay of the target transaction, the degree of influence of each delay influencing factor on the overall delay performance of the target transaction can be quantified, thereby helping to prioritize issues that have the greatest impact on the delay performance of the target transaction and improve optimization efficiency.

[0142] In addition, in one embodiment, the delay performance of a specified thread or a specified transaction can also be analyzed. Exemplarily, a user can input a transaction analysis request carrying a thread identifier and a transaction name. After receiving the transaction analysis request, the computing node 120 obtains a transaction execution sequence corresponding to the thread identifier and the transaction name. Based on the transaction execution sequence, the scheduling time, waiting time, off-CPU time, CPU running (on-CPU) time, etc. of the thread are calculated, as well as the percentage of the above-mentioned various times in the overall delay impact. Among them, the scheduling time refers to the time it takes for a thread to change from a ready state to a running state. Specifically, it is the time when the scheduler of the operating system selects a thread to execute and allocates the CPU to the thread. The waiting time refers to the total time that the thread cannot be executed and is in a waiting state due to some reasons. These reasons may include waiting for the completion of an I / O operation, waiting for a lock or semaphore, waiting for other threads to complete certain tasks, etc. The waiting event may include I / O waiting time, network waiting time, sleep time, interrupt occupancy, idle waiting time, etc.

[0143] Exemplarily, after obtaining the above-mentioned delay analysis data, the transaction delay analysis results can be displayed on the interface of the device used by the user. In a feasible display interface, one row corresponds to a transaction running instance, and the transaction running instance corresponds to the thread identifier and transaction name in the transaction analysis request.

[0144] In addition, in the embodiments of the present application, the following analysis can also be performed: arranging in order of delay size, arranging in reverse order of delay size, using a search box to filter transactions with delays greater than a threshold, using a search box to filter transactions with delays less than a threshold, and so on.

[0145] In one embodiment, the transaction execution process and dependency relationship can also be analyzed based on the transaction execution sequence of a transaction. Therefore, in the case where the target performance is a dependency relationship between events, the transaction execution sequence to be analyzed is the transaction execution sequence of the target transaction. Accordingly, the performance analysis request is based on the performance analysis request to process the transaction execution sequence to be analyzed to obtain a performance analysis result for the target performance. The following steps can be included: each event is read in sequence according to the order of each event in the transaction execution sequence to be analyzed. In the case where the read event is a CPU scheduling event and the next event of the event is a thread wake-up event, the thread wake-up event is judged according to the function information in the call stack information of the thread wake-up event whether it is a resource-related wake-up event. A resource-related wake-up event refers to a wake-up event that is satisfied by resources. The thread wake-up event implemented has different functions corresponding to different resources; when it is determined that the thread wake-up event is a non-resource-related wake-up event, it is determined that the event occurring between the scheduled CPU event and the thread wake-up event belongs to the wake-up thread of the thread wake-up event; when it is determined that the thread wake-up event is a resource-related wake-up event, the read event is a non-scheduled CPU event, or the read event is a scheduled CPU event and the next event of the event is a non-thread wake-up event, the thread to which the event belongs is determined according to the event source of the event; a dependency graph of the events corresponding to the target transaction is generated according to the execution order of each event in the transaction execution sequence and the thread to which each event belongs.

[0146] Exemplarily, for a thread wake-up event, for example, an event in which thread A wakes up thread B, thread A is the wake-up thread and thread B is the awakened thread.

[0147] Normally, for thread wake-up events, most of them are events such as thread A waking up thread B. However, a small number of thread wake-up events are thread wake-ups triggered by actions that satisfy certain resources, for example, a certain hardware interrupt action triggers the wake-up of thread B. In this case, the call stack of the thread wake-up event can be used to determine whether the thread wake-up event is a resource-related wake-up event. Specifically, the wake-up is actually implemented through a series of layer-by-layer function calls, and this layer-by-layer call relationship is the call stack. Therefore, in an embodiment of the present application, it is possible to determine whether the thread wake-up event is a resource-related wake-up event by determining whether the call stack of the thread wake-up event contains the pre-set functions to be executed by each resource. If the call stack contains the corresponding function, the thread wake-up event is considered to be a resource-related wake-up event, otherwise it is an ordinary thread A waking up thread B. In addition, it should be noted that different resources correspond to different functions.

[0148] In one embodiment, the events are read in sequence according to the order of the events in the transaction execution sequence of the target transaction. Each time an event is read, assuming that the event read is recorded as event A, the event type corresponding to event A is determined. If the judgment result indicates that event A is not a CPU scheduling event, the event source of event A is marked as the thread to which event A belongs. If the judgment result indicates that event A is a CPU scheduling event, the next event is read from the transaction execution sequence of the target transaction, assuming that the next event read is event B, and the event type of the event B read is determined. If the judgment result indicates that event B is not a thread wake-up event, the thread to which event B belongs is marked according to the event source of event B, and the thread to which event A belongs is marked according to the event source to which event A belongs. If the judgment result indicates that event B is a thread wake-up event, whether event B is a resource-related wake-up event is identified based on the function information in the call stack of event B. If so, the thread to which event B belongs is marked according to the resource corresponding to event B. If event B is a non-resource-related wake-up event, the wake-up thread of event B is determined, as well as the event occurrence time T1 corresponding to event B and the event occurrence time T2 corresponding to event A. Events with occurrence times between T1 and T2 and belonging to the wake-up thread of event B are obtained from all acquired transaction execution sequences, and they are sorted to obtain a subsequence of event A, and the thread to which it belongs is determined to be the wake-up thread of event B. The above process of sequentially reading events in the event sequence and processing them according to the above process is executed for any acquired event sequence.

[0149] After obtaining the subsequences belonging to each event and the threads corresponding to each event in the subsequence, the events corresponding to the target transaction are displayed according to the execution order indicated by the transaction execution sequence to be analyzed, and each event is displayed under the thread to which the event belongs. Figure 7 The interface shown shows the dependencies between the events of the target transaction. Figure 7 The functions of each part in the figure are described as follows.

[0150] Display information 1: used to describe the execution delay statistics of all threads of the transaction, such as total delay, maximum delay, minimum delay, average delay, etc.

[0151] Display information 2: used to describe the execution delay statistics of a thread selected by the user's cursor, for example, the delay time of the thread, the proportion of the total delay, etc.

[0152] exist Figure 7In , the first column represents the timestamp, and each row in the first column represents the timestamp information of the event corresponding to the row. Except for the first column, the remaining columns represent threads, and the column in which the event is located represents the thread in which the event occurs. Figure 7 The application thread event 1, system event 2, system event 3, etc. in the display all represent events. In a feasible implementation, the foreground color of non-system events can be represented by yellow, and the events selected by the user's cursor can be marked with blue. The "+" in front of system event 6 represents a folding mark. If it is '+', it can be expanded, and the expanded content depends on the execution process of the thread. If it is '-', it cannot be expanded. Display information 3 represents the delay between two adjacent events and the proportion of the delay to the total delay, that is, the delay between the two events corresponding to the two ends of the vertical line. In system event 4 (3), the number in the brackets represents the CPU where system event 4 occurs.

[0153] In the embodiment of the present application, by analyzing the dependencies between the events of the target transaction, it is helpful to understand the mutual influence and sequence of events during the transaction execution process, thereby identifying performance bottlenecks or optimization points.

[0154] Exemplarily, in one implementation, the event sequence within a specified time range on a single CPU may also be analyzed. For example, the event sequence within a specified time range on a single CPU may be sorted, and so on.

[0155] In addition, in the embodiment of the present application, the following analysis can be further performed: for example, more application thread events are obtained to further subdivide the on-cpu time; the more thread events obtained can be system call events, through which the overhead of system calls in transaction execution delay can be accurately quantified. It can also be a processor interrupt (Inter-Processor Interrupt, IPI event), through which the dependency between threads is enhanced, etc.

[0156] To facilitate understanding of the transaction processing method provided in the embodiment of the present application, Figure 8 The third flowchart of the transaction processing method provided in the embodiment of the present application is shown as follows: Figure 3As shown, first, after receiving the transaction processing request sent by the first client, the computing device processes the target transaction based on the operating system and application of the computing device. In the process of processing the target transaction, at least one system thread event generated by the operating system and at least one application thread event generated by the application are obtained, and the application thread event includes at least a transaction boundary event. The computing device stores the obtained at least one system thread event and at least one application thread event in a database for storage. The computing device obtains at least one system thread event and at least one application thread event of the target transaction from the database, generates a valid event sequence based on the at least one system thread event and the at least one application thread event, generates a physical execution flow of the target transaction according to the valid event sequence, and constructs a transaction table according to the execution order of the transaction execution sequence, and stores the transaction table in the database, wherein one transaction table corresponds to the transaction execution sequence of one transaction. After receiving the performance analysis request sent by the second client, the computing device obtains the transaction execution sequence to be analyzed from the database, performs corresponding performance analysis based on the transaction execution sequence to be analyzed, and sends it to the second client for display.

[0157] 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 transaction processing device, Fig. 9 The module composition diagram of the transaction processing device provided in the embodiment of the present application is shown as follows: Fig. 9 As shown, the device includes: a first acquisition module 901, which is used to respond to receiving a transaction processing request of a target transaction, and in the process of processing the target transaction, obtain at least one system thread event and at least one application thread event, wherein the application thread event includes a transaction boundary event; a first generation module 902, which is used to generate a valid event sequence based on the at least one system thread event and the at least one application thread event, wherein the valid events in the valid event sequence refer to system thread events and / or application thread events whose occurrence times are within the occurrence time range of the transaction boundary event, and are also within the occurrence time range of the system thread event; a second generation module 903, which is used to generate a transaction execution sequence of the target transaction according to the valid event sequence, wherein the transaction execution sequence is used to perform performance analysis on an operating system and / or an application, wherein the application refers to an application that executes the target transaction.

[0158] Optionally, in one embodiment, the above-mentioned first generation module 902 is specifically used to: group the at least one system thread event and the at least one application thread event to obtain at least one group of event subsequences, and a group of event subsequences corresponds to one thread; for any group of event subsequences, determine the valid event subsequences in the event subsequences, and each of the valid event subsequences forms the valid event sequence.

[0159] Optionally, in one embodiment, the above-mentioned first generation module 902 is further specifically used to: determine the earliest occurrence time and the latest occurrence time corresponding to the at least one system thread event according to the occurrence time of each system thread event in the event subsequence; filter out each target event whose occurrence time is between the earliest occurrence time and the latest occurrence time from the event subsequence; and filter out valid events whose occurrence time is within the occurrence time range of the transaction boundary event from each of the target events to form the valid event subsequence.

[0160] Optionally, in one embodiment, when the transaction boundary event includes a transaction start event but does not include a transaction end event, the second generation module 903 is specifically used to: determine a target event segment corresponding to the target transaction from the valid event sequence, the target event segment refers to an event segment whose occurrence time is between the transaction start event and the next transaction start event, and the next transaction start event refers to the first transaction start event in the valid event sequence whose occurrence time is after the transaction start event; determine the next event that needs to be executed after each event in the target event segment; and generate the transaction execution sequence according to each event in the target event segment and the next event corresponding to each event.

[0161] Optionally, in one embodiment, when the transaction boundary event includes a transaction start event and a transaction end event, the second generation module 903 is specifically used to: read each valid event in sequence according to the arrangement order of each valid event in the valid event sequence, and when the valid event read is a transaction start event, add the transaction start event to the stack data structure, and add the transaction start event to the transaction cache area; when the valid event read is a non-transaction boundary event, add the valid event read to the transaction cache area, and arrange the valid events in the transaction cache area according to the arrangement order of the events in the valid event sequence; when the valid event read is a transaction end event, detect whether the transaction end event and the transaction start event at the top of the stack in the stack data structure belong to the same transaction; popping the transaction start event belonging to the same transaction as the transaction end event from the stack data structure, and deleting the event fragments between the transaction start event at the top of the stack and the transaction end event belonging to the same transaction in the transaction cache area; when the read transaction end event and the transaction start event at the bottom of the stack in the stack data structure belong to the same transaction, taking the events between the transaction start event at the bottom of the stack and the transaction end event belonging to the same transaction as the transaction start event at the bottom of the stack in the transaction cache area as the target event fragments corresponding to the target transaction; determining the next event to be executed after each event in the target event fragment;

[0162] The transaction execution sequence is generated according to each event in the target event segment and the next event corresponding to each event.

[0163] Optionally, in one embodiment, the device provided by the embodiment of the present application also includes the following modules: a construction module, used to construct a transaction table according to the execution order of the transaction execution sequence, the transaction table including each target valid event belonging to the target transaction, each target valid event including a target field, and the target field is used to indicate the next target valid event that needs to be executed after the target valid event; a storage module, used to store the transaction table in a database, the database stores a transaction table, and one transaction table corresponds to the transaction execution sequence of multiple transactions.

[0164] Optionally, in one embodiment, the device provided by the embodiment of the present application also includes the following modules: a second acquisition module, used to obtain a transaction execution sequence to be analyzed from the database in response to receiving a performance analysis request for analyzing target performance, wherein the transaction execution sequence to be analyzed refers to a transaction execution sequence of transactions used to perform the target performance analysis; an analysis module, used to process the transaction execution sequence to be analyzed based on the performance analysis request to obtain a performance analysis result for the target performance.

[0165] Optionally, in one embodiment, when the target performance is thread delay performance, the transaction execution sequence to be analyzed includes multiple transaction execution sequences, and the above-mentioned analysis module is specifically used to: filter out the transaction execution sequence to be analyzed of the transactions executed by each thread from the multiple transaction execution sequences; for any thread, generate delay analysis data of the thread according to the transaction execution sequence to be analyzed of the transactions executed by the thread, as the performance analysis result, the delay analysis data includes at least one of the following data: the number of transactions executed by the thread, the minimum transaction delay in the transactions executed by the thread, the maximum transaction delay in the transactions executed by the thread, the average transaction delay of the transactions executed by the thread, and the delay value corresponding to a preset transaction proportion in the transactions executed by the thread.

[0166] Optionally, in one embodiment, when the target performance is transaction delay performance, the transaction execution sequence to be analyzed includes transaction execution sequences of multiple transactions, and the above-mentioned analysis module is specifically used to: filter out the transaction execution sequence to be analyzed of the target type transaction from the multiple transaction execution sequences, and the target type transaction refers to the transaction of the type of delay performance to be analyzed; generate delay analysis data of the target type transaction according to the transaction execution sequence to be analyzed of the target type transaction, and as the performance analysis result, the delay analysis data includes at least one of the following data: the number of transactions of the target type transaction, the minimum transaction delay in the target type transaction, the maximum transaction delay in the target type transaction, the average transaction delay of the target type transaction, the delay value corresponding to the preset transaction proportion in the target type transaction, and the distribution data of the target type transaction in each delay interval.

[0167] Optionally, in one embodiment, the target performance is the delay performance of the target transaction, and the transaction execution sequence obtained from the database is the transaction execution sequence of the target transaction. The above-mentioned analysis module is specifically used to: divide the transaction execution sequence to be analyzed 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 start event and the event timestamp of the end event in the event segment; calculate the ratio of the execution time of the event segment to the total execution events of the target transaction as the performance analysis result.

[0168] Optionally, in one embodiment, when the target performance is the delay performance of the target transaction, the transaction execution sequence to be analyzed is the transaction execution sequence of the target transaction, and the analysis module is specifically used to: divide the transaction execution sequence to be analyzed into multiple event segments according to a group of any two adjacent events; for any event segment, determine the delay influencing factor corresponding to the event segment according to the event type of the event whose occurrence time in the event segment is later than that of the subsequent event; for any delay influencing factor, count the superimposed execution time corresponding to each event segment belonging to the delay influencing factor, and calculate the ratio of the superimposed execution time to the total execution time of the target transaction as the performance analysis result.

[0169] Optionally, in one embodiment, when the target performance is the dependency relationship between events corresponding to the target transaction, the transaction execution sequence to be analyzed is the transaction execution sequence of the target transaction, and the analysis module is specifically used to: read each event in sequence according to the order of the events in the transaction execution sequence, and when the read event is a CPU scheduling event and the next event of the event is a thread wake-up event, determine whether the thread wake-up event is a resource-related wake-up event based on function information in the call stack of the thread wake-up event. A resource-related wake-up event refers to an event in which a thread wake-up is realized by satisfying resources, and different resources correspond to different function; in the case where it is determined that the thread wake-up event is a non-resource-related wake-up event, determine that the event occurring between the scheduled CPU event and the thread wake-up event belongs to the wake-up thread of the thread wake-up event; in the case where it is determined that the thread wake-up event is a resource-related wake-up event, the read event is a non-scheduled CPU event, or the read event is a scheduled CPU event and the next event of the event is a non-thread wake-up event, determine the thread to which the event belongs according to the event source of the event; generate a dependency graph of the events corresponding to the target transaction according to the execution order of each event in the transaction execution sequence and the thread to which each event belongs.

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

[0171] Fig.10 FIG. 1 is a block diagram of an electronic device used to implement an embodiment of the present application. Fig.10As 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.

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

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

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

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

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

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

[0178] It should be understood that the above processor can be a processor (Central Processing Unit, CPU), and can also be other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), application-specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It is worth noting that the processor can be a processor that supports the Advanced RISC Machines (ARM) architecture.

[0179] 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).

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

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

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

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

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

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

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

[0187] 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 transaction processing method, characterized in that: include: In response to receiving a transaction processing request of a target transaction, obtaining at least one system thread event and at least one application thread event in the process of processing the target transaction, wherein the application thread event includes a transaction boundary event; Generate a valid event sequence based on the at least one system thread event and the at least one application thread event, wherein the valid events in the valid event sequence refer to system thread events and / or application thread events whose occurrence times are within the occurrence time range of the transaction boundary event and are also within the occurrence time range of the system thread event; generating a transaction execution sequence of the target transaction according to the valid event sequence, wherein the transaction execution sequence is used to perform performance analysis on an operating system and / or an application program, wherein the application program refers to an application program that executes the target transaction; The method further includes: constructing a transaction table according to the execution order of the transaction execution sequence, wherein the transaction table includes each target valid event belonging to the target transaction, and storing the transaction table in a database, wherein the database stores a transaction table, and one transaction table corresponds to the transaction execution sequence of multiple transactions; In response to receiving a performance analysis request for analyzing target performance, obtaining a transaction execution sequence to be analyzed from the database, wherein the transaction execution sequence to be analyzed refers to a transaction execution sequence of transactions used to perform the target performance analysis; and processing the transaction execution sequence to be analyzed based on the performance analysis request to obtain a performance analysis result for the target performance.

2. The method according to claim 1, characterized in that: The generating a valid event sequence based on the at least one system thread event and the at least one application thread event comprises: Grouping the at least one system thread event and the at least one application thread event to obtain at least one event group, where one event group corresponds to one thread; For any set of event groups, a valid event subsequence corresponding to the event group is determined, and each of the valid event subsequences forms the valid event sequence.

3. The method according to claim 2, characterized in that The determining of a valid event subsequence of the event group comprises: Determine the earliest occurrence time and the latest occurrence time among the occurrence times corresponding to the at least one system thread event; Filter each target event whose occurrence time is between the earliest occurrence time and the latest occurrence time from the event group; Valid events whose occurrence times are within the occurrence time range of the transaction boundary event are screened from each of the target events to form the valid event subsequence.

4. The method according to claim 1, characterized in that In a case where the transaction boundary event includes a transaction start event but does not include a transaction end event, generating a transaction execution sequence of the target transaction according to the valid event sequence includes: Determine a target event segment corresponding to the target transaction from the valid event sequence, wherein the target event segment refers to an event segment occurring between a transaction start event of the target transaction and a next transaction start event, and the next transaction start event refers to the first transaction start event occurring after the transaction start event of the target transaction in the valid event sequence; Determine the next event to be executed after each event in the target event segment; The transaction execution sequence is generated according to each event in the target event segment and the next event corresponding to each event.

5. The method according to claim 1, characterized in that In the case where the transaction boundary event includes a transaction start event and a transaction end event, generating the transaction execution sequence of the target transaction according to the valid event sequence includes: Reading each valid event in sequence according to the arrangement order of each valid event in the valid event sequence, and if the read valid event is a transaction start event, adding the transaction start event to a stack data structure, and adding the transaction start event to a transaction cache area; In the case that the read valid event is a non-transaction boundary event, the read valid event is added to the transaction cache area, and the valid events in the transaction cache area are arranged according to the arrangement order of events in the valid event sequence; In the case where the read valid event is a transaction end event, detecting whether the transaction end event and the transaction start event at the top of the stack in the stack data structure belong to the same transaction; Popping a transaction start event belonging to the same transaction as the transaction end event from the stack data structure, and deleting an event segment between the transaction start event at the top of the stack and the transaction end event belonging to the same transaction in the transaction cache area; When the read transaction end event and the transaction start event at the bottom of the stack in the stack data structure belong to the same transaction, taking the events between the transaction start event at the bottom of the stack and the transaction end event belonging to the same transaction as the transaction start event at the bottom of the stack in the transaction cache area as target event fragments corresponding to the target transaction; Determine the next event to be executed after each event in the target event segment; The transaction execution sequence is generated according to each event in the target event segment and the next event corresponding to each event.

6. The method according to claim 1, characterized in that Each of the target valid events includes a target field, and the target field is used to indicate the next target valid event that needs to be executed after the target valid event.

7. The method according to claim 1, characterized in that In the case where the target performance is thread latency performance, the transaction execution sequence to be analyzed includes multiple transaction execution sequences, and the processing of the transaction execution sequence to be analyzed based on the performance analysis request to obtain a performance analysis result for the target performance includes: Filtering out a transaction execution sequence of a transaction executed by each thread from the multiple transaction execution sequences; For any thread, delay analysis data of the thread is generated according to a transaction execution sequence of transactions executed by the thread. The delay analysis data includes at least one of the following data as the performance analysis result: the number of transactions executed by the thread, the minimum transaction delay in transactions executed by the thread, the maximum transaction delay in transactions executed by the thread, the average transaction delay in transactions executed by the thread, and a delay value corresponding to a preset transaction ratio in transactions executed by the thread.

8. The method according to claim 1, characterized in that In the case where the target performance is transaction latency performance, the transaction execution sequence to be analyzed includes transaction execution sequences of multiple transactions, and the processing of the transaction execution sequence to be analyzed based on the performance analysis request to obtain a performance analysis result for the target performance includes: Filtering out the transaction execution sequences to be analyzed of each type of transaction from the multiple transaction execution sequences; For any type of transaction, delay analysis data of the type of transaction is generated according to the transaction execution sequence to be analyzed of the type of transaction. As the performance analysis result, the delay analysis data includes at least one of the following data: the number of transactions of the type of transaction, the minimum transaction delay in the type of transaction, the maximum transaction delay in the type of transaction, the average transaction delay of the type of transaction, the delay value corresponding to the preset transaction proportion in the type of transaction, and the distribution data of the type of transaction in each delay interval.

9. The method according to claim 1, characterized in that: In a case where the target performance is the latency performance of the target transaction, the to-be-analyzed transaction execution sequence is the transaction execution sequence of the target transaction, and the processing of the to-be-analyzed transaction execution sequence based on the performance analysis request to obtain a performance analysis result for the target performance includes: Dividing the transaction execution sequence to be analyzed into multiple 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; The ratio of the execution time of the event fragment to the total execution time of the target transaction is calculated as the performance analysis result.

10. The method according to claim 1, characterized in that In a case where the target performance is the latency performance of the target transaction, the to-be-analyzed transaction execution sequence is the transaction execution sequence of the target transaction, and the processing of the to-be-analyzed transaction execution sequence based on the performance analysis request to obtain a performance analysis result for the target performance includes: Dividing the transaction execution sequence to be analyzed into multiple event segments according to a group of any two adjacent events; For any event segment, determining the delay influencing factor corresponding to the event segment according to the event type of the event in the event segment that occurs later than the event; For any delay influencing factor, the superimposed execution time corresponding to each event segment belonging to the delay influencing factor is counted, and the ratio of the superimposed execution time to the total execution time of the target transaction is calculated as the performance analysis result.

11. The method according to claim 1, characterized in that: In a case where the target performance is a dependency relationship between events corresponding to a target transaction, the transaction execution sequence to be analyzed is a transaction execution sequence of the target transaction, and the processing of the transaction execution sequence to be analyzed based on the performance analysis request to obtain a performance analysis result for the target performance includes: Reading each event in sequence according to the order of each event in the transaction execution sequence, and in the case where the read event is a CPU scheduling event and the next event of the event is a thread wake-up event, judging whether the thread wake-up event is a resource-related wake-up event according to function information in a call stack of the thread wake-up event, wherein a resource-related wake-up event refers to an event of thread wake-up realized by satisfying resources, and different resources correspond to different functions; In the case where it is determined that the thread wake-up event is a non-resource-related wake-up event, determining that an event occurring between the scheduled CPU event and the thread wake-up event belongs to the wake-up thread of the thread wake-up event; In any one of the cases where it is determined that the thread wake-up event is a wake-up event related to a resource, the read event is a non-scheduled CPU event, or the read event is a scheduled CPU event and the next event of the event is a non-thread wake-up event, determining the thread to which the event belongs according to the event source of the event; A dependency graph of events corresponding to the target transaction is generated according to the execution order of each event in the transaction execution sequence and the thread to which each event belongs.

12. 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 11 when executing the computer program.

13. 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 11 is implemented.

14. 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 11.

Images