Application program performance detection method and system and nonvolatile storage medium

Abstract

The invention discloses an application program performance detection method and system and a nonvolatile storage medium. The method comprises the following steps: receiving original stack data of a target application transmitted by a proxy end; based on the original stack data, symbolized data corresponding to the target application program is determined, and the symbolized data comprises the name of a calling function, the file path of the calling function and the source code line number of the calling function; and based on the symbolized data, determining a performance detection result of the target application program, the performance detection result including a function execution path and a resource consumption condition. According to the method and the device, the technical problems of high complexity and high overhead in deployment and operation of an application program performance detection technology in a production environment at present are solved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically, to an application performance testing method, system, and non-volatile storage medium. Background Technology

[0002] In today's complex and ever-changing cloud computing and containerized deployment environments, real-time monitoring and analysis of application performance is of paramount importance. Traditional methods, such as code instrumentation and sampling profilers, while providing detailed performance insights, are limited in production environments due to their high invasiveness, deployment complexity, and high overhead. Code instrumentation, in particular, often requires modification of source code or bytecode, increasing maintenance costs, while the accuracy and efficiency of sampling profilers depend on whether the target application carries sufficient debugging information.

[0003] The rise of eBPF (extended Berkeley Packet Filter) technology has revolutionized performance monitoring. While some current eBPF baseline performance monitoring tools utilize eBPF technology for data collection, they still have shortcomings in symbolic processing. For example, they still require local or remote access to debugging information; or their performance and accuracy may be affected when debugging information is lacking; and they may still rely on deployment-intensive or resource-intensive symbolic operations.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides an application performance testing method, system, and non-volatile storage medium to at least address the technical problems of high complexity and high overhead in the deployment and operation of current application performance testing technologies in production environments.

[0006] According to one aspect of the present invention, an application performance testing method is provided, comprising: receiving raw stack data of a target application transmitted by an agent, wherein the raw stack data includes function data or address data, the function data including an identifier of the file where the called function is located and an offset of the called function, and the address data being the memory address data of the called function, the agent being set on the host where the target application is located, and the agent program including an extended Berkeley package filter program; determining symbolic data corresponding to the target application based on the raw stack data, wherein the symbolic data includes the name of the called function, the file path of the called function, and the source code line number of the called function; and determining the performance testing result of the target application based on the symbolic data, wherein the performance testing result includes the function execution path and resource consumption.

[0007] Optionally, based on the original stack data, the symbolic data corresponding to the target application is determined, including: if the original stack data is function data, determining the dependency files of the target application in a preset centralized dependency file library based on the identifier; and parsing the dependency files of the target application based on the preset symbolic library to obtain the symbolic data.

[0008] Optionally, the pre-defined steps for building a centralized dependency file library are as follows: build a blank initial extensible repository; obtain multiple dependency files, including executable files with debugging information, separate debugging information files, and source files; determine the identifiers of each of the multiple files; build a hash-hierarchical directory based on the identifiers of each of the multiple files; and store the multiple dependency files in the initial extensible repository based on the hash-hierarchical directory to obtain the centralized dependency file library.

[0009] Optionally, if the original stack data is address data, the offset is calculated based on the memory start address and memory end address in the memory address data; the binary file corresponding to the called function is determined based on the memory address data; the identifier is determined in the binary file; and the function data is constructed based on the offset and the identifier.

[0010] Optionally, based on symbolic data, the performance test results of the target application are determined, including: based on symbolic data, determining hot functions, call frequency of hot functions, and execution time of hot functions in the target application; based on hot functions, call frequency of hot functions, and execution time of hot functions, determining function execution paths and resource consumption; converting function execution paths and resource consumption into flame graphs and displaying them on a preset display platform.

[0011] According to another aspect of the present invention, an application performance testing system is also provided, comprising: a server for executing the application performance testing method of any one of the above claims; and a proxy for obtaining the raw stack data of a target application and transmitting the raw stack data to the server.

[0012] Optionally, the agent converts the original stack data into a binary serialization format and transmits it to the server via a preset communication protocol, wherein the preset communication protocol is determined based on the size of the original stack data.

[0013] According to another aspect of the present invention, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored program, wherein, when the program is running, the device where the non-volatile storage medium is located is controlled to execute any of the above-described application performance detection methods.

[0014] According to another aspect of the present invention, a computer device is also provided, the computer device including a processor for running a program, wherein the program executes any of the above-described application performance detection methods during runtime.

[0015] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements any of the above-described application performance detection methods.

[0016] In this embodiment of the invention, an application performance testing method is employed. This method receives raw stack data of the target application transmitted from a proxy. The raw stack data includes function data or address data. Function data includes the identifier of the file containing the called function and the offset of the called function's execution. Address data is the memory address of the called function. The proxy is located on the host where the target application resides, and the proxy program includes an extended Berkeley package filter program. Based on the raw stack data, symbolic data corresponding to the target application is determined. Symbolic data includes the name of the called function, the file path of the called function, and the line number of the called function's source code. Based on the symbolic data, the performance testing result of the target application is determined. The performance testing result includes the function execution path and resource consumption. This method centralizes the symbolic process on the server side, significantly reducing deployment complexity in production environments and optimizing resource utilization. It thus solves the technical problems of high complexity and high overhead in the deployment and operation of current application performance testing technologies in production environments. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a computer terminal for implementing an application performance testing method is shown.

[0019] Figure 2 This is a flowchart illustrating the application performance testing method provided according to an embodiment of the present invention;

[0020] Figure 3 This is a diagram illustrating the operational logic architecture of an application performance testing system according to an optional embodiment of the present invention. Detailed Implementation

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

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0024] eBPF (extended Berkeley Packet Filter) is a technology that enables custom programs to run securely and efficiently in kernel space without modifying kernel source code or loading kernel modules. Through probe points mounted to the kernel or user space, it can capture information such as system calls and function calls, and is used in networking, security, and observability domains.

[0025] An Agent is a lightweight program deployed on the monitored host (physical machine or open-source system node) and is responsible for collecting raw stack trace information using eBPF technology and sending the data to the Server.

[0026] The server is responsible for receiving data sent by the agent, centrally storing and managing the debugging dependencies of the target application, performing the symbolization process, converting the raw stack information into a human-readable format, and providing profiling results or integration with other analysis platforms.

[0027] Symbolization is the process of resolving memory addresses into function names, file names, and line numbers, making it easier for developers to understand the calling relationships during program runtime.

[0028] Build ID, a unique identifier, is embedded in files such as ELF, PDB, Mach-O, and WASM files. It is used to locate the corresponding binary / symbolic file on the server side and to achieve symbolization.

[0029] According to an embodiment of the present invention, an embodiment of an application performance testing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing an application performance testing method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0032] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the application performance detection method in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the application performance detection method described above. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0034] Figure 2 This is a flowchart illustrating the application performance testing method provided according to an embodiment of the present invention, as shown below. Figure 2 As shown, the method includes the following steps:

[0035] Step S201: Receive the raw stack data of the target application transmitted by the agent. The raw stack data includes function data or address data. The function data includes the identifier of the file where the calling function is located and the offset of the calling function. The address data is the memory address data of the calling function. The agent is set on the host where the target application is located. The agent program includes the extended Berkeley package filter program.

[0036] In this step, the server receives raw stack data transmitted from the proxy deployed on the host where the target application resides. This data is collected by the Extended Berkeley Package Filter (eBPF) program. The raw stack data includes function data or address data. Function data includes the identifier of the file where the calling function resides (such as the Build ID) and the offset at which the function is running, while address data directly represents the memory address of the calling function.

[0037] eBPF, a technology for efficiently running custom code in both kernel and user space, can capture application runtime stack information by attaching to key points such as system calls or function entry points, without modifying kernel or application code. The agent side can contain one or more eBPF programs responsible for collecting this data and sending it to the server. The server then performs subsequent symbolic processing, transforming the raw stack data into readable performance profiling results, such as function names, file names, and line numbers, thereby helping developers locate and optimize software performance bottlenecks.

[0038] For example, one or more eBPF programs included in the Agent can be attached to appropriate hook points (such as perf_event, kprobes / uprobes). Stack information can be collected using the bpf_get_stack() helper function, by setting the BPF_F_USER_STACK flag to collect both user-space and kernel-space stacks. The collected data is then passed from the eBPF program to the Agent's user-space process via BPF_MAP_TYPE_PERF_EVENT_ARRAY or BPF_MAP_TYPE_RINGBUF.

[0039] eBPF's stack backtracking logic does not depend on whether the target program uses frame pointers for compilation, and it does not require DWARF parsing, thus avoiding the introduction of complex and high-overhead parsing libraries and the deployment of large debug files. It uses Build ID + offset to collect user-space stacks, pushing the responsibility of address resolution to the server. It also has reliability and rollback mechanisms, logging failure information or attempting to send the original memory address in cases such as failure to obtain the Build ID.

[0040] Step S202: Based on the original stack data, determine the symbolic data corresponding to the target application, wherein the symbolic data includes the name of the called function, the file path of the called function, and the source code line number of the called function.

[0041] In this step, the server receives raw stack data, including but not limited to the Build ID and runtime offset of the called function, or direct memory addresses. By querying the centrally stored dependency libraries, the server uses the Build ID as an index to locate the binary file and library corresponding to the target application, executes a symbolication algorithm, and maps the raw addresses to the name of the called function, the file path where it is located, and the source code line number, thereby generating symbolic data. This transformation greatly improves developers' ability to understand and locate performance bottlenecks, enabling accurate performance profiling results even in production environments without debugging information, providing crucial evidence for optimizing resource utilization and improving user experience.

[0042] For example, after receiving the raw stack data packet from the Agent, the system can locate dependent files based on the Build ID, download the files or retrieve them from the cache, and then call the symbolization library to parse the files, converting offsets into function names and other information. For address data, additional process memory mapping information is required to calculate the Build ID and offset before symbolization. Kernel stack addresses can also be symbolized from the kernel symbol file based on the kernel version information provided by the Agent. Finally, the symbolized profiling data is stored.

[0043] Step S203: Based on symbolic data, determine the performance test results of the target application, wherein the performance test results include function execution paths and resource consumption.

[0044] In this step, after receiving the raw stack trace data and successfully converting it into symbolic data containing function names, file paths, and source code line numbers, the server further analyzes this data to depict the function execution paths of the target application and assess resource consumption. Through statistical analysis and aggregation of the symbolic data, visualizations such as flame graphs can be generated, clearly showing the application's call hierarchy and hot functions, while also calculating resource consumption metrics such as CPU time percentage and memory usage for each function. These performance test results provide developers with in-depth insights, helping to identify performance bottlenecks, optimize code logic, and rationally allocate computing resources, thereby improving the overall performance of the application and the user experience.

[0045] Through the above steps, the symbolization process is centralized on the server side, thereby significantly reducing the deployment complexity in the production environment and optimizing resource utilization. This solves the technical problems of high complexity and high overhead in the deployment and operation of current application performance testing technologies in the production environment.

[0046] As an optional embodiment, determining the symbolic data corresponding to the target application based on the original stack data includes: when the original stack data is function data, determining the dependency files of the target application in a preset centralized dependency file library based on identifiers; and parsing the dependency files of the target application based on the preset symbolic library to obtain symbolic data.

[0047] Optionally, when the raw stack data collected by the agent using eBPF technology is represented as function data, it includes the identifier (such as the Build ID) and runtime offset of the file where the calling function resides. The server uses this identifier as an index to locate the specific dependency file of the target application from a pre-defined centralized dependency file library. This dependency file library is pre-configured to store resources such as binary files and shared libraries containing debugging information, and is organized by Build ID for easy and quick lookup. Subsequently, the server calls a pre-defined symbolic library to parse the located dependency file, and combines the offset information from the raw stack data to convert the memory address into symbolic data such as the specific function name, file path, and source code line number. This enables in-depth analysis of application performance in a production environment without deploying any debugging dependencies on the monitored host. This process not only simplifies the complexity of the agent and reduces runtime overhead, but also improves the system's scalability and maintainability through centralized management of dependency files.

[0048] As an optional implementation, the construction steps of the preset centralized dependency file library are as follows: construct a blank initial extensible repository; obtain multiple dependency files, wherein the multiple dependency files include an executable file with debugging information, a separate debugging information file, and source files; determine the identifiers of the multiple files; construct a hash hierarchical directory based on the identifiers of the multiple files; and store the multiple dependency files in the initial extensible repository based on the hash hierarchical directory to obtain the centralized dependency file library.

[0049] Optionally, first, a blank, scalable repository can be created to hold future dependency files. Next, various files with debugging information are collected, such as executables, shared libraries, individual debugging information files, source files, and perf-map files. Each file is assigned a unique identifier, typically a Build ID, for precise indexing. Using the Build ID as the core index key, files are organized using a specific directory structure (such as a hash-based hierarchical directory based on the Build ID), optimizing file storage and retrieval efficiency. Finally, based on the built directory structure, all dependency files are stored in the initial scalable repository, forming a centralized dependency file library. A suitable storage backend (such as object storage) is selected, and dependency files are retrieved by integrating with a CI / CD pipeline or pulling from a public symbol server. The establishment of the repository ensures that the server can quickly and accurately find the symbolic dependencies of the target application, enabling consistent performance monitoring and analysis across hosts and container environments, reducing the complexity of production deployment, and improving the overall efficiency and maintainability of the system.

[0050] As an optional embodiment, when the original stack data is address data, the offset is calculated based on the memory start address and memory end address in the memory address data; the binary file corresponding to the called function is determined based on the memory address data; an identifier is determined in the binary file; and function data is constructed based on the offset and the identifier.

[0051] Optionally, when processing raw stack information in the form of address data, the server first parses the memory address data to extract the start and end addresses of the called function, and then calculates the offset. Next, based on the memory address information, the server locates the binary file corresponding to the target called function; this process may require accessing the file system or memory-mapped view. Once the binary file is identified, the server searches for its Build ID as an identifier, which is crucial for subsequent symbolic dependency location. Finally, the calculated offset is combined with the identifier to form function data for subsequent symbolic resolution, which is then transformed into easily understandable performance monitoring results, such as function names, file paths, and source code line numbers, comprehensively revealing the application's runtime status and resource consumption details.

[0052] As an optional embodiment, the performance test results of the target application are determined based on symbolic data, including: determining hot functions, call frequency, and execution time of hot functions in the target application based on symbolic data; determining function execution paths and resource consumption based on hot functions, call frequency, and execution time; and converting the function execution paths and resource consumption into a flame graph and displaying it on a preset display platform.

[0053] Optionally, when generating performance test results based on symbolic data, the server analyzes the data to identify hot functions in the target application, tracking their call frequency and execution time—the foundation for performance bottleneck analysis. By statistically analyzing hot functions, the frequency and time consumption distribution of function calls are constructed, thereby identifying key function execution paths and resource consumption details. This analysis process reveals which functions or code segments are the main sources of performance consumption. This data can then be converted into an intuitive visual representation—a flame graph. Each bar represents a function call stack, and the width of the bars reflects the function's execution time or call frequency, helping to quickly locate performance problems. The flame graph data is then presented on a pre-defined display platform, such as a web interface, or integrated into other monitoring tools, facilitating the development and operations teams to analyze and optimize application performance and improve resource utilization efficiency.

[0054] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0055] Through the above description of the embodiments, those skilled in the art can clearly understand that the application performance testing method according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform. Of course, it 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 the present invention, in essence, or the part that contributes to the prior art, 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 a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0056] According to an embodiment of the present invention, an application performance testing system is also provided, comprising: a server for executing any of the application performance testing methods described above; and a proxy for obtaining the raw stack data of a target application and transmitting the raw stack data to the server.

[0057] Optionally, Figure 3 This is a logical architecture diagram of an application performance detection system provided by an optional embodiment of the present invention. Figure 3 As shown, the application performance monitoring system consists of a server and a proxy. The proxy is deployed on the monitored host and uses eBPF technology to non-intrusively capture the raw stack data of the target application during runtime, including memory addresses and call context information, and transmits it securely and efficiently to the server. The server receives this data, uses a pre-defined centralized dependency file library for symbolization, and resolves abstract memory addresses into specific function names, file paths, and line numbers. It then analyzes the program's execution path and resource consumption, generating performance monitoring results, such as hot functions, their call frequency, and execution time, displayed in flame graph form. This allows users to intuitively understand the application's performance bottlenecks and optimization directions.

[0058] The Agent can be configured to monitor all processes, a specific list of process PIDs, or select targets by container identifier. In an open-source system environment, it identifies processes within containers by analyzing process cgroup or namespace information and associates the collected information with the container. It handles namespace isolation, correctly identifying the process's PID namespace. It collects data containing sufficient metadata (such as timestamps, process IDs, container IDs, Kubernetes tags, etc.). The open-source Agent adopts the DaemonSet pattern, running one Agent Pod instance on each (or selected) Node in the cluster. This aligns well with eBPF's system-level, low-overhead characteristics, simplifying deployment and management while minimizing resource consumption. The Server has the capability to receive a large number of concurrent data streams or batches from Agents, parses and verifies the received data, and stores the raw stack traces and metadata (which can be initially stored in temporary storage or a message queue for asynchronous processing).

[0059] As an optional embodiment, the agent converts the original stack data into a binary serialization format and transmits it to the server through a preset communication protocol, wherein the preset communication protocol is determined based on the size of the original stack data.

[0060] Optionally, the raw stack data, metadata, and sample counts collected by the agent, including information such as memory addresses and call context, are packaged and first converted into a compact binary serialization format, such as Protocol Buffers, to reduce the amount of data and bandwidth consumption during transmission. This is then transmitted in batches or streams via a network connection (such as TCP), with data compression considered. Based on the size of the stack data, the agent can choose the most suitable communication protocol for transmission. When the data volume is moderate and controllable and real-time performance is highly demanding, the gRPC protocol is preferred to achieve efficient and reliable point-to-point communication. For scenarios involving massive amounts of data or high-concurrency collection, requiring buffering and decoupling, message queue technologies such as Kafka can be chosen to adapt to the buffering needs and decoupling characteristics of the data stream, ensuring stable transmission of raw stack data to the server for further processing even under high load.

[0061] Embodiments of the present invention may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one of a plurality of network devices in a computer network. The computer device includes a memory and a processor.

[0062] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the application performance detection method and apparatus in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned application performance detection method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0063] The processor can access information and applications stored in memory via a transmission device to perform the following steps: receiving raw stack data of the target application transmitted from an agent, wherein the raw stack data includes function data or address data, the function data includes the identifier of the file where the called function is located and the offset of the called function, and the address data is the memory address data of the called function, the agent is located on the host where the target application is located, and the agent program includes an extended Berkeley package filter program; determining the symbolic data corresponding to the target application based on the raw stack data, wherein the symbolic data includes the name of the called function, the file path of the called function, and the source code line number of the called function; and determining the performance test results of the target application based on the symbolic data, wherein the performance test results include the function execution path and resource consumption.

[0064] Optionally, the processor may also execute program code that performs the following steps: determining symbolic data corresponding to the target application based on the original stack data, including: when the original stack data is function data, determining the dependency files of the target application in a preset centralized dependency file library based on identifiers; and parsing the dependency files of the target application based on the preset symbolic library to obtain symbolic data.

[0065] Optionally, the processor may also execute program code with the following steps: The construction steps of the pre-defined centralized dependency file library are as follows: construct a blank initial extensible repository; obtain multiple dependency files, wherein the multiple dependency files include an executable file with debugging information, a separate debugging information file, and source files; determine the identifiers of the multiple files; construct a hash hierarchical directory based on the identifiers of the multiple files; and store the multiple dependency files in the initial extensible repository based on the hash hierarchical directory to obtain the centralized dependency file library.

[0066] Optionally, the processor may also execute program code that performs the following steps: when the original stack data is address data, calculate the offset based on the memory start address and memory end address in the memory address data; determine the binary file corresponding to the called function based on the memory address data; determine the identifier in the binary file; and construct function data based on the offset and the identifier.

[0067] Optionally, the processor may also execute program code that performs the following steps: Based on symbolic data, determine the performance test results of the target application, including: Based on symbolic data, determine the hot functions, call frequency, and execution time of the hot functions in the target application; Based on the hot functions, call frequency, and execution time, determine the function execution path and resource consumption; Convert the function execution path and resource consumption into a flame graph and display it on a preset display platform.

[0068] This invention provides an application performance testing method. It receives raw stack data of a target application transmitted from a proxy, where the raw stack data includes function data or address data. The function data includes the identifier of the file containing the called function and the offset of the called function's execution. The address data is the memory address of the called function. The proxy is located on the host where the target application resides, and the proxy program includes an extended Berkeley package filter program. Based on the raw stack data, symbolic data corresponding to the target application is determined, where the symbolic data includes the name of the called function, the file path of the called function, and the source code line number of the called function. Based on the symbolic data, the performance testing result of the target application is determined, where the performance testing result includes the function execution path and resource consumption. This method centralizes the symbolic process on the server side, thereby significantly reducing deployment complexity in a production environment and optimizing resource utilization. It also solves the technical problems of high complexity and high overhead in the deployment and operation of current application performance testing technologies in production environments.

[0069] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a non-volatile storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0070] Embodiments of the present invention also provide a non-volatile storage medium. Optionally, in this embodiment, the aforementioned non-volatile storage medium can be used to store the program code executed by the application performance testing method provided in the above embodiments.

[0071] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0072] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: receiving raw stack data of the target application transmitted by the agent, wherein the raw stack data includes function data or address data, the function data includes the identifier of the file where the called function is located and the offset of the called function, and the address data is the memory address data of the called function, the agent is set in the host where the target application is located, and the agent program includes an extended Berkeley package filter program; determining symbolic data corresponding to the target application based on the raw stack data, wherein the symbolic data includes the name of the called function, the file path of the called function, and the source code line number of the called function; and determining the performance test results of the target application based on the symbolic data, wherein the performance test results include the function execution path and resource consumption.

[0073] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: determining symbolic data corresponding to the target application based on the original stack data, including: when the original stack data is function data, determining the dependency files of the target application in a preset centralized dependency file library based on identifiers; and parsing the dependency files of the target application based on the preset symbolic library to obtain symbolic data.

[0074] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: The construction steps of the preset centralized dependency file library are as follows: construct a blank initial extensible repository; obtain multiple dependency files, wherein the multiple dependency files include an executable file with debugging information, a separate debugging information file, and source files; determine the identifiers of the multiple files; construct a hash hierarchical directory based on the identifiers of the multiple files; and store the multiple dependency files in the initial extensible repository based on the hash hierarchical directory to obtain the centralized dependency file library.

[0075] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: when the original stack data is address data, calculate the offset based on the memory start address and memory end address in the memory address data; determine the binary file corresponding to the called function based on the memory address data; determine the identifier in the binary file; and construct function data based on the offset and the identifier.

[0076] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: determining the performance test results of the target application based on symbolic data, including: determining hot functions, call frequency, and execution time of hot functions in the target application based on symbolic data; determining function execution paths and resource consumption based on hot functions, call frequency, and execution time; and converting the function execution paths and resource consumption into a flame graph and displaying it on a preset display platform.

[0077] Embodiments of the present invention also provide a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can: receive raw stack data of a target application transmitted from an agent, wherein the raw stack data includes function data or address data, the function data includes the identifier of the file where the calling function is located and the offset of the calling function, and the address data is the memory address data of the calling function. The agent is set in the host where the target application is located, and the agent program includes an extended Berkeley package filter program; based on the raw stack data, determine the symbolic data corresponding to the target application, wherein the symbolic data includes the name of the calling function, the file path of the calling function, and the source code line number of the calling function; based on the symbolic data, determine the performance test result of the target application, wherein the performance test result includes the function execution path and resource consumption.

[0078] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0079] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0080] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0081] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0083] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0084] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for testing application performance, characterized in that, include: The system receives raw stack data of the target application transmitted from the proxy end. The raw stack data includes function data or address data. The function data includes the identifier of the file where the calling function is located and the offset of the calling function. The address data is the memory address data of the calling function. The proxy end is set in the host where the target application is located. The proxy program end includes an extended Berkeley package filter program. Based on the original stack data, the symbolic data corresponding to the target application is determined, wherein the symbolic data includes the name of the called function, the file path of the called function, and the source code line number of the called function; Based on the symbolic data, the performance test results of the target application are determined, wherein the performance test results include function execution paths and resource consumption.

2. The method according to claim 1, characterized in that, The step of determining the symbolic data corresponding to the target application based on the original stack data includes: If the original stack data is the function data, the dependency files of the target application are determined from a preset centralized dependency file library based on the identifier; Based on a pre-defined symbolization library, the dependency files of the target application are parsed to obtain the symbolized data.

3. The method according to claim 2, characterized in that, The steps for constructing the preset centralized dependency file library are as follows: Build a blank initial scalable repository; Obtain multiple dependency files, including an executable file with debugging information, a separate debugging information file, and source files; Determine the identifiers for each of the plurality of files; Based on the identifiers of the various files, a hash-based hierarchical directory is constructed; Based on the hash-hierarchical directory, the multiple dependency files are stored in the initial scalable repository to obtain the centralized dependency file library.

4. The method according to claim 2, characterized in that, Also includes: If the original stack data is the address data, the offset is calculated based on the memory start address and memory end address in the memory address data; Based on the memory address data, the binary file corresponding to the called function is determined; The identifier is determined in the binary file; The function data is constructed based on the offset and the identifier.

5. The method according to any one of claims 1 to 4, characterized in that, The process of determining the performance test results of the target application based on the symbolized data includes: Based on the symbolic data, the hot functions in the target application, the call frequency of the hot functions, and the execution time of the hot functions are determined. Based on the hot-button functions, their call frequency, and execution time, the function execution path and resource consumption are determined. The function execution path and resource consumption are converted into a flame graph and displayed on a preset display platform.

6. An application performance testing system, characterized in that, include: The server is used to execute the application performance detection method according to any one of claims 1 to 5; The proxy is used to obtain the raw stack data of the target application and transmit the raw stack data to the server.

7. The system according to claim 6, characterized in that, The proxy converts the original stack data into a binary serialization format and transmits it to the server through a preset communication protocol, wherein the preset communication protocol is determined based on the size of the original stack data.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is running, the device containing the non-volatile storage medium is controlled to execute the application performance testing method according to any one of claims 1 to 5.

9. A computer device, characterized in that, include: Memory and processor The memory stores computer programs; The processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, the processor performs the application performance detection method according to any one of claims 1 to 5.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the application performance detection method according to any one of claims 1 to 5.

Images