Performance transaction analysis method and device based on call chain and computer equipment

Abstract

The invention provides a performance transaction analysis method and device based on a call chain, a storage medium and computer equipment, and the method comprises the steps: determining a target scene when performance transaction is detected, and determining at least one scene interface according to the target scene; for each scene interface, tracing and recording all downstream services by taking the scene interface as a starting point to obtain a call chain corresponding to the scene interface; and when the call chain of each scene interface is determined, generating a call graph of the target scene. In this way, the complete calling relation graph about the target scene can be obtained. And then performing service de-duplication operation on the call graph, determining at least one call domain and a service corresponding to each call domain, and analyzing the reason of performance transaction to obtain an analysis result. The reason for performance transaction of the target scene is comprehensively analyzed through all the call domains and the services contained in the call domains, and the mutual influence among multiple call levels is considered, so that the problem root can be comprehensively and accurately positioned from the complete call relationship.

Description

Technical Field

[0001] The present application relates to the technical field of system analysis, and in particular to a method, device, storage medium and computer equipment for performance analysis based on a call chain. Background Art

[0002] In today's software system performance analysis field, as the system architecture becomes increasingly complex, the analysis of performance indicators such as response time is becoming more and more critical. Accurate analysis of performance indicators can be beneficial to the stable operation and optimization of the system. Currently, analysis can be performed by gradually tracing the call chain from the entry point to try to locate the link that may cause performance changes.

[0003] However, the current performance variance analysis cannot fully grasp the indirect correlation effects between various call levels, and is prone to missing potential root causes of problems across multiple layers, and is thus unable to accurately determine the overall performance bottleneck, resulting in performance variance analysis that is not accurate and comprehensive enough. Summary of the invention

[0004] The purpose of this application is to solve at least one of the above-mentioned technical defects, especially the technical defect that the performance change analysis in the prior art cannot fully grasp the indirect correlation effects between the various call levels, and is easy to miss the potential root causes of problems across multiple layers, and thus cannot accurately determine the overall performance bottleneck, resulting in the technical defect that the performance change analysis is not accurate and comprehensive enough.

[0005] In a first aspect, the present application provides a performance variation analysis method based on a call chain, the method comprising:

[0006] When a performance change is detected, determining a target scenario where the performance change occurs, and determining at least one scenario interface according to the target scenario;

[0007] For each scenario interface, trace back and record all downstream services starting from the scenario interface to obtain the call chain corresponding to the scenario interface;

[0008] When the call chain of each scenario interface is determined, a call graph of the target scenario is generated according to the call chain of each scenario interface;

[0009] A service deduplication operation is performed on the call graph to determine at least one call domain and a service corresponding to each call domain, and the cause of the performance change is analyzed based on the services corresponding to each call domain to obtain an analysis result.

[0010] In one embodiment, tracing back and recording all downstream services starting from the scenario interface to obtain a call chain corresponding to the scenario interface includes:

[0011] Determine the services included in the next call level based on the scenario interface and enter the next call level;

[0012] In the current call level, the services included in the next call level are determined according to the services included in the current call level, and the next call level is entered until the services included in the determined next call level are empty, and the services in each call level and their call relationships are recorded;

[0013] According to the services and their calling relationships in each calling level, a calling chain corresponding to the scene interface is generated.

[0014] In one embodiment, generating the call graph of the target scenario according to the call chain of each scenario interface includes:

[0015] According to the call chain of each scenario interface, determine the services included in the call chain of each scenario interface;

[0016] The call domains to which the services included in the call chain of each scenario interface belong are obtained, and a call graph corresponding to the target scenario is generated according to the call chains of each scenario interface and the call domains to which the services included in the call chain of each scenario interface belong.

[0017] In one embodiment, performing a service deduplication operation on the call graph to determine at least one call domain and a service corresponding to each call domain includes:

[0018] Extracting each service in the call graph to obtain a call service set;

[0019] Performing a service deduplication operation on the calling service set to remove duplicate services in the calling service set to obtain at least one target service;

[0020] At least one calling domain is determined according to each target service, and each target service is divided based on the calling domain to determine a service corresponding to each calling domain.

[0021] In one embodiment, the analysis of the causes of performance changes based on the services corresponding to each calling domain to obtain analysis results includes:

[0022] For each calling domain, obtain performance data of each service of the calling domain;

[0023] Performing a performance evaluation on each service according to the performance data of each service in the calling domain to obtain a performance score for each service in the calling domain;

[0024] Determine the average performance score of each service in the calling domain within a preset time period, and select a service whose performance score is lower than its corresponding average performance score from each service;

[0025] The selected services and their corresponding calling domains are recorded to generate analysis results.

[0026] In one of the embodiments, determining at least one scene interface according to the target scene includes:

[0027] Get the preset classification mapping table;

[0028] Querying the classification mapping table for a list of scene interfaces corresponding to the target scene;

[0029] When the scene interface list corresponding to the target scene is queried, at least one scene interface is determined based on the scene interface list.

[0030] In one embodiment, after executing the step of generating a call graph of the target scenario according to the call chains of each scenario interface, the method further includes:

[0031] The call graph of the target scene is stored, and the call graph of the target scene is visually displayed.

[0032] In a second aspect, the present application provides a performance anomaly analysis device based on a call chain, the device comprising:

[0033] An interface determination module, used to determine a target scenario where the performance change occurs when a performance change is detected, and determine at least one scenario interface according to the target scenario;

[0034] A call chain determination module is used to trace and record all downstream services for each scenario interface starting from the scenario interface to obtain the call chain corresponding to the scenario interface;

[0035] A call graph generation module, used to generate a call graph of the target scenario according to the call chains of each scenario interface when determining the call chain of each scenario interface;

[0036] The abnormality analysis module is used to perform service deduplication operation on the call graph to determine at least one call domain and the service corresponding to each call domain, and analyze the cause of performance abnormality based on the services corresponding to each call domain to obtain analysis results.

[0037] In a third aspect, the present application provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the performance anomaly analysis method based on the call chain as described in any of the above embodiments.

[0038] In a fourth aspect, the present application provides a computer device, comprising: one or more processors, and a memory;

[0039] The memory stores computer-readable instructions, and when the one or more processors execute the computer-readable instructions, the steps of the performance variance analysis method based on the call chain as described in any of the above embodiments are performed.

[0040] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0041] The present application provides a method, device, storage medium and computer equipment for analyzing performance fluctuations based on call chains. The method includes: when a performance fluctuation is detected, the target scenario where the performance fluctuation occurs is determined, and at least one scenario interface is determined according to the target scenario; for each scenario interface, all downstream services are traced and recorded starting from the scenario interface to obtain the call chain corresponding to the scenario interface; when the call chain of each scenario interface is determined, the call graph of the target scenario is generated according to the call chain of each scenario interface. In this way, a complete call relationship graph about the target scenario can be obtained, from which the call relationship and call hierarchy between services can be obtained. Then, the call graph is deduplicated to determine at least one call domain and the service corresponding to each call domain, and the cause of the performance fluctuation is analyzed based on the service corresponding to each call domain to obtain the analysis result. By performing a service deduplication operation on the call graph, all non-overlapping call services and involved call domains can be obtained, and then the cause of the performance fluctuation in the target scenario is comprehensively analyzed based on each call domain and the services contained in the target scenario. In this process, the mutual influence between multiple call levels can also be considered, so as to ensure that the root cause of the problem can be comprehensively and accurately located from the complete call relationship. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0043] Figure 1 A flowchart of a performance variance analysis method based on a call chain provided in an embodiment of the present application;

[0044] Figure 2 A flowchart of the call chain corresponding to the scenario interface is obtained by tracing back and recording all downstream services with the scenario interface as the starting point provided in the embodiment of the present application;

[0045] Figure 3 An example diagram of a call relationship provided for an embodiment of the present application;

[0046] Figure 4A schematic diagram of a process for analyzing the causes of performance changes based on services corresponding to each calling domain provided in an embodiment of the present application;

[0047] Figure 5 A schematic diagram of the structure of a performance anomaly analysis device based on a call chain provided in an embodiment of the present application;

[0048] Figure 6 An internal structure diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0050] In one embodiment, the present application provides a performance anomaly analysis method based on a call chain, and the following embodiment is described by applying the method to a server. It can be understood that the performance anomaly analysis method based on a call chain can be performed by a single server or a server cluster composed of multiple servers, and the present application does not make specific restrictions on this.

[0051] like Figure 1 As shown, the present application provides a performance variation analysis method based on a call chain, the method comprising:

[0052] S101: When a performance change is detected, a target scenario in which the performance change occurs is determined, and at least one scenario interface is determined according to the target scenario.

[0053] In this step, when a user needs to perform a performance change detection on a certain application or system, the server can perform the performance change detection on the application or system. When the server detects the performance change, it locates the functional module in the application or system where the performance change occurs, so as to determine the target scenario where the performance change occurs, and then determines at least one scenario interface according to the target scenario.

[0054] Among them, performance changes refer to the unexpected and obvious changes in the performance indicators of the system or software, such as longer response time, lower throughput, etc. The target scenario refers to the functional module in the application. The scenario interface refers to the entry API contained in the corresponding target scenario.

[0055] Furthermore, the server can determine whether the application or system has a performance change by monitoring performance indicators related to the performance change, and then locate the functional module where the performance change has occurred, that is, the target scenario.

[0056] S102: For each scenario interface, trace back and record all downstream services starting from the scenario interface to obtain a call chain corresponding to the scenario interface.

[0057] In this step, for each determined scenario interface, the scenario interface is used as the tracing starting point, and all services called downstream are traced and recorded to construct a call chain for the scenario interface.

[0058] The call chain refers to a link used to describe the execution sequence of mutual calls between a series of internal services starting from an entry API during the running process of the application. It can be understood that the call chain can be in a tree or strip shape.

[0059] For example, suppose there is a scenario interface A. When executing scenario interface A, service B will be called. When executing service B, service C will be called. When executing service C, the required data is returned. There is no need to call other services. At this time, the call chain about scenario interface A can be obtained as scenario interface A-service B-service C. At this time, the call chain is in the form of a strip. In another example, suppose there is a scenario interface D. When executing scenario interface D, service E and service F will be called. When executing service E and service F, the required data is returned. There is no need to call other services. At this time, the call chain about scenario interface A can be obtained as scenario interface D-service E, scenario interface D-service F. At this time, the call chain is in the form of a tree.

[0060] S103: When the call chain of each scenario interface is determined, a call graph of the target scenario is generated according to the call chains of each scenario interface.

[0061] In this step, when the call chain is determined for each scenario interface and the call chain of each scenario interface is obtained, the target scenario can be used as a starting point to draw a call graph of the target scenario according to the call chains of each scenario interface.

[0062] The call graph refers to the relationship graph of the services called by each entry scenario involved in the target scenario. For example, when the target scenario is a shopping scenario, the various entry scenarios involved may include favorites shopping, product details page shopping, advertising promotion shopping, user search shopping, etc.

[0063] S104: performing a service deduplication operation on the call graph to determine at least one call domain and a service corresponding to each call domain, and analyzing the cause of the performance change based on the services corresponding to each call domain to obtain an analysis result.

[0064] In this step, after obtaining the call graph of the target scenario, the call graph is deduplicated to obtain a service set without duplicate services, so that these services can be analyzed later to locate the problem causing the performance fluctuation. Then, based on the call domains to which each service in the service set belongs, at least one call domain and the services corresponding to each call domain are determined. Finally, the causes of the performance fluctuation are analyzed based on the services corresponding to each call domain to obtain the analysis results.

[0065] The call domain refers to a relatively independent range or area in the call relationship of an application, which covers a group of interrelated services, components, modules or methods.

[0066] Specifically, since performance fluctuations are not necessarily caused by only one service, but may be caused by multiple services, if the analysis is performed according to the call level, when a problem occurs in a middle-layer service, the mining and analysis of downstream called services will be stopped. This may miss some problematic services and make it difficult to fully grasp the problems in the entire calling process. Based on this, this solution constructs the entire call graph of the target scenario, and comprehensively analyzes each called service after deduplication, ensuring that all calling services involved in the target scenario can be comprehensively and accurately analyzed. This improves the comprehensiveness and accuracy of performance fluctuation analysis.

[0067] The present application provides a method, device, storage medium and computer equipment for analyzing performance fluctuations based on call chains. The method includes: when a performance fluctuation is detected, the target scenario where the performance fluctuation occurs is determined, and at least one scenario interface is determined according to the target scenario; for each scenario interface, all downstream services are traced and recorded starting from the scenario interface to obtain the call chain corresponding to the scenario interface; when the call chain of each scenario interface is determined, the call graph of the target scenario is generated according to the call chain of each scenario interface. In this way, a complete call relationship graph about the target scenario can be obtained, from which the call relationship and call hierarchy between services can be obtained. Then, the call graph is deduplicated to determine at least one call domain and the service corresponding to each call domain, and the cause of the performance fluctuation is analyzed based on the service corresponding to each call domain to obtain the analysis result. By performing a service deduplication operation on the call graph, all non-overlapping call services and involved call domains can be obtained, and then the cause of the performance fluctuation in the target scenario is comprehensively analyzed based on each call domain and the services contained in the target scenario. In this process, the mutual influence between multiple call levels can also be considered, so as to ensure that the root cause of the problem can be comprehensively and accurately located from the complete call relationship.

[0068] like Figure 2 As shown, in one embodiment, all downstream services are traced back and recorded starting from the scenario interface to obtain a call chain corresponding to the scenario interface, including:

[0069] S201: Determine the services included in the next call level based on the scenario interface, and enter the next call level.

[0070] S202: In the current calling level, determine the services included in the next calling level according to the services included in the current calling level, and enter the next calling level until the services included in the determined next calling level are empty, and then record the services in each calling level and their calling relationships.

[0071] S203: Generate a call chain corresponding to the scenario interface according to the services in each call level and their call relationships.

[0072] In this embodiment, the scene interface is used as the starting point to continuously query the services of the next call level until the services contained in the next call level are empty. At this time, the services in each call level and the call relationship of these services are recorded, and then the call chain corresponding to the scene interface is constructed according to the services in each call level and the call relationship of these services. In this way, the call chain of each scene interface can be obtained, so that a call graph that can reflect the overall call relationship of the target scene can be generated based on this construction.

[0073] In one embodiment, generating a call graph of a target scenario according to the call chain of each scenario interface includes:

[0074] S1: According to the call chain of each scenario interface, determine the services included in the call chain of each scenario interface.

[0075] S2: Obtain the call domains to which the services contained in the call chain of each scenario interface belong, and generate a call graph corresponding to the target scenario based on the call chains of each scenario interface and the call domains to which the services contained in the call chain of each scenario interface belong.

[0076] In this embodiment, the call chain of each scenario interface is traversed, and the specific services involved therein are identified one by one. After determining the services included in the call chain of each scenario interface, the call domains to which these services belong are found through the pre-set mapping relationship between services and call domains. For example, if there is a call chain of an order processing scenario interface, which includes an order creation service, an inventory query service, etc., according to the existing mapping rules, it is determined that the order creation service belongs to the order management call domain, and the inventory query service belongs to the inventory management call domain. Finally, the call chain information of the scenario interface is integrated with the call domain information to which each service belongs, and a call graph corresponding to the target scenario is generated in an appropriate graphical manner, such as nodes representing services, lines representing call relationships, and different area divisions representing call domains.

[0077] In addition, as applications are continuously updated and iterated, services may change and the call domains they belong to may also change. Therefore, relevant mapping data can be regularly maintained and updated to ensure that the generated call graph is always consistent with the actual application situation, thereby providing a reliable basis for application performance analysis, troubleshooting, etc.

[0078] It can be understood that the call graph of the target scenario is generated through the call chain construction of each scenario interface, so that the reasons for performance changes in the target scenario can be analyzed from the overall call situation based on the call graph, so as to improve the comprehensiveness and reliability of the analysis, thereby ensuring the accuracy of the performance change analysis.

[0079] In one example, if Figure 3 As shown, Figure 3 This is an example diagram of the calling relationship provided in the embodiment of the present application. Figure 3 In the example, the target scenario is the shopping scenario, which includes four entry scenarios, namely favorites shopping, product detail page shopping, advertising promotion, and user search. Favorites shopping calls service A in microservice domain do1 (i.e., calling domain), then service A calls service D in microservice domain do2 (i.e., calling domain), and finally service D calls SERVICE F in microservice domain do3 (i.e., calling domain). In this way, the call chain of the entry scenario (i.e., scenario interface) of favorites shopping is obtained. The corresponding call chains can be obtained by analogy for the other three entry scenarios. Figure 3 In the example, the services directly called by favorites purchase, product detail page purchase, advertising promotion and user search can be called the same call level. In this way, after the service deduplication operation, at least one call domain and the corresponding services in each call domain can be obtained, namely, call domain do1 (service A, service B), call domain do2 (service C, service D), call domain do3 (SERVICE E, SERVICE F).

[0080] In one embodiment, performing a service deduplication operation on a call graph to determine at least one call domain and a service corresponding to each call domain includes:

[0081] S1: Extract each service in the call graph to obtain a call service set.

[0082] S2: performing a service deduplication operation on the calling service set to remove duplicate services in the calling service set and obtain at least one target service.

[0083] S3: Determine at least one calling domain according to each target service, and divide each target service based on the calling domain to determine a service corresponding to each calling domain.

[0084] In this embodiment, each node in the call graph is traversed, because these nodes represent various services, and they are extracted one by one, so as to construct an initial call service set. Then, a suitable deduplication algorithm is used to gradually remove duplicate services in the call service set, and finally at least one target service is obtained. Next, the call domain of each target service is obtained. Since the call domains of different services may be consistent, at least one call domain can be determined after obtaining the call domain of each target service, and then the target services are divided according to the determined call domains, so that each call domain contains services in the target scenario.

[0085] Furthermore, in the process of deduplication of the call service set, a hash table can be used to record the services that have appeared. When traversing each service in the call service set, check its record in the hash table. If the service has not been recorded, it will be determined as the target service and marked in the hash table that the service already exists; if the service already has a record in the hash table, it means that it is a duplicate service and is skipped directly.

[0086] It is understandable that by deduplicating the call graph and dividing each target service according to the call domain, on the one hand, it is possible to avoid subsequent reanalysis of the same call service and save computing resources. On the other hand, different target services can be distinguished by the call domain, thereby analyzing performance changes in the dimension of the call domain.

[0087] like Figure 4 As shown, in one embodiment, the causes of performance changes are analyzed based on the services corresponding to each calling domain, and the analysis results are obtained, including:

[0088] S301: For each calling domain, obtain performance data of each service of the calling domain.

[0089] In this step, for each calling domain, the performance data of each service corresponding to the calling domain in the target scenario is obtained. It is understandable that when obtaining the performance data of each service, the performance data of each service can be obtained by collecting data of preset various performance-related indicators.

[0090] Among them, performance data is a data set related to various performance indicators used to measure the application during operation, including but not limited to response time, throughput, resource utilization, etc.

[0091] S302: Perform performance evaluation on each service according to the performance data of each service in the calling domain to obtain a performance score of each service in the calling domain.

[0092] Among them, the performance score is used to evaluate the performance level of the service. The higher the performance score, the higher the level of service.

[0093] For a certain service, you can obtain the preset weights of the data in each dimension of its performance data, and then quantify and score the data in each dimension of the performance data of the service according to the pre-set evaluation criteria. For example, the shorter the response time, the higher the score, and the lower the resource utilization, the higher the score. Finally, the performance score of the service is obtained by weighted summing the scores of the data in each dimension of the performance data of the service and the corresponding preset weights. Other services can also refer to this process to determine the performance score. It can be understood that the determination of the preset weight can be set based on the core concerns of the business and the degree of impact of the indicator on the overall performance. For example, for a service with extremely high real-time requirements, the preset weight of the response time may be relatively high.

[0094] In another embodiment, a deep learning model can be constructed to learn the relationship between performance data and the performance score of the service, and then the pre-trained deep learning model can be called to determine the performance score of each service. The specific performance score calculation method can be determined according to actual conditions, and this application does not make specific restrictions on this.

[0095] S303: Determine the average performance score of each service in the calling domain within a preset time period, and select a service whose performance score is lower than the corresponding average performance score from each service.

[0096] The average performance score is used to measure the average performance level of the service over a period of time. The preset time period is an empirical value and can be set to two days, three days, etc. This application does not impose specific restrictions on this. It should be noted that the preset time period can be determined from the current time as the starting point, and the time period determined by a period of time is the preset time period.

[0097] In this step, the server can calculate the performance score of each service in the previous period to determine the average performance score of each service in the period, and then select the service with a performance score lower than its corresponding performance score from each service. In this way, the average performance score of each service can be used to measure whether the performance of the corresponding service meets the standard, thereby further improving the accuracy of performance change analysis.

[0098] S304: Record the selected service and its corresponding calling domain to generate analysis results.

[0099] When the selected service and its corresponding call domain are recorded, an analysis report can be generated based on this information so that relevant personnel can quickly identify the cause of the performance change and take timely measures to maintain the stable operation of the application.

[0100] In one of the embodiments, determining at least one scenario interface according to the target scenario includes:

[0101] S1: Obtain a preset classification mapping table.

[0102] The classification mapping table is used to record the correspondence between the scene and the scene interface list. The classification mapping table can be pre-set and maintained when the correspondence is modified.

[0103] S2: Query the scene interface list corresponding to the target scene in the classification mapping table.

[0104] In this step, when the classification mapping table is obtained, the target scene can be used as a search term to query the scene interface list corresponding to the target scene in the classification mapping table, wherein the scene interface list includes at least one scene interface.

[0105] S3: When the scene interface list corresponding to the target scene is found, at least one scene interface is determined based on the scene interface list.

[0106] Specifically, when a scene interface list corresponding to the target scene is queried in the classification mapping table, at least one scene interface can be determined from each scene interface recorded in the scene interface list.

[0107] In this embodiment, each scenario interface of the target scenario can be determined through a pre-configured classification mapping table, so that the service call traceability can be performed based on each scenario interface later, thereby realizing the analysis of performance changes in the target scenario.

[0108] In one embodiment, after executing the step of generating a call graph of a target scenario according to the call chains of each scenario interface, the performance variation analysis method based on the call chain further includes:

[0109] The call graph of the target scene is stored and the call graph of the target scene is visualized.

[0110] In this embodiment, after the call graph is obtained, the call graph can be stored. If the code has not changed, the call graph can be directly reused to save computing resources. Moreover, after the call graph is obtained, the call graph can be visualized so that relevant personnel can intuitively understand the call relationship of the target scenario.

[0111] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0112] The following is a description of a performance anomaly analysis device based on a call chain provided in an embodiment of the present application. The performance anomaly analysis device based on a call chain described below and the performance anomaly analysis method based on a call chain described above can be referenced to each other.

[0113] like Figure 5 As shown, the present application provides a performance abnormality analysis device 400 based on a call chain, the device comprising:

[0114] The interface determination module 401 is used to determine the target scenario where the performance change occurs when the performance change is detected, and determine at least one scenario interface according to the target scenario;

[0115] A call chain determination module 402 is used to trace back and record all downstream services for each scenario interface starting from the scenario interface to obtain a call chain corresponding to the scenario interface;

[0116] A call graph generation module 403 is used to generate a call graph of a target scenario according to the call chains of each scenario interface when the call chain of each scenario interface is determined;

[0117] The abnormality analysis module 404 is used to perform a service deduplication operation on the call graph to determine at least one call domain and the service corresponding to each call domain, and analyze the cause of the performance abnormality based on the services corresponding to each call domain to obtain an analysis result.

[0118] In one embodiment, the call chain determination module includes:

[0119] A determination submodule is used to determine the services included in the next call level based on the scenario interface and enter the next call level;

[0120] The tracing submodule is used to determine the services included in the next calling level in the current calling level according to the services included in the current calling level, and enter the next calling level until the services included in the determined next calling level are empty, and then record the services in each calling level and their calling relationships;

[0121] The call chain generation submodule is used to generate the call chain corresponding to the scenario interface according to the services and their call relationships in each call level.

[0122] In one embodiment, the call graph generation module includes:

[0123] The service determination submodule is used to determine the services included in the call chain of each scenario interface according to the call chain of each scenario interface;

[0124] The graph generation submodule is used to obtain the call domain of the services contained in the call chain of each scenario interface, and generate a call graph corresponding to the target scenario based on the call chains of each scenario interface and the call domain of the services contained in the call chain of each scenario interface.

[0125] In one embodiment, the change analysis module includes:

[0126] The service extraction submodule is used to extract each service in the call graph and obtain a call service set;

[0127] A deduplication submodule is used to perform a service deduplication operation on the calling service set to remove duplicate services in the calling service set and obtain at least one target service;

[0128] The division submodule is used to determine at least one calling domain according to each target service, and divide each target service based on the calling domain to determine the service corresponding to each calling domain.

[0129] In one embodiment, the change analysis module includes:

[0130] A data acquisition submodule, for acquiring, for each calling domain, performance data of each service of the calling domain;

[0131] The performance evaluation submodule is used to evaluate the performance of each service in the calling domain according to the performance data of each service in the calling domain, and obtain the performance score of each service in the calling domain;

[0132] The score determination submodule is used to determine the average performance score of each service in the calling domain within a preset time period, and select a service whose performance score is lower than its corresponding average performance score from each service;

[0133] The result generation submodule is used to record the selected services and their corresponding call domains to generate analysis results.

[0134] In one embodiment, the interface determination module includes:

[0135] A table acquisition submodule is used to obtain a preset classification mapping table;

[0136] A query submodule, used to query a scene interface list corresponding to a target scene in a classification mapping table;

[0137] The interface determination submodule is used to determine at least one scene interface based on the scene interface list when a scene interface list corresponding to the target scene is queried.

[0138] In one embodiment, the performance abnormality analysis device based on the call chain further includes:

[0139] The visualization module is used to store the call graph of the target scene and to visualize the call graph of the target scene.

[0140] The division of each module in the above-mentioned performance anomaly analysis device based on call chain is only used for illustration. In other embodiments, the performance anomaly analysis device based on call chain can be divided into different modules as needed to complete all or part of the functions of the above-mentioned performance anomaly analysis device based on call chain. Each module in the above-mentioned performance anomaly analysis device based on call chain can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above-mentioned modules.

[0141] In one embodiment, the present application also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the performance anomaly analysis method based on the call chain as described in any of the above embodiments.

[0142] In one embodiment, the present application also provides a computer device having computer-readable instructions stored therein. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the performance anomaly analysis method based on the call chain as described in any of the above embodiments.

[0143] Indicatively, if Figure 6 As shown, Figure 6 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. The computer device 500 may be provided as a server. Figure 6The computer device 500 includes a processing component 502, which further includes one or more processors, and a memory resource represented by a memory 501, for storing instructions executable by the processing component 502, such as an application. The application stored in the memory 501 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 502 is configured to execute instructions to perform the performance variation analysis method based on the call chain of any of the above embodiments.

[0144] The computer device 500 may further include a power supply component 503 configured to perform power management of the computer device 500, a wired or wireless network interface 504 configured to connect the computer device 500 to a network, and an input / output (I / O) interface 505. The computer device 500 may operate based on an operating system stored in the memory 501, such as Windows Server TM, Mac OS X TM, Unix TM, Linux TM, Free BSD TM, or the like.

[0145] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0146] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish an entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements not only include those elements, but also include other elements that are not clearly listed, or also include elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements limited by the sentence "comprise one..." do not exclude the existence of other identical elements in the process, method, article or equipment including the elements. Herein, the singular "one", "one" and "described / the" may also include plural forms, unless the context clearly indicates another way. It should also be understood that the terms "include / comprise" or "have" etc. specify the existence of stated features, wholes, steps, operations, components, parts or combinations thereof, but do not exclude the possibility of the existence or addition of one or more other features, wholes, steps, operations, components, parts or combinations thereof. At the same time, the term "and / or" used in this specification includes any and all combinations of the relevant listed items.

[0147] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can refer to each other.

[0148] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A performance change analysis method based on call chain, characterized in that: The method comprises: When a performance change is detected, determining a target scenario where the performance change occurs, and determining at least one scenario interface according to the target scenario; For each scenario interface, trace back and record all downstream services starting from the scenario interface to obtain the call chain corresponding to the scenario interface; When the call chain of each scenario interface is determined, a call graph of the target scenario is generated according to the call chain of each scenario interface; A service deduplication operation is performed on the call graph to determine at least one call domain and a service corresponding to each call domain, and the cause of the performance change is analyzed based on the services corresponding to each call domain to obtain an analysis result.

2. The performance change analysis method based on call chain according to claim 1 is characterized in that: The method of tracing back and recording all downstream services starting from the scenario interface to obtain the call chain corresponding to the scenario interface includes: Determine the services included in the next call level based on the scenario interface and enter the next call level; In the current call level, the services included in the next call level are determined according to the services included in the current call level, and the next call level is entered until the services included in the determined next call level are empty, and the services in each call level and their call relationships are recorded; According to the services and their calling relationships in each calling level, a calling chain corresponding to the scene interface is generated.

3. The performance change analysis method based on call chain according to claim 1 is characterized in that: Generating a call graph of the target scenario according to the call chain of each scenario interface includes: According to the call chain of each scenario interface, determine the services included in the call chain of each scenario interface; The call domains to which the services included in the call chain of each scenario interface belong are obtained, and a call graph corresponding to the target scenario is generated according to the call chains of each scenario interface and the call domains to which the services included in the call chain of each scenario interface belong.

4. The performance change analysis method based on call chain according to claim 1 is characterized in that: The performing a service deduplication operation on the call graph to determine at least one call domain and a service corresponding to each call domain includes: Extracting each service in the call graph to obtain a call service set; Performing a service deduplication operation on the calling service set to remove duplicate services in the calling service set to obtain at least one target service; At least one calling domain is determined according to each target service, and each target service is divided based on the calling domain to determine a service corresponding to each calling domain.

5. The performance variation analysis method based on call chain according to any one of claims 1 to 4, characterized in that: The analysis of the causes of performance changes based on the services corresponding to each calling domain to obtain analysis results includes: For each calling domain, obtain performance data of each service of the calling domain; Performing a performance evaluation on each service according to the performance data of each service in the calling domain to obtain a performance score for each service in the calling domain; Determine the average performance score of each service in the calling domain within a preset time period, and select a service whose performance score is lower than its corresponding average performance score from each service; The selected services and their corresponding calling domains are recorded to generate analysis results.

6. The performance change analysis method based on call chain according to claim 1 is characterized in that: The determining at least one scene interface according to the target scene includes: Get the preset classification mapping table; Querying the classification mapping table for a list of scene interfaces corresponding to the target scene; When the scene interface list corresponding to the target scene is queried, at least one scene interface is determined based on the scene interface list.

7. The performance variation analysis method based on call chain according to claim 1 is characterized in that: After executing the step of generating a call graph of the target scenario according to the call chains of each scenario interface, the method further includes: The call graph of the target scene is stored, and the call graph of the target scene is visually displayed.

8. A performance variation analysis device based on call chain, characterized in that: The device comprises: An interface determination module, used to determine a target scenario where the performance change occurs when a performance change is detected, and determine at least one scenario interface according to the target scenario; A call chain determination module is used to trace and record all downstream services for each scenario interface starting from the scenario interface to obtain the call chain corresponding to the scenario interface; A call graph generation module, used to generate a call graph of the target scenario according to the call chains of each scenario interface when determining the call chain of each scenario interface; The abnormality analysis module is used to perform service deduplication operation on the call graph to determine at least one call domain and the service corresponding to each call domain, and analyze the cause of performance abnormality based on the services corresponding to each call domain to obtain analysis results.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the call chain-based performance anomaly analysis method as described in any one of claims 1 to 7.

10. A computer device, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the performance variance analysis method based on the call chain as described in any one of claims 1 to 7 are performed.

Images