A method, medium, and computing device for outputting a record file

Abstract

The embodiments disclosed in the specification provide a method, medium and computing device for outputting a record file. The processing flow of a distributed processing system is split into processing steps that can be monitored on a single device node. Meanwhile, the event recording mechanism of JFR is used to record the starting execution time point, input data and ending execution time point corresponding to the processing steps executed on the single device node, forming a JFR record file. In this way, the JFR record file corresponding to the processing steps executed on each device node is obtained, which is equivalent to obtaining the running record of the distributed processing system, and the performance of the distributed processing system can be analyzed accordingly.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification relate to the field of information technology, and in particular, to a method, medium and computing device for outputting a record file. BACKGROUND

[0002] A distributed processing system refers to a processing system deployed on at least two device nodes. Specifically, different system modules of the processing system are deployed in different device nodes, and the different system modules communicate with each other through a network between the device nodes, and each system module completes a processing flow through cooperation.

[0003] In engineering practice, it is often necessary to analyze the performance of a distributed processing system. The performance analysis can be understood as analyzing the efficiency of the distributed processing system in executing a processing flow, so as to optimize the distributed processing system according to the analysis result. The prerequisite for being able to analyze the performance of the distributed processing system is to obtain the running record of the distributed processing system.

[0004] Therefore, there is a need for a technical solution capable of obtaining the running record of the distributed processing system. SUMMARY

[0005] Embodiments of the present specification provide a method, medium and computing device for outputting a record file, so as to obtain the running record of the distributed processing system for performance analysis.

[0006] Embodiments of the present specification provide technical solutions as follows:

[0007] According to a first aspect of embodiments of the present specification, a method for outputting a record file is provided, wherein the distributed processing system includes at least two system modules, different system modules are running in virtual machines deployed on different device nodes, and each system module executes at least one processing step of a processing flow; for each processing step, an operation of executing the processing step is defined as an event required to be recorded by a Java Flight Recorder (JFR).

[0008] The method includes:

[0009] After monitoring that the system module running in the corresponding virtual machine starts to execute a processing step, a starting execution time point corresponding to the processing step is recorded, and input data corresponding to the processing step is recorded; after monitoring that the system module ends to execute the processing step, an ending execution time point corresponding to the processing step is recorded.

[0010] A JFR record file containing the starting execution time point, the input data and the ending execution time point corresponding to the processing step is outputted.

[0011] According to a second aspect of the embodiments of the present specification, a performance analysis method based on the JFR record file output by the method of the first aspect is provided, comprising:

[0012] obtaining the JFR record file corresponding to each processing step of the processing flow of the distributed processing system;

[0013] For each processing step, determining the consumption time corresponding to the processing step according to the start execution time point and the end execution time point recorded in the JFR record file corresponding to the processing step;

[0014] determining one or more processing steps with a corresponding consumption time exceeding an abnormal value as an abnormal processing step;

[0015] For each abnormal processing step, performing performance analysis, including: using the input data in the JFR record file corresponding to the abnormal processing step to perform execution testing on the abnormal processing step in a test environment simulated based on the distributed processing system, so as to determine the code problem of the system module responsible for executing the abnormal processing step in the distributed processing system according to the test result.

[0016] According to a third aspect of the embodiments of the present specification, a distributed processing system is provided, comprising at least two system modules, different system modules running in virtual machines deployed on different device nodes, each system module executing at least one processing step of a processing flow; for each processing step, defining the operation of executing the processing step as an event required to be recorded by a virtual machine flight recorder JFR;

[0017] After monitoring that the system module running in the corresponding virtual machine starts to execute a processing step, recording the start execution time point corresponding to the processing step and recording the input data corresponding to the processing step; after monitoring that the system module ends to execute the processing step, recording the end execution time point corresponding to the processing step; outputting the JFR record file containing the start execution time point, the input data and the end execution time point corresponding to the processing step.

[0018] According to a fourth aspect of the embodiments of the present specification, a performance analysis device based on the JFR record file output by the method of the first aspect is provided, comprising:

[0019] an obtaining module, which obtains the JFR record file corresponding to each processing step of the processing flow of the distributed processing system;

[0020] a first determining module, which, for each processing step, determines the consumption time corresponding to the processing step according to the start execution time point and the end execution time point recorded in the JFR record file corresponding to the processing step;

[0021] The second determination module identifies one or more processing steps whose consumption time exceeds the abnormal value as abnormal processing steps.

[0022] The performance analysis module performs performance analysis for each exception handling step, including: in a test environment simulated based on the distributed processing system, using the input data in the JFR record file corresponding to the exception handling step, performing an execution test on the exception handling step, so as to determine the code problems of the system module responsible for executing the exception handling step in the distributed processing system based on the test results.

[0023] According to a fifth aspect of several embodiments of this specification, a computing device is provided, including a memory and a processor; the memory is configured to store computer instructions executable on the processor, and the processor is configured to implement the method of the first aspect when executing the computer instructions.

[0024] According to a sixth aspect of several embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect.

[0025] In the above technical solution, the processing flow of the distributed processing system is broken down into multiple processing steps. The method of breaking down these steps must ensure that each system module can execute at least one processing step. Thus, the event logging mechanism of the Java Flight Recorder (JFR) of the Java Virtual Machine deployed on a single device node can be utilized. A processing step can be defined as an event that the JFR needs to record. This allows the JFR to record the time when a system module in the virtual machine starts executing a processing step, the time when it ends executing a processing step, and the input data acquired during the execution of the processing step. The JFR will then create a JFR log file from these event records and output it.

[0026] The above technical solution breaks down the processing flow of a distributed processing system into processing steps that can be monitored on individual device nodes. Simultaneously, the event logging mechanism of JFR (Junior Function Records) is used to record the start time, input data, and end time of each processing step executed on a single device node, forming a JFR log file. In this way, obtaining the JFR log files corresponding to the processing steps executed on each device node is equivalent to obtaining the runtime record of the distributed processing system, which can be used for performance analysis.

[0027] Furthermore, because the processing flow of a distributed processing system is broken down into multiple processing steps, performance analysis of the distributed processing system can be performed not only from a global perspective, but also at a finer granularity. This means that performance analysis can be performed on the process of executing a single processing step for a single system module, making it easier to discover potential code problems in a single system module and to optimize that single system module accordingly. Attached Figure Description

[0028] Figure 1 This is a method for outputting log files provided in this disclosure.

[0029] Figure 2 An exemplary processing flow diagram is provided.

[0030] Figure 3 This is a flowchart illustrating a performance analysis method provided in this disclosure.

[0031] Figure 4 This is a schematic diagram of the structure of a distributed processing system provided in this disclosure.

[0032] Figure 5 This is a schematic diagram of the structure of a computer-readable storage medium provided in this disclosure.

[0033] Figure 6 This is a schematic diagram of the structure of a computing device provided in this disclosure.

[0034] In the accompanying drawings, identical or corresponding reference numerals denote identical or corresponding parts. Any number of elements in the drawings is for illustrative purposes only and not for limitation, and any naming is for distinction only and has no limiting meaning. Detailed Implementation

[0035] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0036] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0037] In a distributed processing system, different system modules are deployed on different device nodes. These modules communicate using the network between the device nodes and collaborate to complete the processing flow. The various system modules in a distributed processing system typically use the Remote Procedure Call (RPC) protocol for network interaction.

[0038] Performance analysis of a distributed processing system can generally be understood as analyzing the efficiency of its execution of processing flows. The purpose of performance analysis is to identify code issues that affect processing efficiency, allowing for optimization and improvement of the distributed processing system.

[0039] For centralized processing systems, performance analysis can typically be performed from a resource utilization perspective. This involves analyzing the system's utilization of hardware resources (such as CPU, memory, and bandwidth) to assess its processing efficiency. However, distributed processing systems often involve network interactions between system modules deployed across different device nodes. The resource overhead generated by these network interactions is difficult to quantify, making it challenging to use a resource utilization perspective for global performance analysis. In particular, some distributed processing systems are implemented using multi-link network communication models managed by multiplexers (such as the Reactor model). The processing flow may involve multiple switching between business threads and communication threads within a single system module, as well as the sending and receiving of multiple data packets, resulting in resource overhead that is difficult to quantify.

[0040] In other words, because the processing flow of a distributed processing system involves network interactions between node devices, resulting in resource overhead that is difficult to quantify, it is difficult to perform performance analysis on a distributed processing system as a global business execution entity.

[0041] To this end, this disclosure breaks down the processing flow of a distributed processing system into multiple processing steps. The method of breaking down these steps must ensure that each system module can execute at least one processing step. In this way, the event logging mechanism of the Java Virtual Machine's Java FR (Java Freeloader) deployed on a single device node can be utilized. A processing step can be defined as an event that the JFR needs to record, allowing the JFR to record the time when a system module in the virtual machine starts executing a processing step, the time when it ends executing a processing step, and the input data acquired during the execution of the processing step. The JFR will then create a JFR log file from these event records and output it.

[0042] The above technical solution breaks down the processing flow of a distributed processing system into processing steps that can be monitored on individual device nodes. Simultaneously, the event logging mechanism of JFR (Junior Function Records) is used to record the start time, input data, and end time of each processing step executed on a single device node, forming a JFR log file. In this way, obtaining the JFR log files corresponding to the processing steps executed on each device node is equivalent to obtaining the runtime record of the distributed processing system, which can be used for performance analysis.

[0043] Furthermore, by breaking down the processing flow of a distributed processing system into multiple processing steps, performance analysis can be performed not only globally but also at a finer granularity. This means performance analysis can be conducted on the execution of individual processing steps within a single system module, making it easier to identify potential code issues in individual modules and enabling targeted optimization. Moreover, for distributed processing systems operating in different business scenarios, the processing flow can be specifically broken down according to the characteristics of that business scenario. Adopting a processing step breakdown method suitable for the performance analysis of the distributed processing system within that specific business scenario can yield better performance analysis results.

[0044] The above technical solution will be described in detail below with reference to the accompanying drawings.

[0045] Figure 1 This disclosure provides a method for outputting a log file, comprising the following steps:

[0046] S100: After detecting that the system module running in the corresponding virtual machine has started to execute a processing step, record the start time of the processing step and the input data corresponding to the processing step.

[0047] The distributed processing system described in this disclosure may include at least two system modules, each running in a virtual machine deployed on a different device node. A distributed processing system can be understood as a software system or program whose different system modules (which can be understood as software modules or program modules) are distributed across virtual machines on different node devices. These system modules can interact using the network communication capabilities between the node devices and collaborate to complete the entire processing flow. The processing flow of the distributed processing system can be the core business process that the distributed processing system needs to execute.

[0048] Figure 1 The illustrated method can be applied to the Virtual Machine Flight Recorder (JFR) of a virtual machine deployed on each device node. JFR is a tool supported by the Java Virtual Machine (JVM), essentially a process running within the JVM. Any program behavior occurring within the JVM can be treated as an event by JFR, which can record the event's occurrence time, end time, and input data.

[0049] In one or more embodiments provided in this disclosure, leveraging the characteristics of the JFR, for each processing step, the operation performing that processing step is defined as an event that the virtual machine flight recorder (JFR) needs to record. Decomposing the processing flow of a distributed processing system into multiple processing steps requires ensuring that each system module can execute at least one processing step. In some embodiments, the processing steps executed by different system modules may be the same or different.

[0050] In some embodiments, logic can be added to the code of the system module so that the system module can trigger a start execution notification each time a processing step begins execution. The start execution notification may carry an identifier of the processing step or an identifier of the processing flow to which the processing step belongs. JFR can detect the notification, treat the detection of the notification as an event occurrence, and take the time point of the notification detection as the start execution time point corresponding to the processing step.

[0051] Of course, in other embodiments, JFR can also monitor the point in time when a system module begins to execute a processing step in other ways.

[0052] When a system module executes a processing step, it acquires the input data for that step. The system module then processes this input data to obtain the output data for that step. The input data for the processing step can be understood as traffic in a distributed processing system.

[0053] It is understandable that at least part of the output data of the previous processing step in the same processing flow may be at least part of the input data of the next processing step; that is, there may be context dependencies between processing steps. Of course, the input data of a certain processing step may also not depend on the output data of previous processing steps, but may be obtained from other sources.

[0054] JFR can monitor the input data acquired by a system module when it executes a certain processing step, and record the input data as the input data corresponding to that processing step.

[0055] S102: After detecting that the system module has finished executing the processing step, record the end execution time point corresponding to the processing step.

[0056] In some embodiments, logic can be added to the code of the system module so that the system module can trigger an execution termination notification when each processing step is completed. The execution termination notification may carry an identifier of the processing step or an identifier of the processing flow to which the processing step belongs. JFR can detect the notification, regard the detection of the notification as the end of the event, and take the time point of the notification detection as the execution termination time point corresponding to the processing step.

[0057] Of course, in other embodiments, JFR can also monitor the point in time when a system module finishes executing a processing step in other ways.

[0058] S104: Output a JFR record file containing the start execution time, input data, and end execution time corresponding to this processing step.

[0059] JFRs typically record event information into JFR log files and write them to the corresponding storage of the virtual machine. In the embodiments of this disclosure, the JFR log file includes the start execution time, input data, and end execution time corresponding to the processing steps.

[0060] Furthermore, in some embodiments, each system module can also execute at least one processing step of other processing flows. To distinguish processing steps from different processing flows, JFR can record the flow identifier corresponding to a processing step after detecting that a system module running in the corresponding virtual machine has started executing that step; the flow identifier corresponding to the processing step is the identifier of the processing flow to which that processing step belongs. Accordingly, JFR can output a JFR log file containing the flow identifier corresponding to the processing step, the start execution time, the input data, and the end execution time.

[0061] It should be noted that since the system module runs in the Java Virtual Machine, the input data obtained by the system module during the execution of processing steps generally has the Java heap object format. Considering that subsequent performance testing will also be conducted using heap processing steps in a test environment, the format of the input data corresponding to the processing steps recorded in the JFR log file, while not in the heap object format, needs to be in a format that can be restored to the heap object format. Therefore, in some embodiments, the system module can use a serialization tool to serialize the heap object format input data into a binary stream. The JFR can detect this binary stream and record it as input data.

[0062] Furthermore, in some embodiments, the distributed processing system may include a client module and a server module. The set of processing steps executed by the client module includes: processing steps for network communication with the server module, at least one processing step for implementing business logic, encoding processing steps, decoding processing steps, serialization processing steps, and deserialization processing steps. The set of processing steps executed by the server module may include: processing steps for network communication with the client module, at least one processing step for implementing business logic, encoding processing steps, decoding processing steps, serialization processing steps, and deserialization processing steps.

[0063] Figure 2 An exemplary processing flow diagram is provided. Figure 2 As shown, a distributed processing system can include a client module and a server module. The client module can be deployed on the user device, and the server module can be deployed on the server. Figure 2 The processing steps executed by the client module and the server module are shown in the diagram. The processing steps of the distributed processing system are as follows: the client module executes the processing step of calling the server module via RPC, the processing step of implementing business logic 1, the processing step of implementing data serialization, the processing step of implementing business logic 2, and the processing step of implementing data encoding; after the client module sends a request to the server module, the server module executes the processing steps of implementing data decoding, implementing business logic 3, implementing data deserialization, implementing business logic 4, implementing data serialization, implementing business logic 5, and implementing data encoding; after the server module sends feedback to the client module, the client module executes the processing steps of implementing data decoding, implementing business logic 6, implementing data deserialization, and implementing business logic 7. Figure 2 The execution order of each processing step is shown, as well as the contextual dependencies between each processing step.

[0064] Figure 3 This is a flowchart illustrating a performance analysis method provided in this disclosure, including the following steps:

[0065] S300: Obtain the JFR record files corresponding to each processing step in the processing flow of the distributed processing system.

[0066] Figure 3 The illustrated process flow can be applied to performance analysis programs independent of the distributed processing system. The performance analysis program can read the JFR record files corresponding to each processing step of the process flow from the storage (e.g., the disks of the device nodes) of the virtual machines deployed on each device node of the distributed processing system.

[0067] In some embodiments, each processing step may be executed multiple times, and the JFR may record the processing step multiple times, outputting multiple JFR record files.

[0068] S302: For each processing step, determine the execution time corresponding to the processing step based on the start and end execution times recorded in the JFR record file corresponding to the processing step.

[0069] It's easy to understand that for a JFR log file, the duration between the start and end execution times recorded in the log file can be the consumption time of the corresponding processing steps.

[0070] In addition, in some other embodiments, for each processing step, the start and end execution times recorded in the multiple JFR record files corresponding to the processing step can be used to determine the multiple durations consumed in executing the processing step, and the average duration can be calculated; the average duration can be used as the consumption duration corresponding to the processing step.

[0071] S304: Identify one or more processing steps whose corresponding processing time exceeds the abnormal value as abnormal processing steps.

[0072] In some embodiments, outlier values ​​can be set based on practical experience.

[0073] In some embodiments, the processing steps can be sorted from longest to shortest according to their corresponding processing time. The processing step with the longest processing time can be designated as the exception handling step, or the first few processing steps can be designated as exception handling steps. It's easy to understand that, assuming the first N processing steps are designated as exception handling steps, the exception value can be a value between the processing time of the (N+1)th processing step and the processing time of the Nth processing step (inclusive).

[0074] S306: Perform performance analysis for each exception handling step.

[0075] In step S306, the process of performing anomaly analysis may be as follows: In a test environment built based on the distributed processing system, the input data in the JFR record file corresponding to the anomaly handling step is used to perform an execution test on the anomaly handling step, so as to determine the code problem of the system module responsible for executing the anomaly handling step in the distributed processing system based on the test results.

[0076] In other words, the performance analysis program needs to ensure that the parameters of the simulated test environment are the same as the parameters of the runtime environment of the system module responsible for executing the exception handling step, and that the context on which the exception handling step depends exists in the simulated test environment. Testers can then identify code problems in the system module responsible for executing the exception handling step within the distributed processing system based on the test results, and optimize the code of that system module.

[0077] In some embodiments, after optimizing the system module responsible for executing the exception handling step, the input data in the JFR record file corresponding to the exception handling step can be used to perform an execution test on the exception handling step in a test environment built on the basis of the optimized distributed processing system. This is so that the optimization effect on the system module responsible for executing the exception handling step can be analyzed based on the test results (i.e., the performance difference of the system module before and after optimization can be compared).

[0078] In the embodiments provided in this disclosure, the performance analysis of the exception handling step is performed using the JFR record file corresponding to the exception handling step. In fact, the test environment is simulated by an automated test tool (performance analysis program) with various normal, peak and abnormal loads. Based on the corresponding system module, the input data (traffic replay function) corresponding to the exception handling step is used to test the execution of the exception handling step and analyze its various performance indicators during the execution process.

[0079] In addition, performance analysis tools can also include similar... Figure 2 The processing flowchart shown is presented to the testers, and the processing time for each processing step and the contextual dependencies between processing steps are marked in the processing flowchart.

[0080] Figure 4This is a schematic diagram of the structure of a distributed processing system provided in this disclosure, including at least two system modules. Different system modules run in virtual machines deployed on different device nodes. Each system module executes at least one processing step of the processing flow. For each processing step, the operation of executing the processing step is defined as an event that the virtual machine flight recorder JFR needs to record.

[0081] After detecting that a system module running in the corresponding virtual machine has started executing a processing step, record the start time of the processing step and the input data for that processing step; after detecting that the system module has finished executing the processing step, record the end time of the processing step; output a JFR log file containing the start time, input data and end time of the processing step.

[0082] Figure 4 An example is given of a distributed processing system comprising four system modules, which are deployed on different device nodes.

[0083] This disclosure also provides a computer-readable storage medium, such as Figure 5 As shown, the medium 140 stores a computer program that, when executed by a processor, implements the methods of embodiments of this disclosure.

[0084] This disclosure also provides a computing device, including a memory and a processor; the memory is used to store computer instructions that can be executed on the processor, and the processor is used to implement the methods of the embodiments of this disclosure when executing the computer instructions.

[0085] Figure 6 This is a schematic diagram of the structure of a computing device provided in this disclosure. The computing device 15 may include, but is not limited to, a processor 151, a memory 152, and a bus 153 connecting different system components (including the memory 152 and the processor 151).

[0086] The memory 152 stores computer instructions that can be executed by the processor 151, enabling the processor 151 to perform the methods of any embodiment of this disclosure. The memory 152 may include a random access memory (RAM) 1521, a cache memory 1522, and / or a read-only memory (ROM) 1523. The memory 152 may also include a program tool 1525 having a set of program modules 1524, including but not limited to: an operating system, one or more application programs, other program modules, and program data. One or more combinations of these program modules may include an implementation of a network environment.

[0087] Bus 153 may include, for example, a data bus, an address bus, and a control bus. The computing device 15 can also communicate with external devices 155 via I / O interface 154, such as a keyboard or a Bluetooth device. The computing device 150 can also communicate with one or more networks via network adapter 156, such as a local area network (LAN), a wide area network (WAN), or a public network. As shown, network adapter 156 can also communicate with other modules of the computing device 15 via bus 153.

[0088] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0089] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0090] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0091] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0092] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0094] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0095] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0096] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the functions specified in one or more boxes. In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0097] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0098] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0099] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0100] The foregoing has described several embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0101] The terminology used in the various embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the various embodiments of this specification. The singular forms “a,” “described,” and “the” as used in the various embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0102] It should be understood that although the terms first, second, third, etc., may be used to describe various information in various embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of various embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0103] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the method embodiments are basically similar to the method embodiments and are therefore described simply; relevant parts can be referred to the descriptions of the method embodiments. The method embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. When implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware. Alternatively, some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0104] The above description is merely a preferred embodiment of the various embodiments of this specification and is not intended to limit the various embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the various embodiments of this specification should be included within the protection scope of the various embodiments of this specification.

Claims

1. A method for outputting a log file, wherein, The distributed processing system includes at least two system modules, which run in virtual machines deployed on different device nodes. The processing flow of the distributed processing system is divided into multiple processing steps. Each system module executes at least one processing step of the processing flow. For each processing step, the operation of executing the processing step is defined as an event that the virtual machine flight recorder (JFR) needs to record. The method includes: After detecting that a system module running in the corresponding virtual machine has started executing a processing step, the start time of the processing step is recorded, and the input data of the processing step is also recorded. The input data is used for performance testing in the test environment. After detecting that the system module has finished executing the processing step, the end time of the processing step is recorded. The output is a JFR record file containing the start execution time, input data, and end execution time corresponding to the processing step, for use in the performance analysis of the distributed processing system.

2. The method as described in claim 1, wherein the distributed processing system includes a client module and a server module, and the set of processing steps executed by the client module includes: The processing steps for network communication with the server module include at least one processing step for implementing business logic, an encoding processing step, a decoding processing step, a serialization processing step, and a deserialization processing step. The set of processing steps executed by the server module includes: processing steps for network communication with the client module, at least one processing step for implementing business logic, encoding processing steps, decoding processing steps, serialization processing steps, and deserialization processing steps.

3. The method as described in claim 1, wherein, Each system module also performs at least one processing step in other processing flows; The method further includes: After detecting that a system module running in the corresponding virtual machine has started executing a processing step, the process identifier corresponding to the processing step is recorded; the process identifier corresponding to the processing step is the identifier of the processing flow to which the processing step belongs; The output is a JFR log file containing the start time, input data, and end time of the corresponding processing step, including: The output is a JFR record file containing the process identifier, start time, input data, and end time of the processing step.

4. A performance analysis method for JFR record files output by the method according to any one of claims 1-3, comprising: Obtain the JFR record files corresponding to each processing step in the processing flow of the distributed processing system; For each processing step, the execution time is determined based on the start and end times recorded in the JFR record file corresponding to that processing step. One or more processing steps whose processing time exceeds the outlier value are identified as outlier processing steps. For each exception handling step, a performance analysis is performed, including: in a test environment simulated based on the distributed processing system, using the input data in the JFR log file corresponding to the exception handling step, an execution test is performed on the exception handling step, so as to determine the code problems of the system module responsible for executing the exception handling step in the distributed processing system based on the test results.

5. The method as described in claim 4, obtaining the JFR record files corresponding to each processing step of the processing flow of the distributed processing system, including: Obtain multiple JFR record files corresponding to each processing step in the processing flow of the distributed processing system; For each processing step, the execution time consumed by that step is determined based on the start and end times recorded in the corresponding JFR record file, including: For each processing step, based on the start and end execution times recorded in the multiple JFR record files corresponding to that processing step, determine the multiple durations consumed in executing that processing step, and calculate the average duration; The average duration is taken as the consumption time corresponding to this processing step.

6. The method of claim 4, further comprising, after determining that there is a code problem in the system module responsible for executing the exception handling step in the distributed processing system, the method includes: Optimize the system module responsible for executing this exception handling step; In a test environment built on the optimized distributed processing system, the input data in the JFR log file corresponding to the exception handling step is used to execute the exception handling step for testing. Based on the test results, the optimization effect on the system module responsible for executing the exception handling step can be analyzed.

7. A distributed processing system, comprising at least two system modules, the different system modules running in virtual machines deployed on different device nodes, the processing flow of the distributed processing system being divided into multiple processing steps, each system module executing at least one processing step of the processing flow; for each processing step, the operation of executing the processing step is defined as an event that the virtual machine flight recorder (JFR) needs to record; After detecting that a system module running in the corresponding virtual machine has started executing a processing step, the start time of the processing step and the input data for the processing step are recorded. The input data is used for performance testing in the test environment. After detecting that the system module has finished executing the processing step, the end time of the processing step is recorded. A JFR log file containing the start time, input data and end time of the processing step is output for performance analysis of the distributed processing system.

8. A performance analysis apparatus for a JFR record file output by the method of any one of claims 1-3, comprising: The acquisition module retrieves the JFR record files corresponding to each processing step in the processing flow of the distributed processing system. The first determining module determines the execution time of each processing step based on the start and end execution times recorded in the JFR record file corresponding to that processing step. The second determination module identifies one or more processing steps whose consumption time exceeds the abnormal value as abnormal processing steps. The performance analysis module performs performance analysis for each exception handling step, including: in a test environment simulated based on the distributed processing system, using the input data in the JFR record file corresponding to the exception handling step, performing an execution test on the exception handling step, so as to determine the code problems of the system module responsible for executing the exception handling step in the distributed processing system based on the test results.

9. A computing device, comprising a memory and a processor; the memory being configured to store computer instructions executable on the processor, the processor being configured to implement the method of any one of claims 1 to 6 when executing the computer instructions.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1 to 6.

Images