A pressure testing method and device combining performance bottleneck positioning

Abstract

The embodiment of the application provides a stress testing method and a stress testing device combined with performance bottleneck positioning, the stress testing device comprises a preset performance diagnosis tool, and the method comprises the following steps: in the case that a performance bottleneck exists in the process of performing stress testing on a target service, determining a target instance in which the target service is deployed; a performance diagnosis thread corresponding to the preset performance diagnosis tool is arranged in the target instance; calling the performance diagnosis thread to perform performance diagnosis on the target instance, obtaining a diagnosis result, and the diagnosis result is used for positioning the performance bottleneck reason of the target service.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a stress testing method and apparatus that combines performance bottleneck location. Background Technology

[0002] Current technologies for performance testing of a service under test (SUT) first require performance evaluation and the establishment of stress indicators. Then, stress testing tools are used to perform the tests and obtain the results. Next, the results and stress indicators are analyzed to determine if the SUT has reached its performance limits. If not, repeated stress testing is necessary, with performance bottlenecks identified during each test. Finally, after repeated stress testing and bottleneck identification, a stress test report is generated. Current stress testing tools only include the stress testing process. After obtaining the results, testers need to provide feedback to operations personnel. Operations personnel must then log into an instance of the SUT, install performance diagnostic tools, identify performance bottlenecks, and provide the results back to the testers. This process of identifying performance bottlenecks using current technologies is cumbersome and inefficient. Summary of the Invention

[0003] This application provides a stress testing method and apparatus that incorporates performance bottleneck location, which can improve the efficiency of performance bottleneck location during stress testing.

[0004] The technical solution of this application is implemented as follows:

[0005] In a first aspect, embodiments of this application provide a stress testing method that combines performance bottleneck location, applied to a stress testing device, the stress testing device including a preset performance diagnostic tool, the method comprising:

[0006] If a performance bottleneck is found during stress testing of the target service, a target instance for deploying the target service is determined; the target instance is configured with a performance diagnostic thread corresponding to the preset performance diagnostic tool.

[0007] The performance diagnosis thread is invoked to perform performance diagnosis on the target instance and obtain the diagnosis results, which are used to locate the cause of the performance bottleneck of the target service.

[0008] In the above-mentioned stress testing method that combines performance bottleneck location, the step of calling the performance diagnosis thread to perform performance diagnosis on the target instance and obtaining the diagnosis results includes:

[0009] Determine the objective function included in the target instance;

[0010] The performance diagnostic thread is invoked to transmit the target function to the preset performance diagnostic tool to obtain the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path represents the call relationship between the target function and the sub-functions.

[0011] The first duration, the second duration, and the call path are determined as the diagnostic result.

[0012] In the above-mentioned stress testing method that combines performance bottleneck location, the step of calling the performance diagnosis thread to perform performance diagnosis on the target instance and obtaining the diagnosis results includes:

[0013] Identify the target virtual machine for deploying the target instance;

[0014] The performance diagnostic thread is invoked to collect garbage collection (GC) data corresponding to the target virtual machine during the stress test of the target service.

[0015] The GC data is identified as the diagnostic result.

[0016] In the above-mentioned stress testing method that combines performance bottleneck location, determining the target instance for deploying the target service includes:

[0017] Obtain and parse the target service to obtain at least one instance corresponding to the target service;

[0018] If the performance diagnostic thread is not set in the first instance of the at least one instance, then a preset performance diagnostic tool agent is deployed in the first instance;

[0019] The preset performance diagnostic tool agent is attached to the target process of the first instance to start the performance diagnostic thread of the first instance;

[0020] The first instance and the second instance that enable the performance diagnostic thread are determined as the target instance, and the second instance is an instance other than the first instance among the at least one instances.

[0021] In the above-mentioned stress testing method that combines performance bottleneck location, the GC data includes the time consumption of young generation GC data and overall GC data.

[0022] Secondly, embodiments of this application provide a stress testing device, which includes a preset performance diagnostic tool. The device includes:

[0023] The determination module is used to determine the target instance for deploying the target service when a performance bottleneck is found during stress testing of the target service; the target instance is equipped with a performance diagnosis thread corresponding to the preset performance diagnosis tool;

[0024] The performance diagnosis module is used to call the performance diagnosis thread to perform performance diagnosis on the target instance and obtain the diagnosis results. The diagnosis results are used to locate the cause of the performance bottleneck of the target service.

[0025] In the aforementioned stress testing device, the performance diagnosis module is further configured to determine the target function included in the target instance; call the performance diagnosis thread to transmit the target function to the preset performance diagnosis tool to obtain the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path characterizes the call relationship between the target function and the sub-functions; and determine the first runtime, the second runtime, and the call path as the diagnosis result.

[0026] In the aforementioned stress testing device, the performance diagnostic module is further configured to determine the target virtual machine where the target instance is deployed; call the performance diagnostic thread to collect garbage collection (GC) data corresponding to the target virtual machine during the stress test of the target service; and determine the GC data as the diagnostic result.

[0027] This application provides a stress testing method and apparatus that combines performance bottleneck localization. The stress testing apparatus includes a preset performance diagnostic tool. The method includes: when a performance bottleneck exists during stress testing of a target service, determining a target instance where the target service is deployed; setting a performance diagnostic thread corresponding to the preset performance diagnostic tool in the target instance; calling the performance diagnostic thread to perform performance diagnosis on the target instance and obtaining diagnostic results, which are used to locate the cause of the performance bottleneck in the target service. By using the above implementation scheme, by pre-setting a performance diagnostic thread in the target instance where the target service is deployed, when a performance bottleneck occurs during stress testing of the target service, the preset performance diagnostic tool can be directly called to locate the cause of the performance bottleneck. This application combines the stress testing process with the performance bottleneck localization process to directly locate the cause when a performance bottleneck occurs during stress testing, thereby improving the efficiency of performance bottleneck localization. Attached Figure Description

[0028] Figure 1 A flowchart of a stress testing method combining performance bottleneck location is provided for an embodiment of this application;

[0029] Figure 2A schematic diagram illustrating the composition of an exemplary pressure testing device provided in this application embodiment;

[0030] Figure 3 This application provides an exemplary stress testing method flow that combines performance bottleneck location. Figure 1 ;

[0031] Figure 4 This application provides an exemplary stress testing method flow that combines performance bottleneck location. Figure 2 ;

[0032] Figure 5 An exemplary GC data diagram provided for an embodiment of this application;

[0033] Figure 6 A schematic diagram of the composition structure of a pressure testing device provided in this application embodiment. Figure 1 ;

[0034] Figure 7 A schematic diagram of the composition structure of a pressure testing device provided in this application embodiment. Figure 2 . Detailed Implementation

[0035] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit the scope of this application.

[0036] This application provides a stress testing method that combines performance bottleneck location and is applied to a stress testing device. Figure 1 A flowchart of a stress testing method combining performance bottleneck location is provided for an embodiment of this application, as shown below. Figure 1 As shown, stress testing methods that combine performance bottleneck location can include:

[0037] S101. If a performance bottleneck is found during the stress test of the target service, determine the target instance for deploying the target service; the target instance has a performance diagnosis thread corresponding to the preset performance diagnosis tool.

[0038] In this embodiment of the application, when a performance bottleneck is found during the stress test of the target service, the stress testing device determines the target instance where the target service is deployed; the target instance is equipped with a performance diagnosis thread corresponding to a preset performance diagnosis tool.

[0039] It should be noted that the stress testing method combined with performance bottleneck location provided in this application embodiment is applied to the process of generating performance bottlenecks when stress testing a target service using a stress testing device.

[0040] It should be noted that, Figure 2 This application provides an exemplary schematic diagram of the composition of a pressure testing device, as shown in the embodiments. Figure 2 As shown, the stress testing device first performs stress tests on the target service. Only after multiple stress tests produce performance bottlenecks is the performance diagnostic function used to locate the cause of the performance bottleneck. When performing performance diagnostics, a tool platform, preset performance diagnostic tools, and an object storage platform are required.

[0041] It should be noted that stress testing involves continuously applying pressure to software, forcing it to run under extreme conditions, observing the extent to which it can operate, and thus discovering performance defects. This is done by setting up a test environment similar to the real environment, and sending a predetermined number of transaction requests to the system at the same time or within a certain period of time to test the system's efficiency under different pressure conditions and the pressure that the system can withstand.

[0042] It should be noted that a performance bottleneck can be understood as the stress test results not meeting expectations. Further analysis of the stress test results is needed to find the cause of the performance bottleneck.

[0043] It should be noted that performance bottlenecks can exist in modules such as hardware, middleware, applications, operating systems, and network devices. Hardware bottlenecks are generally related to CPU, memory, and disk. Middleware bottlenecks are generally related to software, databases, and caching. Application bottlenecks are generally related to unreasonable parameters, improper container configuration, poor database design, inadequate program architecture planning, and poor program design. Operating system bottlenecks are generally related to the number of connections, virtual memory, and kernel parameters. Network device bottlenecks are generally related to security devices and web application protection systems.

[0044] It should be noted that the target service can be an HTTP interface such as "http: / / www.jd.com / getItems".

[0045] It should be noted that the target instance can be the IP address of a container or a physical machine, such as "127.0.0.1".

[0046] It should be noted that, in the embodiments of this application, before performing performance diagnosis on the target instance, it is necessary to first determine the target instance for which the performance diagnosis thread is set.

[0047] Specifically, the target service is obtained and parsed to obtain at least one instance corresponding to the target service; if the first instance among the at least one instances does not have a performance diagnostic thread set up, a preset performance diagnostic tool agent is deployed in the first instance; the preset performance diagnostic tool agent is attached to the target process of the first instance to start the performance diagnostic thread of the first instance; the first instance and the second instance with the performance diagnostic thread started are determined as the target instance, and the second instance is the instance other than the first instance among the at least one instances.

[0048] It should be noted that when creating a load testing task to perform load testing on the target service, it is necessary to first associate the container application deployed by the target service. Each container application corresponds to multiple address information. Therefore, before performing performance diagnosis, it is necessary to first parse the target service to obtain all instances corresponding to the target service, and then arbitrarily select one instance from all instances for performance diagnosis.

[0049] It should be noted that the target process can be a Java process.

[0050] It should be noted that if the first instance is found from all instances, it is necessary to first determine whether a performance diagnostic thread is set up in the first instance, i.e., whether the performance diagnostic function is enabled. For example, assuming the project corresponding to the first instance is a Java project, the address information of the first instance is used to query whether the Java main process of the first instance has a performance diagnostic thread enabled. If it is enabled, the preset performance diagnostic tool can be directly called to perform performance diagnosis on the first instance. This query operation can be performed by calling, for example, Figure 2 The interface implementation of the preset performance diagnostic tool is shown; if it is not enabled, the performance diagnostic thread needs to be started on the first instance, which can be done by calling, for example... Figure 2 The interface implementation of the tool platform shown begins with, for example, Figure 2 The preset performance diagnostic tool agent is downloaded to the first instance on the object storage platform shown, and then called as follows: Figure 2 The interface of the tool platform shown executes a script on the first instance to complete the operation of setting up the performance diagnosis thread, that is, starting the performance diagnosis thread on the first instance.

[0051] It should be noted that after setting a performance diagnostic thread for the first instance that did not have one, both the first instance and the second instance with a pre-set performance diagnostic thread are identified as the target instance. The target instance is the instance with the performance diagnostic thread corresponding to the preset performance diagnostic tool by default.

[0052] S102. Call the performance diagnosis thread to perform performance diagnosis on the target instance and obtain the diagnosis results. The diagnosis results are used to locate the cause of the performance bottleneck of the target service.

[0053] In this embodiment of the application, after the stress testing device determines the target instance, it calls the performance diagnosis thread to perform performance diagnosis on the target instance and obtains the diagnosis results. The diagnosis results are used to locate the cause of the performance bottleneck of the target service.

[0054] It should be noted that calling the performance diagnostic thread to perform performance diagnostics on the target instance can be understood as calling the interface of the preset performance diagnostic tool to perform performance diagnostic operations on the target instance.

[0055] It should be noted that performance diagnostic operations include two types: one is to diagnose whether the program design in the target instance is reasonable, and the other is to diagnose whether the target server where the target instance is located is abnormal.

[0056] In one alternative embodiment, Figure 3 This application provides an exemplary stress testing method flow that combines performance bottleneck location. Figure 1 It can diagnose whether the program design in the target instance is reasonable, such as Figure 3 As shown, the method is as follows:

[0057] S201. Determine the objective function included in the target instance.

[0058] In this embodiment of the application, after determining the target instance, the pressure testing device determines the objective function included in the target instance.

[0059] It should be noted that the objective function consists of the class path of the objective function and the name of the objective function.

[0060] S202. The performance diagnostic thread is invoked to transmit the target function to the preset performance diagnostic tool to obtain the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path represents the call relationship between the target function and the sub-functions.

[0061] In this embodiment of the application, after determining the target path, the stress testing device calls the performance diagnosis thread to transmit the target function to the preset performance diagnosis tool to obtain the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path represents the call relationship between the target function and the sub-functions.

[0062] It should be noted that when transferring the target path to the preset performance diagnostic tool, select "Diagnose by function" in the preset performance diagnostic tool, and then transfer the function path "com.jd.test.testClass" and the function name "testFunc" to the preset performance diagnostic tool to obtain the function runtime.

[0063] It should be noted that when transmitting the target path to the preset performance diagnostic tool, the number of layers to be tracked during diagnosis can be selected. Assuming layer 1 is selected, the output performance diagnostic result will only show the first runtime of the target function; assuming layer 2 is selected, the output performance diagnostic result will include the first runtime of the target function and the second runtime of the sub-functions included in the target function; assuming layer 3 is selected, the output performance diagnostic result will include the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the third runtime of the sub-functions included in the sub-functions, and so on. The specific number of layers selected depends on the actual situation and is not limited in this embodiment. Furthermore, this application can not only display the runtime of each function after the function, but also use symbols to indicate whether the function includes sub-functions, or mark the path with the longest execution time at each layer with different colors. Specific functions can be added according to the actual situation and are not limited in this embodiment.

[0064] It should be noted that the preset performance diagnostic tool can not only determine the runtime of the target function, but also determine the runtime of the specific function mapped to the function monitoring name based on the function monitoring name registered by the user in the intelligent monitoring platform. For example, you can select "Diagnose by UMP" in the preset performance diagnostic tool, and then transfer "ump.key.jimdb.hgetall" to the preset performance diagnostic tool to obtain the function runtime.

[0065] S203. The first duration, the second duration, and the call path are determined as the diagnostic results.

[0066] In this embodiment of the application, after determining the first duration, the second duration, and the call path, the stress testing device determines the first duration, the second duration, and the call path as diagnostic results to locate the cause of the performance bottleneck of the target service.

[0067] It should be noted that after obtaining the first and second durations of the diagnostic results, the corresponding function can be judged based on the first and second durations to determine whether the function is written reasonably, and the function can be further optimized to improve the performance of the target service.

[0068] In another alternative embodiment, Figure 4 This application provides an exemplary stress testing method flow that combines performance bottleneck location. Figure 2 It can diagnose whether the target server where the target instance resides is experiencing any abnormalities, such as... Figure 4 As shown, the method is as follows:

[0069] S301. Determine the target virtual machine for the deployment target instance.

[0070] In this embodiment of the application, after determining the target instance, the stress testing device determines the target virtual machine for deploying the target instance.

[0071] S302, Call the performance diagnostic thread to collect garbage collection (GC) data of the target virtual machine during the stress test of the target service.

[0072] In this embodiment of the application, after determining the target server where the target instance is located, the stress testing device calls the performance diagnosis thread to collect the garbage collection (GC) data of the target virtual machine during the stress test of the target service.

[0073] It should be noted that the target virtual machine can be a Java Virtual Machine.

[0074] It should be noted that the garbage collection (GC) data refers to Java Virtual Machine (JVM) GC data, including the time taken and the occurrence of Young Generation GC and the overall Full GC. Figure 5 As shown, Figure 5 This is an exemplary GC data diagram provided for an embodiment of this application.

[0075] S303. Determine the GC data as the diagnostic result.

[0076] In this embodiment of the application, after determining the GC data corresponding to the target virtual machine, the stress testing device determines the GC data as the diagnostic result.

[0077] It should be noted that, through Figure 5 As can be seen, during the stress test of the target service, the target server corresponding to the target instance experienced three fluctuations. This means that the GC data can be used to determine whether the target server is experiencing an anomaly, and the performance of the target service can be optimized by improving the target server.

[0078] It should be noted that after the performance diagnosis is completed, this performance diagnosis function can be turned off by calling the interface in the preset performance diagnosis tool. If it is detected that it has not been turned off within the preset time, it will be turned off automatically. The preset time can be 10 minutes, 20 minutes or 30 minutes. The specific time is determined according to the actual situation. This application embodiment does not limit it here.

[0079] This application provides a stress testing method and apparatus that combines performance bottleneck localization. The stress testing apparatus includes a preset performance diagnostic tool. The method includes: when a performance bottleneck exists during stress testing of a target service, determining a target instance where the target service is deployed; setting a performance diagnostic thread corresponding to the preset performance diagnostic tool in the target instance; calling the performance diagnostic thread to perform performance diagnosis on the target instance and obtaining diagnostic results, which are used to locate the cause of the performance bottleneck in the target service. By using the above implementation scheme, by pre-setting a performance diagnostic thread in the target instance where the target service is deployed, when a performance bottleneck occurs during stress testing of the target service, the preset performance diagnostic tool can be directly called to locate the cause of the performance bottleneck. This application combines the stress testing process with the performance bottleneck localization process to directly locate the cause when a performance bottleneck occurs during stress testing, thereby improving the efficiency of performance bottleneck localization.

[0080] Based on the above embodiments, in another embodiment of this application, a pressure testing device 1 is provided. Figure 6 A schematic diagram of the composition structure of a pressure testing device provided in this application. Figure 1 ,like Figure 6 As shown, the pressure testing device 1 includes:

[0081] Module 10 is used to determine the target instance for deploying the target service when a performance bottleneck is found during stress testing of the target service; the target instance is configured with a performance diagnosis thread corresponding to the preset performance diagnosis tool.

[0082] The performance diagnosis module 11 is used to call the performance diagnosis thread to perform performance diagnosis on the target instance and obtain the diagnosis results. The diagnosis results are used to locate the cause of the performance bottleneck of the target service.

[0083] Optionally, the performance diagnosis module 11 determines the target function included in the target instance; calls the performance diagnosis thread to transmit the target function to the preset performance diagnosis tool, and obtains the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path represents the call relationship between the target function and the sub-functions; and determines the first runtime, the second runtime, and the call path as the diagnosis result.

[0084] Optionally, the performance diagnostic module 11 is further configured to determine the target virtual machine where the target instance is deployed; call the performance diagnostic thread to collect garbage collection (GC) data corresponding to the target virtual machine during the stress test of the target service; and determine the GC data as the diagnostic result.

[0085] Optionally, the performance diagnosis module 11 is further configured to acquire and parse the target service to obtain at least one instance corresponding to the target service; if the performance diagnosis thread is not set in the first instance of the at least one instance, a preset performance diagnosis tool agent is deployed in the first instance; the preset performance diagnosis tool agent is attached to the target process of the first instance to start the performance diagnosis thread of the first instance; the first instance and the second instance that have started the performance diagnosis thread are determined as the target instance, and the second instance is an instance other than the first instance among the at least one instances.

[0086] Optionally, in the above-mentioned stress testing device 1, the GC data includes the time consumed by young generation GC data and overall GC data.

[0087] This application provides a stress testing device, which includes a preset performance diagnostic tool. The method includes: when a performance bottleneck exists during stress testing of a target service, determining a target instance where the target service is deployed; setting a performance diagnostic thread corresponding to the preset performance diagnostic tool in the target instance; calling the performance diagnostic thread to perform performance diagnosis on the target instance and obtaining a diagnostic result, which is used to locate the cause of the performance bottleneck in the target service. By using the above implementation scheme, by pre-setting a performance diagnostic thread in the target instance where the target service is deployed, when a performance bottleneck occurs during stress testing of the target service, the preset performance diagnostic tool can be directly called to locate the cause of the performance bottleneck. This application combines the stress testing process with the performance bottleneck location process to directly locate the cause when a performance bottleneck occurs during stress testing, thereby improving the efficiency of performance bottleneck location.

[0088] Figure 7 A schematic diagram of the composition structure of a pressure testing device provided in this application embodiment. Figure 2 In practical applications, based on the same disclosed concept of the above embodiments, such as Figure 7 As shown, the pressure testing device 1 in this embodiment includes: a processor 12, a memory 13, and a communication bus 14.

[0089] In a specific embodiment, the determination module 10 and performance diagnosis module 11 can be implemented by a processor 12 located on the pressure testing device 1. The processor 12 can be at least one of the following: Application-Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), CPU, controller, microcontroller, or microprocessor. It is understood that for different pressure testing devices, the electronic device used to implement the processor function can also be other types; this embodiment does not impose specific limitations.

[0090] In this embodiment, the communication bus 14 is used to realize the connection communication between the processor 12 and the memory 13; when the processor 12 executes the running program stored in the memory 13, it implements the following stress testing method combined with performance bottleneck location:

[0091] If a performance bottleneck is found during stress testing of the target service, a target instance for deploying the target service is determined; the target instance is configured with a performance diagnostic thread corresponding to the preset performance diagnostic tool.

[0092] The performance diagnosis thread is invoked to perform performance diagnosis on the target instance and obtain the diagnosis results, which are used to locate the cause of the performance bottleneck of the target service.

[0093] Optionally, the processor 12 is further configured to determine the target function included in the target instance; call the performance diagnostic thread to transmit the target function to the preset performance diagnostic tool to obtain the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path represents the call relationship between the target function and the sub-functions; and determine the first runtime, the second runtime, and the call path as the diagnostic result.

[0094] Optionally, the processor 12 is further configured to determine the target virtual machine for deploying the target instance; call the performance diagnostic thread to collect garbage collection (GC) data corresponding to the target virtual machine during the stress test of the target service; and determine the GC data as the diagnostic result.

[0095] Optionally, the processor 12 is further configured to acquire and parse the target service to obtain at least one instance corresponding to the target service; if the performance diagnostic thread is not set in the first instance of the at least one instance, a preset performance diagnostic tool agent is deployed in the first instance; the preset performance diagnostic tool agent is attached to the target process of the first instance to start the performance diagnostic thread of the first instance; the first instance and the second instance that have started the performance diagnostic thread are determined as the target instance, and the second instance is an instance other than the first instance among the at least one instances.

[0096] Optionally, the GC data includes the time taken for young generation GC data and overall GC data.

[0097] It should be noted that, in this document, 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. Unless otherwise specified, 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 that element.

[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause an image display device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the stress testing method combined with performance bottleneck location described in the various embodiments of this disclosure.

[0099] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A stress testing method combining performance bottleneck location, characterized in that, The method is applied to a stress testing device, which includes a preset performance diagnostic tool, and is used during the process of generating performance bottlenecks when stress testing a target service using the stress testing device; the method includes: If a performance bottleneck is found during stress testing of the target service, a target instance for deploying the target service is determined. The target instance is equipped with a performance diagnostic thread corresponding to the preset performance diagnostic tool. The performance diagnostic thread is implemented by downloading the preset performance diagnostic tool proxy to the instance through the object storage platform of the stress testing device and calling the interface of the tool platform of the stress testing device to execute the script on the instance. The performance diagnostic thread is invoked to perform performance diagnostics on the target instance, and a diagnostic result is obtained. The diagnostic result is used to locate the cause of the performance bottleneck of the target service. The invocation of the performance diagnostic thread to perform performance diagnostics on the target instance includes: invoking the interface of the preset performance diagnostic tool to perform performance diagnostics on the target instance. The performance diagnosis includes diagnosing the design rationality of the program in the target instance and / or diagnosing anomalies in the target server where the target instance resides.

2. The method according to claim 1, characterized in that, The process of invoking the performance diagnosis thread to perform performance diagnosis on the target instance and obtaining the diagnosis results includes: Determine the objective function included in the target instance; The performance diagnostic thread is invoked to transmit the target function to the preset performance diagnostic tool to obtain the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path represents the call relationship between the target function and the sub-functions. The first duration, the second duration, and the call path are determined as the diagnostic result.

3. The method according to claim 1, characterized in that, The process of invoking the performance diagnosis thread to perform performance diagnosis on the target instance and obtaining the diagnosis results includes: Identify the target virtual machine for deploying the target instance; The performance diagnostic thread is invoked to collect garbage collection (GC) data corresponding to the target virtual machine during the stress test of the target service. The GC data is identified as the diagnostic result.

4. The method according to claim 1, characterized in that, The process of determining the target instance for deploying the target service includes: Obtain and parse the target service to obtain at least one instance corresponding to the target service; If the performance diagnostic thread is not set in the first instance of the at least one instance, then a preset performance diagnostic tool agent is deployed in the first instance; The preset performance diagnostic tool agent is attached to the target process of the first instance to start the performance diagnostic thread of the first instance; The first instance and the second instance that enable the performance diagnostic thread are determined as the target instance, and the second instance is an instance other than the first instance among the at least one instances.

5. The method according to claim 3, characterized in that, The GC data includes the time taken for young generation GC data and overall GC data.

6. A pressure testing device, characterized in that, The pressure testing device includes a preset performance diagnostic tool, and the device includes: The determination module is used to determine the target instance for deploying the target service when a performance bottleneck is found during stress testing of the target service. The target instance is equipped with a performance diagnosis thread corresponding to the preset performance diagnosis tool. The performance diagnosis thread is implemented by downloading the preset performance diagnosis tool proxy to the instance through the object storage platform of the stress testing device and calling the interface of the tool platform of the stress testing device to execute the script on the instance. The performance diagnosis module is used to call the performance diagnosis thread to perform performance diagnosis on the target instance and obtain a diagnosis result. The diagnosis result is used to locate the cause of the performance bottleneck of the target service. Calling the performance diagnosis thread to perform performance diagnosis on the target instance includes: calling the interface of the preset performance diagnosis tool to perform performance diagnosis on the target instance. The performance diagnosis includes diagnosing the design rationality of the program in the target instance and / or diagnosing anomalies in the target server where the target instance resides.

7. The apparatus according to claim 6, characterized in that, The performance diagnostic module is further configured to determine the target function included in the target instance; call the performance diagnostic thread to transmit the target function to the preset performance diagnostic tool to obtain the first runtime of the target function, the second runtime of the sub-functions included in the target function, and the call path of the target function calling the sub-functions; the call path represents the call relationship between the target function and the sub-functions; and determine the first runtime, the second runtime, and the call path as the diagnostic result.

8. The apparatus according to claim 6, characterized in that, The performance diagnostic module is also used to determine the target virtual machine where the target instance is deployed; and to call the performance diagnostic thread to collect garbage collection (GC) data corresponding to the target virtual machine during the stress test of the target service. The GC data is identified as the diagnostic result.

Images