Performance detection method, device, readable medium and electronic device for middle-layer application

Abstract

The present disclosure relates to a performance detection method, device, readable medium, and electronic device for a middle-layer application. The method comprises: receiving a performance detection instruction for instructing to detect the performance of the middle-layer application; obtaining performance indicator parameters of the middle-layer application when the middle-layer application is in a running state, wherein the middle-layer application is capable of processing requests sent by an upstream server and sending them to a downstream server and receiving results returned by the downstream server when the middle-layer application is in a running state; and detecting the performance of the middle-layer application based on the performance indicator parameters and the abnormal conditions corresponding to each preset abnormality type. In this way, by directly matching the obtained performance indicator parameters with the abnormal conditions corresponding to each preset abnormality type, the performance detection results of the middle-layer application can be accurately obtained, thereby improving the degree of automation of the performance detection of the middle-layer application and thereby improving the efficiency of the performance detection of the middle-layer application.

Description

Technical Field

[0001] The present disclosure relates to the field of computer application technology, and in particular to a performance detection method, device, readable medium, and electronic device for an intermediate layer application. Background Art

[0002] Middle-tier applications refer to computer software that uses the "distribution-collection" communication model. With the development and widespread application of computer technology, middle-tier applications have been widely developed and deployed to process large amounts of data in computer systems. Figure 1 This is a schematic diagram of the middle-tier application communication mode. Figure 1 As shown, first, the middle-tier application 20 receives the request sent from the upstream server 10. Then, the middle-tier application 20 distributes the request. Since the amount of data required to process this request is large, and this data is stored in N downstream servers 30, and access services are provided by the downstream servers 30, the middle-tier application 20 splits the request sent by the upstream server 10 into N sub-requests, processes each sub-request, and sends it to the N downstream servers 30. Afterwards, the downstream server uses its own data shards to process the sub-requests and returns the results to the middle-tier application 20. Finally, the middle-tier application 20 collects the returned results. For example, the middle-tier application 20 receives the results returned by N downstream servers, aggregates the N results, and returns them to the upstream server 10 to complete the processing of the request. Therefore, the efficiency of request processing is closely related to the performance of the middle-tier application. It is necessary to test the performance of the middle-tier application to ensure the efficiency of request processing. Summary of the Invention

[0003] This section is provided to briefly introduce the concepts that will be described in detail in the detailed description of the embodiments below. This section is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0004] In a first aspect, the present disclosure provides a performance detection method for a middle-layer application, comprising:

[0005] receiving a performance detection instruction for instructing to detect the performance of the middle-layer application;

[0006] When the middle-tier application is in a running state, obtaining performance indicator parameters of the middle-tier application, wherein when the middle-tier application is in a running state, it is capable of processing a request sent by an upstream server and sending it to a downstream server and receiving a result returned by the downstream server;

[0007] The performance of the middle layer application is detected according to the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality.

[0008] In a second aspect, the present disclosure provides a performance detection device for a middle-layer application, comprising:

[0009] A receiving module, configured to receive a performance detection instruction for instructing to detect the performance of the middle-layer application;

[0010] an acquisition module, configured to acquire performance indicator parameters of the middle-tier application when the middle-tier application is in a running state, wherein the middle-tier application, when in a running state, is capable of processing requests sent by an upstream server and sending them to a downstream server, and receiving results returned by the downstream server;

[0011] The detection module is used to detect the performance of the middle layer application according to the performance indicator parameters and the abnormal conditions corresponding to each type of preset abnormality.

[0012] In a third aspect, the present disclosure provides a computer-readable medium having a computer program stored thereon, which implements the steps of the method described in the first aspect when executed by a processing device.

[0013] In a fourth aspect, the present disclosure provides an electronic device, comprising:

[0014] a storage device having at least one computer program stored thereon;

[0015] At least one processing device is used to execute the at least one computer program in the storage device to implement the steps of the method described in the first aspect of the present disclosure.

[0016] Through the above technical solution, while the middle-layer application is in operation, performance indicator parameters of the middle-layer application are obtained, and the performance of the middle-layer application is tested based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality. In this way, by directly matching the obtained performance indicator parameters with the preset abnormal conditions corresponding to each type of abnormality, the performance test results of the middle-layer application can be accurately obtained, thereby improving the automation level of the performance test of the middle-layer application and thereby improving the efficiency of the performance test of the middle-layer application.

[0017] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and other features, advantages and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that the originals and elements are not necessarily drawn to scale. In the drawings:

[0019] Figure 1 It is a schematic diagram of the middle-tier application communication mode;

[0020] Figure 2 is a flow chart of a performance detection method for a middle-tier application provided according to an embodiment of the present disclosure;

[0021] Figure 3 is a schematic diagram of the architecture of a middle-layer application provided according to an embodiment of the present disclosure;

[0022] Figure 4 This is a display interface for performance indicator parameters of a middle-layer application provided according to an embodiment of the present disclosure;

[0023] Figure 5 is a block diagram of a performance detection device for a middle-layer application provided according to an embodiment of the present disclosure;

[0024] Figure 6 A schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0025] In order to meet the requirements of high QPS (Query-Per-Second) and low latency, and to reduce the difficulty of application development, middle-tier applications have the following characteristics: (1) Middle-tier applications rely on multi-layer software frameworks and libraries to build and run. First, since middle-tier applications use RPC (Remote Procedure Call) to communicate with upstream and downstream servers, middle-tier applications need to be built using the RPC framework. Second, the operation of middle-tier application threads depends on the management and scheduling of the operating system kernel. This multi-layer software architecture increases the complexity of middle-tier application execution. (2) Middle-tier applications use a large number of asynchronous and concurrent designs. Among them, asynchronous and concurrent operations can easily mask the root cause of application performance anomalies, making it difficult to detect application performance. (3) The performance of middle-tier applications depends on multiple downstream servers, and performance fluctuations of downstream servers can also cause performance anomalies of middle-tier applications. Since middle-tier applications are usually deployed in data centers and their own characteristics make it difficult to detect their performance, it is necessary to provide a performance detection method for middle-tier applications to help developers understand the current performance status of middle-tier applications, locate application execution anomalies, and discover potential optimization directions for applications.

[0026] However, in related technologies, when testing the performance of middle-tier applications, the performance indicators are not further processed, resulting in a certain gap between the performance results intuitively understood by users and the collected performance indicators. The system performance cannot be directly evaluated from the collected data, resulting in low efficiency in performance testing of middle-tier applications.

[0027] In view of this, the present disclosure provides a performance detection method, device, readable medium and electronic device for a middle-layer application, which can automatically detect the performance of the middle-layer application and improve the efficiency of performance detection of the middle-layer application.

[0028] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0029] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0030] As used herein, the term "including" and its variations are open-ended, i.e., "including but not limited to." The term "based on" means "based, at least in part, on." The term "one embodiment" means "at least one embodiment," the term "another embodiment" means "at least one additional embodiment," and the term "some embodiments" means "at least some embodiments." Other terms are defined in the following description.

[0031] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0032] It should be noted that the modifications of "one" and "multiple" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, they should be understood as "one or more".

[0033] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0034] All actions of acquiring signals, information or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where they are located and with the authorization given by the owner of the corresponding device.

[0035] It is understandable that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved in this disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0036] For example, in response to a user's active request, a prompt message is sent to the user to clearly inform the user that the operation requested will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operations of the disclosed technical solution based on the prompt message.

[0037] As an optional but non-limiting implementation, in response to receiving a user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0038] It is understandable that the above notification and user authorization process are merely illustrative and do not limit the implementation of the present disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0039] At the same time, it is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) must comply with the requirements of relevant laws, regulations and relevant provisions.

[0040] Figure 2 This is a flow chart of a performance detection method for an intermediate layer application provided according to an embodiment of the present disclosure. Figure 2 As shown, the method provided by the present disclosure may include steps 21 to 23.

[0041] In step 21, a performance detection instruction for instructing to detect the performance of the middle-layer application is received.

[0042] In the present disclosure, the execution subject of the performance detection method of the middle-layer application can be a server of the middle-layer application, wherein the middle-layer application can be a microserver application, a microserver system, etc.

[0043] In step 22, when the middle-layer application is in the running state, the performance indicator parameters of the middle-layer application are obtained.

[0044] It should be understood that the server can receive the performance test instruction when the middle-tier application is in a running state, or it can receive the performance test instruction when the middle-tier application is not in a running state, and this disclosure does not specifically limit this. If the performance test instruction is received when the middle-tier application is not in a running state, the server must wait until the middle-tier application is in a running state before obtaining the performance indicator parameters of the middle-tier application.

[0045] Among them, when the middle-tier application is in a running state, it is able to process the request sent by the upstream server and send it to the downstream server and receive the result returned by the downstream server. The performance indicator parameters of the middle-tier application may include performance parameters in the process of the middle-tier application processing the request and sending it to the downstream server, and / or performance indicator parameters in the process of receiving the result returned by the downstream server. In addition, considering that the time period from the middle-tier application receiving the request sent by the upstream server to the final result returned to the upstream server (i.e., the request delay time) is the most critical performance parameter of the middle-tier application, therefore, in a possible way, the performance indicator parameter can be a time-related parameter in the process of the middle-tier application processing and sending the request, and / or a time-related parameter in the process of receiving the result returned by the downstream server.

[0046] In step 23, the performance of the middle-layer application is tested based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality.

[0047] For example, for each type of exception, it is determined whether there are parameters in the performance indicator parameters that meet the exception conditions corresponding to the type of exception. If there are parameters that meet the exception conditions corresponding to the type of exception, it is determined that the middle-layer application has this type of exception.

[0048] Because middle-tier applications rely on multi-layer software frameworks and libraries for construction and operation, and their performance depends on multiple downstream servers, middle-tier applications typically experience multiple types of exceptions. In this disclosure, to improve the efficiency of performance testing for middle-tier applications, exception conditions corresponding to each type of exception are pre-set. This allows accurate performance testing results for middle-tier applications to be obtained by directly matching the acquired performance indicator parameters with the pre-set exception conditions corresponding to each type of exception.

[0049] Using the above technical solution, while the middle-tier application is in operation, performance indicator parameters of the middle-tier application are obtained, and the performance of the middle-tier application is tested based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality. This allows accurate performance test results of the middle-tier application to be obtained simply by matching the obtained performance indicator parameters with the preset abnormal conditions corresponding to each type of abnormality, thereby improving the automation and efficiency of performance testing of the middle-tier application.

[0050] In order to facilitate those skilled in the art to better understand the specific implementation of the performance detection method for the middle-layer application provided by the present disclosure, the method provided by the present disclosure is described below with a complete embodiment.

[0051] In related technologies, the application's runtime is often used to detect possible abnormal code in the application, or the application's performance is only detected using performance indicator parameters obtained from the kernel space. In this way, due to the lack of comprehensiveness of the collected data, the abnormal range of the middle-layer application detection is limited, and the granularity of the middle-layer application performance display is not refined enough, thus making it impossible to fully detect the performance of the middle-layer application. Therefore, in order to improve the comprehensiveness of the obtained performance indicator parameters, in the present disclosure, multiple software layer data can be collected simultaneously. For example, when the middle-layer application is in a running state, the performance indicator parameters of the middle-layer application can be obtained from the user space and the kernel space.

[0052] It should be understood that the type of performance indicator parameter obtained usually needs to be determined in combination with the architecture of the middle-layer application. Figure 3 This is a schematic diagram of the architecture of the middle layer application provided according to an embodiment of the present disclosure. Figure 3As shown, the right side shows the key code flow for the middle-tier application processing a request, while the left side shows the main components of the middle-tier application and their relationships. The first code block on the right, the computing function + the sending function, indicates that the middle-tier application performs certain computations on the request after receiving it and then sends it. The second code block (the for loop) shows the specific process of the middle-tier application sending N subrequests to the downstream server. The middle-tier application first preprocesses each subrequest (for example, by calling the pre_process function) and then calls the query function to send the subrequest to the downstream server. Each query function is linked to the do_rpc function in the RPC framework layer. In the operating system kernel, the do_rpc function is linked to the tcp_sendmsg function call. Furthermore, the operating system calls the tcp_recvmsg function to receive the return data from the downstream server. The tcp_sendmsg function is used to send the subrequest to the downstream server using TCP (Transmission Control Protocol) technology, and the tcp_recvmsg function is used to receive the return data from the downstream server using TCP technology.

[0053] The middle-tier application includes three thread pools (upstream-io, worker, and downstream-io) and three queues (request queue, subrequest queue, and result queue). The upstream-io thread pool is responsible for receiving upstream requests and replying to the corresponding results. The worker thread pool is responsible for request preprocessing, for loop code, and do_rpc function execution. The downstream-io thread pool is responsible for sending and receiving subrequests, namely, for executing the tcp_sendmsg and tcp_recvmsg functions.

[0054] based on Figure 3 The architecture of the middle-tier application shown determines the type of performance indicator parameter obtained. For example, after determining the type of the performance indicator parameter, an eBPF program can be written and used to track the execution information of key functions of the middle-tier application using Linux user mode and kernel tracing technologies such as uprobe and kprobe to collect function execution time information and thread scheduling time information.

[0055] It should be understood that an eBPF program can be deployed on the server of the middle-tier application to be tested to achieve the purpose of obtaining performance indicator parameters in the above manner. In addition, the duration of data acquisition can be set (for example, 30 seconds), and the performance indicator parameters obtained during this duration are saved to the server hard disk. The following describes a specific implementation method for obtaining performance indicator parameters of middle-tier applications.

[0056] First, when the middle-tier application is in running state, the first tracking technology is used to obtain the execution time information of the first-class function running in the user space, as well as the request identifier corresponding to each execution of each first-class function, so as to obtain the execution time information of the first-class function corresponding to each request.

[0057] The first tracing technology is uprobe technology, and the first type of function is a function running in user space, such as computing functions, sending functions, and do_rpc functions. Computing functions and sending functions have longer running times, while do_rpc functions have shorter running times. Therefore, when the first type of function is a computing function or a sending function, the execution time information may include the function's start time, end time, and running time. When the first type of function is a do_rpc function, the execution time information is the start time of the do_rpc function.

[0058] For example, we use uprobe technology to track the execution time information of the computing and sending functions to obtain the execution start and end times of the computing and sending functions. We also obtain the request identifier reqid corresponding to each execution of the computing and sending functions to obtain the execution start and end times of the computing and sending functions corresponding to each request. Furthermore, we use uprobe technology to track the execution time information of the do_rpc function to obtain the execution start time of the do_rpc function.

[0059] It should be understood that when the middle-layer application is in running state, it may process multiple requests, and the performance indicator parameters of the middle-layer application obtained may be the performance indicator parameters of the middle-layer application when processing multiple requests. Therefore, in order to further distinguish the performance indicator parameters corresponding to each request, in this disclosure, it is also necessary to obtain the request identifier corresponding to each execution of each first-class function each time, so as to obtain the execution time information of the first-class function corresponding to each request.

[0060] Next, the second tracing technology is used to obtain the execution time information of the second-class functions running in the kernel space, as well as the request identifier corresponding to each execution of each second-class function, to obtain the execution time information of the second-class function corresponding to each request. The second-class functions include scheduling functions for scheduling threads and sending and receiving functions for sending and receiving requests.

[0061] The second tracing technique, kprobe, involves functions running in kernel space, including scheduling functions and transceiver functions. For example, transceiver functions may include tcp_sendmsg and tcp_recvmsg, while scheduling functions may include ttwu_do_wakeup, wake_up_new_task, and finish_task_switch. The ttwu_do_wakeup and wake_up_new_task functions are used to wake up threads, while the finish_task_switch function is used to terminate threads.

[0062] For example, we use kprobe technology to track the execution start time of the tcp_sendmsg and tcp_recvmsg functions to obtain their execution start time. We also use kprobe technology to track the execution start time of the ttwu_do_wakeup, wake_up_new_task, and finish_task_switch functions to obtain the execution time information of the second-category functions corresponding to each request.

[0063] Afterwards, based on the execution time information of the function for scheduling threads corresponding to each request, the scheduling information of the threads executing the first type of functions and the functions for receiving and sending requests is determined to obtain the scheduling time information of the threads corresponding to each request.

[0064] For example, a thread's scheduling information may include its scheduling delay and run time. First, based on the execution start times of the ttwu_do_wakeup, wake_up_new_task, and finish_task_switch functions in the second category, the start scheduling time sched, the start run time run, and the end run time end of the worker thread that executes the computing, sending, and do_rpc functions are determined. The worker thread's scheduling delay sched_delay = run - sched, and its run time run_time = end - run are then calculated. Similarly, the scheduling delay sched_delay and run time run_time of the downstream-io thread that executes the tcp_sendmsg and tcp_recvmsg functions are calculated.

[0065] It should be understood that both worker threads and downstream-io threads can include multiple threads. For example, worker threads and downstream-io threads each include 16 threads, and each thread can be scheduled once or multiple times. In the present disclosure, through the above-mentioned kprobe technology, the worker thread set tid_set_1 of the execution function corresponding to each request can be obtained. Similarly, the downstream-io thread set tid_set_2 of the execution function corresponding to each request can also be obtained. Among them, each thread set can include the scheduling delay time and running time of each thread.

[0066] Finally, the start time and end time of each request are obtained, and the offline time information of the thread corresponding to each request is determined based on the start time, end time and the scheduling time information of the thread.

[0067] It should be understood that the start time of each request refers to the execution start time of the computing function corresponding to each request, and the end time of each request refers to the execution end time of the sending function corresponding to each request. Therefore, based on the execution start and end times of the computing and sending functions corresponding to each request determined above, the start and end times of each request can be determined. Subsequently, the time between the start and end times, excluding the thread's scheduling delay time and running time, is recorded as the thread's offline time information off_time.

[0068] Furthermore, when tracking the execution time of the tcp_sendmsg and tcp_recvmsg functions using kprobe technology, it is also possible to extract the contents of a portion of the data packet transmitted by the tcp_sendmsg function and the contents of a portion of the data packet transmitted by the tcp_recvmsg function to obtain the request identifier reqid from the portion of the data packet content. For example, the location of the request identifier in the data packet is known in advance, and then the data at that location is extracted to obtain the request identifier reqid.

[0069] It should be understood that the performance indicator parameters corresponding to each request can be obtained according to the above acquisition method. When storing, the performance indicator parameters corresponding to each request can be represented by a key-value pair. For example, in a key-value pair, the key represents the request identifier of the request, and the value represents the performance indicator parameter corresponding to the request.

[0070] Compared with the related technology of only obtaining performance indicator parameters from the kernel space, the above technical solution improves the comprehensiveness of the obtained performance indicator parameters, expands the data acquisition source, increases the scope of detectable application anomalies, and further improves the performance detection efficiency of middle-layer applications.

[0071] After obtaining the performance indicator parameters corresponding to each request in the above manner, the performance indicator parameters can also be displayed. For example, for each request, the performance indicator parameters of the middle-tier application corresponding to the request are displayed on the same display interface. For example, the open source visualization library plotly can be used to achieve the purpose of displaying the performance indicator parameters of the middle-tier application.

[0072] For example, Figure 4 This is a display interface for the performance indicator parameters of the middle layer application provided according to an embodiment of the present disclosure. Figure 4 As shown in the figure, when the middle-tier application processes a request, it divides it into two batches (batch1 and batch2) for processing, and calls two worker threads to execute the "computing function + sending function" call operations on the two batches respectively. Figure 4 As shown in the figure, there is a serious imbalance in the processing time of the two batches. For example, the total processing time of the "computing function + sending function" call executed by the first worker thread is shorter than the "computing function" call executed by the second worker thread. This will lead to a waste of worker thread resources and increase the latency of the middle-tier application. In this way, the developers of the middle-tier application based on Figure 4 The performance indicators of the middle-tier application shown in the figure indicate that there is an application logic design anomaly in the middle-tier application, and this anomaly is caused by the uneven distribution of tasks between the two batches. Therefore, the anomaly can be fixed by modifying the corresponding code logic.

[0073] It should be understood that, based on actual needs, the performance indicator parameter display interface may also display the running time of other threads (e.g., downstream-io thread), scheduling delay time, execution time of various functions (e.g., do_rpc function, tcp_sendmsg function, and tcp_recvmsg function), etc. This disclosure does not specifically limit this.

[0074] The above technical solution allows users to directly observe the middle-tier application's request processing process and quickly identify any anomalies such as abnormally increased thread scheduling delays or slow downstream responses during the middle-tier application's request processing.

[0075] The following describes a specific implementation method for detecting the performance of the intermediate layer application based on the performance indicator parameters and the preset abnormal conditions of each type of abnormality.

[0076] It should be understood that the amount of performance indicator parameters corresponding to each request is very large, resulting in a significant workload when testing the performance of the middle-tier application based on a large number of performance indicator parameters. To reduce the workload of testing the performance of the middle-tier application, in one possible embodiment, target performance indicator parameters are determined based on the performance indicator parameters, where the number of target performance indicator parameters is smaller than the number of performance indicator parameters. Subsequently, the performance of the middle-tier application is tested based on the target performance indicator parameters and the preset abnormal conditions for each type of abnormality. The target performance indicator parameters refer to performance indicator parameters that are closely related to the performance of the middle-tier application.

[0077] In one possible approach of this embodiment, the performance indicator parameters are performance indicator parameters of the mid-layer application obtained from user space and kernel space, and the performance indicator parameters include: execution time information of each function, scheduling time information of each thread, and offline time information of each thread. The performance indicator parameters of the mid-layer application can be obtained using the above approach.

[0078] Accordingly, the target performance indicator parameters include at least one of the following: execution time information of the target function, the time interval between the user space and the kernel space, the RPC time used to characterize the time it takes for the middle-layer application to send a request to the downstream server and receive feedback data returned by the downstream server, the scheduling delay time of the thread, the offline time of the thread, the request time used to characterize the time it takes for the middle-layer application to interact with the downstream server, and the sending time used to characterize the time it takes for the middle-layer application to send a request to the downstream server.

[0079] For example, target performance indicator parameters may include:

[0080] (1) Execution time information of the target function. The target function is any one or more functions in the execution time information of the first type of function running in the user space and the second type of function running in the kernel space described above. For example, the target function can be a computing function and a sending function, and the execution time information can be the running start time and running time of the computing function and the sending function. In this way, the execution time information of the target function can be expressed as<FuncName:start_time,duration> ,FuncName=computing / sending.

[0081] (2) The time interval between user space and kernel space. The time interval between user space and kernel space is the execution time difference between the do_rpc function and the corresponding tcp_sendmsg function, that is, for each sub-request, the execution start time difference between the do_rpc function and the tcp_sendmsg function corresponding to the sub-request. This time interval is used to characterize the time delay caused by the interaction between different software layers (interaction between user space and kernel space) to the request sending. The time interval between user space and kernel space can be expressed as<Gap:avg,max> avg and max represent the average and maximum values ​​of the N time intervals gaps corresponding to the N sub-requests of a request, where each sub-request corresponds to a time interval gap.

[0082] (3) RPC time. RPC time is used to characterize the time it takes for the middle-tier application to send a request to the downstream server and receive the feedback data returned by the downstream server. It can be expressed as<RPCLatency:avg,max> RPCLatency represents the time it takes for the middle-tier application to send a request to the downstream server and receive feedback from it. This is the difference between the execution time of the tcp_sendmsg function and the corresponding tcp_recvmsg function. Similarly, avg and max represent the average and maximum RPCLatency values ​​for the N RPCs corresponding to the N subrequests in a request.

[0083] (4) Thread scheduling delay time. The thread scheduling delay time can be expressed as<schedDelay:avg,max> schedDelay represents the thread's scheduling delay, which is the difference between the start time (run) and the start time (sched). Calculate the scheduling delay (schedDelay) for each thread in the thread list. Then, calculate the average (avg) and maximum (max) of the scheduling delays.

[0084] It should be understood that since the scheduling delay time of the worker thread has a weak impact on the performance of the middle-tier application, it is possible to only obtain the scheduling delay time of the downstream-io thread. In this way, the workload can be reduced as much as possible while ensuring a large range of detectable anomalies, further improving the detection efficiency of the performance of the middle-tier application.

[0085] (5) Thread offline time. The thread offline time can be expressed as<offCPU:avg,max> Similarly, calculate the off-CPU time for each thread in the thread group during each scheduling. Then, calculate the average avg and maximum max of the off-CPU time. Similarly, you can also obtain the off-CPU time for only the downstream-io thread.

[0086] (6) Request duration is used to characterize the time it takes for the middle-tier application to interact with the downstream server. Request duration can be expressed as <request:duration>The request duration is the difference between the start time of the tcp_sendmsg function for the first subrequest in a send request and the start time of the tcp_recvmsg function for the last subrequest in the request. The request duration is used to detect abnormalities in the total interaction time between the middle-tier application and the downstream server.

[0087] (7) Sending time is used to characterize the time it takes for the middle-tier application to send a request to the downstream server. Sending time can be expressed as <send:duration>The send duration is the difference between the execution start time of the tcp_sendmsg call for the first subrequest in a request and the execution start time of the tcp_sendmsg call for the last subrequest in the request. The send duration is used to detect whether the middle-tier application experiences any time anomalies when sending N subrequests to the downstream server.

[0088] It should be understood that different target performance indicator parameters can be set according to actual needs, and this disclosure does not make specific limitations on this.

[0089] In addition, in the present disclosure, the exception category may include at least one of a send timeout exception, a layer interval timeout exception, a thread scheduling timeout exception, a thread offline time exception, and a downstream server feedback timeout exception. Among them, the exception condition corresponding to the send timeout exception is that the ratio of the send duration to the request duration is greater than or equal to the first preset value, for example, send.duration / request.duration is greater than or equal to T1. The exception condition corresponding to the layer interval timeout exception is that the time interval between the user space and the kernel space is greater than or equal to the second preset value, for example, Gap.max is greater than or equal to T2. The exception condition corresponding to the thread scheduling timeout exception is that the thread scheduling delay time is greater than or equal to the third preset value, for example, schedDelay.max is greater than or equal to T3. The exception condition corresponding to the thread offline time exception is that the thread offline time is greater than or equal to the fourth preset value, for example, offCPU.max is greater than or equal to T4. The exception condition corresponding to the downstream server feedback timeout exception is that the ratio of the maximum RPC duration to the average RPC duration is greater than or equal to the fifth preset value, for example, RPCLatency.max / RPClatency.avg is greater than or equal to T5. Table 1 shows an exception category and the corresponding exception conditions for each category. In Table 1, the first preset value T1, the second preset value T2, the third preset value T3, the fourth preset value T4, and the fifth preset value T5 are set by the user based on the characteristics of the middle-layer application to be detected and the operating environment, and this disclosure does not specifically limit this.

[0090] Table 1

[0091] Exception Category Abnormal conditions Sending timeout exception send.duration / request.duration≥T1 Layer interval timeout exception Gap.max≥T2 Thread scheduling timeout exception schedDelay.max ≥ T3 Abnormal thread offline time offCPU.max≥T4 Downstream server feedback timeout exception RPCLatency.max / RPCLatency.avg≥T5

[0092] It should be understood that in actual applications, users can also add exception categories specific to the middle-layer application to be detected and exception conditions corresponding to the exceptions of this category based on the characteristics of the middle-layer application to be detected, so as to increase the understanding of the performance of the middle-layer application to be detected. In addition, the exception conditions corresponding to each category of exception can also be set according to actual needs, and this disclosure does not make specific limitations on this.

[0093] In addition, when the acquired performance indicator parameters are performance indicator parameters corresponding to each request processed by the middle-layer application within a preset time period, the specific implementation method of detecting the performance of the middle-layer application based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality may also be:

[0094] For each request, determine the type of exception that occurs when the middle-layer application processes the request based on the performance indicator parameters corresponding to the request and the preset exception conditions corresponding to each type of exception;

[0095] According to the exception type existing in the process of processing each request by the middle-layer application, the probability of each type of exception occurring in the process of processing the request by the middle-layer application is determined.

[0096] For example, assuming that the preset exception categories and the exception conditions corresponding to each category of exceptions are shown in Table 1, the probability of the category exception occurring in the process of the middle-layer application processing the request determined in the above manner is shown in Table 2, and Table 2 also shows the performance loss of the middle-layer application caused by each type of exception.

[0097] Table 2

[0098] Exception Category Probability of occurrence Performance loss Send timeout exception 87.6％ 41.8％ Layer interval timeout exception 1.6％ 15.2％ Thread scheduling timeout exception 1.3％ 13.6％ Abnormal thread offline time 0.3％ 22.0％ Downstream server feedback timeout exception 17.0％ 13.6％

[0099] The performance test results shown in Table 2 show that send timeouts and downstream server feedback timeouts are the most severe anomalies in the middle-tier applications being tested. Specifically, 87.6% of requests encountered send timeouts, resulting in a 41.8% performance loss. 17% of requests also encountered downstream server feedback timeouts, resulting in a 13.6% performance loss. Therefore, users can optimize the middle-tier applications for these two types of anomalies. For example, optimizing for send timeouts with "parallelization" reduced average latency by 40.8%. Optimizing for downstream server feedback timeouts with "reordering" reduced latency by more than 5% in over 37.5% of requests.

[0100] Based on the same concept, the present disclosure provides a performance detection device for a middle-layer application. Figure 5 FIG. 1 is a block diagram of a performance detection device for an intermediate layer application according to an embodiment of the present disclosure. Figure 5 As shown, the performance detection device 500 for the middle-layer application may include:

[0101] A receiving module 501 is configured to receive a performance detection instruction for instructing to detect the performance of the middle-layer application;

[0102] an acquisition module 502 for acquiring performance indicator parameters of the middle-tier application when the middle-tier application is in a running state, wherein the middle-tier application, when in a running state, is capable of processing requests sent by an upstream server and sending them to a downstream server and receiving results returned by the downstream server;

[0103] The detection module 503 is configured to detect the performance of the middle layer application according to the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality.

[0104] Optionally, the detection module 503 includes:

[0105] The first determination submodule is used to determine whether there are parameters in the performance indicator parameters that meet the abnormal conditions corresponding to each type of abnormality. If there are parameters that meet the abnormal conditions corresponding to the type of abnormality, it is determined that the middle layer application has this type of abnormality.

[0106] Optionally, the acquisition module 502 includes:

[0107] A first acquisition submodule is configured to acquire, when the middle-layer application is in a running state, a performance indicator parameter corresponding to each request processed by the middle-layer application within a preset time period;

[0108] Accordingly, the detection module 503 includes:

[0109] A second determination submodule is configured to determine, for each request, the type of exception that occurs when the intermediate layer application processes the request based on the performance indicator parameters corresponding to the request and the preset exception conditions corresponding to each type of exception;

[0110] The third determining submodule is configured to determine, based on the type of exception that occurs in the process of the intermediate layer application processing each request, the probability of each type of exception occurring in the process of the intermediate layer application processing the request.

[0111] Optionally, the acquisition module 502 includes:

[0112] The second acquisition submodule is configured to acquire the performance indicator parameters of the middle-layer application from the user space and the kernel space when the middle-layer application is in a running state.

[0113] Optionally, the acquisition module 502 includes:

[0114] a third acquisition submodule, configured to, when the middle-layer application is in a running state, use a first tracing technology to acquire execution time information of first-class functions running in user space, and a request identifier corresponding to each execution of each first-class function, so as to obtain execution time information of the first-class function corresponding to each request;

[0115] a fourth acquisition submodule, configured to use a second tracing technique to acquire execution time information of second-class functions running in kernel space, and a request identifier corresponding to each execution of each second-class function, to obtain execution time information of the second-class function corresponding to each request, wherein the second-class functions include a scheduling function for scheduling threads and a transceiver function for sending and receiving requests;

[0116] a fourth determining submodule, configured to determine, based on the execution time information of the scheduling function corresponding to each request, the scheduling information of the thread executing the first type of function and the thread executing the sending and receiving function, so as to obtain the scheduling time information of the thread corresponding to each request;

[0117] The fifth acquisition submodule is configured to acquire the start time and end time of each request, and determine the offline time information of the thread corresponding to each request based on the start time, the end time and the scheduling time information of the thread.

[0118] Optionally, the detection module 503 includes:

[0119] a fifth determining submodule, configured to determine target performance indicator parameters according to the performance indicator parameters, wherein the number of the target performance indicator parameters is less than the number of the performance indicator parameters;

[0120] The detection submodule is used to detect the performance of the middle layer application according to the target performance indicator parameters and the preset abnormal conditions of each type of abnormality.

[0121] Optionally, the performance indicator parameters are performance indicator parameters of the intermediate layer application obtained from the user space and the kernel space, and the performance indicator parameters include: execution time information of each function, scheduling time information of each thread, and offline time information of each thread;

[0122] The target performance indicator parameters include at least one of the following: execution time information of the target function, the time interval between the user space and the kernel space, the RPC time used to characterize the time it takes for the middle-layer application to send a request to the downstream server and receive data returned by the downstream server, the scheduling delay time of the thread, the offline time of the thread, the request time used to characterize the time it takes for the middle-layer application to interact with the downstream server, and the sending time used to characterize the time it takes for the middle-layer application to send a request to the downstream server.

[0123] Optionally, the exception category includes at least one of a sending timeout exception, a layer interval timeout exception, a thread scheduling timeout exception, a thread offline time exception, and a downstream server feedback timeout exception;

[0124] The abnormal condition corresponding to the sending timeout exception is that the ratio of the sending time to the request time is greater than or equal to a first preset value;

[0125] The abnormal condition corresponding to the layer interval timeout exception is that the time interval between the user space and the kernel space is greater than or equal to a second preset value;

[0126] The abnormal condition corresponding to the thread scheduling timeout exception is that the thread scheduling delay time is greater than or equal to a third preset value;

[0127] The abnormal condition corresponding to the thread offline time abnormality is that the thread offline time is greater than or equal to a fourth preset value;

[0128] The abnormal condition corresponding to the downstream server feedback timeout exception is that the ratio of the maximum RPC time consumption to the average RPC time consumption is greater than or equal to the fifth preset value.

[0129] Optionally, the device further comprises:

[0130] The display module is used to display the performance indicator parameters of the middle layer application.

[0131] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0132] Based on the same concept, an embodiment of the present disclosure further provides an electronic device, including:

[0133] a storage device having at least one computer program stored thereon;

[0134] At least one processing device is used to execute the at least one computer program in the storage device to implement the steps of any of the above-mentioned performance detection methods for intermediate layer applications.

[0135] Reference below Figure 6 , which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0136] like Figure 6 As shown, the electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0137] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6 The electronic device 600 is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0138] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 609, or installed from the storage device 608, or installed from the ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are performed.

[0139] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or component. In the present disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0140] In some embodiments, the server can communicate using any currently known or later developed network protocol, such as HTTP (HyperText Transfer Protocol), and can be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or later developed network.

[0141] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0142] The above-mentioned computer-readable medium carries one or more programs. When the above-mentioned one or more programs are executed by the electronic device, the electronic device: receives a performance detection instruction for instructing to detect the performance of the middle-layer application; when the middle-layer application is in a running state, obtains the performance indicator parameters of the middle-layer application, wherein, when the middle-layer application is in a running state, it can process the request sent by the upstream server and send it to the downstream server and receive the result returned by the downstream server; detects the performance of the middle-layer application according to the performance indicator parameters and the abnormal conditions corresponding to each preset type of abnormality.

[0143] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages, or a combination thereof, including, but not limited to, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0145] The modules described in the embodiments of the present disclosure may be implemented in software or hardware, wherein the name of a module does not necessarily limit the module itself.

[0146] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0147] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0148] According to one or more embodiments of the present disclosure, Example 1 provides a performance detection method for a middle-layer application, including: receiving a performance detection instruction for instructing to detect the performance of the middle-layer application; when the middle-layer application is in a running state, obtaining performance indicator parameters of the middle-layer application, wherein, when the middle-layer application is in a running state, it is capable of processing requests sent by an upstream server and sending them to a downstream server and receiving results returned by the downstream server; and detecting the performance of the middle-layer application according to the performance indicator parameters and the abnormal conditions corresponding to each preset type of abnormality.

[0149] According to one or more embodiments of the present disclosure, Example 2 provides the method of Example 1, which detects the performance of the middle-layer application based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality, including: for each type of abnormality, determining whether there are parameters in the performance indicator parameters that meet the abnormal conditions corresponding to this type of abnormality; if there are parameters that meet the abnormal conditions corresponding to this type of abnormality, it is determined that this type of abnormality exists in the middle-layer application.

[0150] According to one or more embodiments of the present disclosure, Example 3 provides the method of Example 1, wherein when the middle-layer application is in a running state, obtaining the performance indicator parameters of the middle-layer application includes: when the middle-layer application is in a running state, obtaining the performance indicator parameters corresponding to each request processed by the middle-layer application within a preset time period; accordingly, detecting the performance of the middle-layer application based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality, including: for each request, determining the type of abnormality existing in the process of the middle-layer application processing the request based on the performance indicator parameters corresponding to the request and the preset abnormal conditions corresponding to each type of abnormality; determining the probability of each type of abnormality occurring in the process of the middle-layer application processing the request based on the type of abnormality existing in the process of the middle-layer application processing each request.

[0151] According to one or more embodiments of the present disclosure, Example 4 provides the method of Example 1, wherein when the middle-layer application is in a running state, obtaining the performance indicator parameters of the middle-layer application includes: when the middle-layer application is in a running state, obtaining the performance indicator parameters of the middle-layer application from the user space and the kernel space.

[0152] According to one or more embodiments of the present disclosure, Example 5 provides the method of Example 1, which obtains the performance indicator parameters of the middle-layer application when the middle-layer application is in a running state, including: when the middle-layer application is in a running state, using a first tracing technology to obtain the execution time information of the first-class function running in the user space, and the request identifier corresponding to each execution of each first-class function, so as to obtain the execution time information of the first-class function corresponding to each request; using a second tracing technology to obtain the execution time information of the second-class function running in the kernel space, and the request identifier corresponding to each execution of each second-class function, so as to obtain the execution time information of the second-class function corresponding to each request, the second-class function includes a scheduling function for scheduling threads and a transceiver function for sending and receiving requests; according to the execution time information of the scheduling function corresponding to each request, determining the scheduling information of the thread executing the first-class function and the transceiver function, so as to obtain the scheduling time information of the thread corresponding to each request; obtaining the start time and end time of each request, and determining the offline time information of the thread corresponding to each request based on the start time, the end time and the scheduling time information of the thread.

[0153] According to one or more embodiments of the present disclosure, Example 6 provides a method of any one of Examples 1-5, wherein the performance of the middle-layer application is detected based on the performance indicator parameters and the preset abnormal conditions of each type of abnormality, including: determining target performance indicator parameters based on the performance indicator parameters, the number of the target performance indicator parameters is less than the number of the performance indicator parameters; and detecting the performance of the middle-layer application based on the target performance indicator parameters and the preset abnormal conditions of each type of abnormality.

[0154] According to one or more embodiments of the present disclosure, Example 7 provides the method of Example 6, wherein the performance indicator parameters are performance indicator parameters of the middle-layer application obtained from the user space and the kernel space, and the performance indicator parameters include: execution time information of each function, scheduling time information of each thread, and offline time information of each thread; the target performance indicator parameters include at least one of the following: execution time information of the target function, the time interval between the user space and the kernel space, the RPC time used to characterize the time it takes for the middle-layer application to send a request to the downstream server and receive data returned by the downstream server, the scheduling delay time of the thread, the offline time of the thread, the request time used to characterize the time it takes for the middle-layer application to interact with the downstream server, and the sending time used to characterize the time it takes for the middle-layer application to send a request to the downstream server.

[0155] According to one or more embodiments of the present disclosure, Example 8 provides the method of Example 7, and the exception categories include at least one of a sending timeout exception, a layer interval timeout exception, a thread scheduling timeout exception, a thread offline time exception, and a downstream server feedback timeout exception; wherein, the exception condition corresponding to the sending timeout exception is that the ratio of the sending time to the request time is greater than or equal to a first preset value; the exception condition corresponding to the layer interval timeout exception is that the time interval between the user space and the kernel space is greater than or equal to a second preset value; the exception condition corresponding to the thread scheduling timeout exception is that the thread scheduling delay time is greater than or equal to a third preset value; the exception condition corresponding to the thread offline time exception is that the thread offline time is greater than or equal to a fourth preset value; the exception condition corresponding to the downstream server feedback timeout exception is that the ratio of the maximum RPC time to the average RPC time is greater than or equal to a fifth preset value.

[0156] According to one or more embodiments of the present disclosure, Example 9 provides the method of any one of Examples 1-5, wherein the method further includes: displaying performance indicator parameters of the middle-layer application.

[0157] According to one or more embodiments of the present disclosure, Example 10 provides a performance detection device for a middle-layer application, comprising: a receiving module for receiving a performance detection instruction for instructing to detect the performance of the middle-layer application; an acquisition module for obtaining performance indicator parameters of the middle-layer application when the middle-layer application is in a running state, wherein the middle-layer application is capable of processing requests sent by an upstream server and sending them to a downstream server and receiving results returned by the downstream server when the middle-layer application is in a running state; a detection module for detecting the performance of the middle-layer application based on the performance indicator parameters and the abnormal conditions corresponding to each preset type of abnormality.

[0158] According to one or more embodiments of the present disclosure, Example 11 provides the device of Example 10, and the detection module includes: a first determination submodule, which is used to determine, for each type of abnormality, whether there are parameters in the performance indicator parameters that meet the abnormal conditions corresponding to the type of abnormality; if there are parameters that meet the abnormal conditions corresponding to the type of abnormality, it is determined that the middle-layer application has this type of abnormality.

[0159] According to one or more embodiments of the present disclosure, Example 12 provides the device of Example 10, wherein the acquisition module includes: a first acquisition sub-module, for acquiring, when the middle-layer application is in a running state, performance indicator parameters corresponding to each request processed by the middle-layer application within a preset time period; accordingly, the detection module includes: a second determination sub-module, for determining, for each request, the type of exception existing in the process of the middle-layer application processing the request according to the performance indicator parameters corresponding to the request and the preset exception conditions corresponding to each type of exception; a third determination sub-module, for determining, based on the type of exception existing in the process of the middle-layer application processing each request, the probability of each type of exception occurring in the process of the middle-layer application processing the request.

[0160] According to one or more embodiments of the present disclosure, Example 13 provides the apparatus of Example 10, wherein the acquisition module includes: a second acquisition submodule, configured to acquire performance indicator parameters of the middle-layer application from user space and kernel space when the middle-layer application is in a running state.

[0161] According to one or more embodiments of the present disclosure, Example 14 provides the apparatus of Example 10, wherein the acquisition module includes: a third acquisition submodule, for, when the intermediate layer application is in a running state, using a first tracing technology to acquire execution time information of a first type of function running in a user space, and a request identifier corresponding to each execution of each first type of function, so as to obtain execution time information of the first type of function corresponding to each request; a fourth acquisition submodule, for, using a second tracing technology to acquire execution time information of a second type of function running in a kernel space, and a request identifier corresponding to each execution of each second type of function, so as to obtain execution time information of the second type of function corresponding to each request, wherein the second type of function includes a scheduling function for scheduling threads and a transceiver function for sending and receiving requests; a fourth determination submodule, for, based on the execution time information of the scheduling function corresponding to each request, determining scheduling information of threads executing the first type of function and executing the transceiver function, so as to obtain scheduling time information of threads corresponding to each request; a fifth acquisition submodule, for acquiring the start time and end time of each request, and determining offline time information of the thread corresponding to each request based on the start time, the end time and the scheduling time information of the thread.

[0162] According to one or more embodiments of the present disclosure, Example 15 provides an apparatus of any one of Examples 10-14, wherein the detection module includes: a fifth determination submodule, for determining target performance indicator parameters based on the performance indicator parameters, the number of the target performance indicator parameters being less than the number of the performance indicator parameters; a detection submodule, for detecting the performance of the intermediate layer application based on the target performance indicator parameters and the preset abnormal conditions of each type of abnormality.

[0163] According to one or more embodiments of the present disclosure, Example 16 provides the device of Example 15, wherein the performance indicator parameters are performance indicator parameters of the middle-layer application obtained from the user space and the kernel space, and the performance indicator parameters include: execution time information of each function, scheduling time information of each thread, and offline time information of each thread; the target performance indicator parameters include at least one of the following: execution time information of the target function, the time interval between the user space and the kernel space, the RPC time used to characterize the time taken by the middle-layer application from sending a request to the downstream server to receiving data returned by the downstream server, the scheduling delay time of the thread, the offline time of the thread, the request time used to characterize the time taken by the middle-layer application to interact with the downstream server, and the sending time used to characterize the time taken by the middle-layer application to send a request to the downstream server.

[0164] According to one or more embodiments of the present disclosure, Example 17 provides the device of Example 16, and the exception categories include at least one of a sending timeout exception, a layer interval timeout exception, a thread scheduling timeout exception, a thread offline time exception, and a downstream server feedback timeout exception; wherein, the exception condition corresponding to the sending timeout exception is that the ratio of the sending time to the request time is greater than or equal to a first preset value; the exception condition corresponding to the layer interval timeout exception is that the time interval between the user space and the kernel space is greater than or equal to a second preset value; the exception condition corresponding to the thread scheduling timeout exception is that the thread scheduling delay time is greater than or equal to a third preset value; the exception condition corresponding to the thread offline time exception is that the thread offline time is greater than or equal to a fourth preset value; the exception condition corresponding to the downstream server feedback timeout exception is that the ratio of the maximum RPC time to the average RPC time is greater than or equal to a fifth preset value.

[0165] According to one or more embodiments of the present disclosure, Example 18 provides the apparatus of any one of Examples 10-14, wherein the apparatus further includes: a display module configured to display performance indicator parameters of the intermediate layer application.

[0166] According to one or more embodiments of the present disclosure, Example 19 provides a computer-readable medium having a computer program stored thereon, which implements the steps of the method described in any one of Examples 1 to 9 when executed by a processing device.

[0167] According to one or more embodiments of the present disclosure, Example 20 provides an electronic device, comprising: a storage device on which at least one computer program is stored; and at least one processing device for executing the at least one computer program in the storage device to implement the steps of the method described in any one of Examples 1 to 9.

[0168] The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also includes other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this disclosure.

[0169] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details have been included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0170] Although the subject matter has been described using language specific to structural features and / or methodological logical acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are merely example forms of implementing the claims. Regarding the apparatus in the above-described embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method and will not be elaborated upon here.< / send:duration> < / request:duration>

Claims

1. A performance testing method for a middle-layer application, characterized in that: include: receiving a performance detection instruction for instructing to detect the performance of the middle-layer application; When the middle-tier application is in a running state, obtaining performance indicator parameters of the middle-tier application, wherein when the middle-tier application is in a running state, it is capable of processing a request sent by an upstream server and sending it to a downstream server and receiving a result returned by the downstream server; The performance of the middle-layer application is detected based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality. For each type of abnormality, it is determined whether there are parameters in the performance indicator parameters that meet the abnormal conditions corresponding to this type of abnormality. If there are parameters that meet the abnormal conditions corresponding to this type of abnormality, it is determined that this type of abnormality exists in the middle-layer application.

2. The method according to claim 1, characterized in that When the middle-layer application is in the running state, obtaining the performance indicator parameters of the middle-layer application includes: When the middle layer application is in a running state, obtaining a performance indicator parameter corresponding to each request processed by the middle layer application within a preset time period; Accordingly, the detecting of the performance of the middle layer application according to the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality includes: For each request, determining the type of exception that occurs when the middle layer application processes the request based on the performance indicator parameters corresponding to the request and the preset exception conditions corresponding to each type of exception; According to the exception type existing in the process of the middle-layer application processing each request, the probability of each type of exception occurring in the process of the middle-layer application processing the request is determined.

3. The method according to claim 1, characterized in that When the middle-layer application is in the running state, obtaining the performance indicator parameters of the middle-layer application includes: When the middle layer application is in a running state, performance indicator parameters of the middle layer application are obtained from the user space and the kernel space.

4. The method according to claim 1, wherein When the middle-layer application is in the running state, obtaining the performance indicator parameters of the middle-layer application includes: When the middle-layer application is in a running state, using a first tracing technology to obtain execution time information of first-class functions running in user space and a request identifier corresponding to each execution of each first-class function, so as to obtain execution time information of the first-class function corresponding to each request; Using a second tracing technology to obtain execution time information of second-class functions running in kernel space, and a request identifier corresponding to each execution of each second-class function, to obtain execution time information of the second-class function corresponding to each request, wherein the second-class functions include a scheduling function for scheduling threads and a transceiver function for sending and receiving requests; Determining, based on the execution time information of the scheduling function corresponding to each request, the scheduling information of the thread executing the first type of function and the thread executing the sending and receiving function, so as to obtain the scheduling time information of the thread corresponding to each request; The start time and end time of each request are obtained, and the offline time information of the thread corresponding to each request is determined according to the start time, the end time and the scheduling time information of the thread.

5. The method according to any one of claims 1 to 4, characterized in that The detecting the performance of the intermediate layer application according to the performance indicator parameters and the preset abnormal conditions of each type of abnormality includes: determining target performance indicator parameters according to the performance indicator parameters, wherein the number of the target performance indicator parameters is less than the number of the performance indicator parameters; The performance of the middle layer application is detected according to the target performance indicator parameters and the preset abnormal conditions of each type of abnormality.

6. The method according to claim 5, characterized in that The performance indicator parameters are performance indicator parameters of the middle layer application obtained from the user space and the kernel space, and the performance indicator parameters include: execution time information of each function, scheduling time information of each thread, and offline time information of each thread; The target performance indicator parameters include at least one of the following: execution time information of the target function, the time interval between the user space and the kernel space, the RPC time used to characterize the time it takes for the middle-layer application to send a request to the downstream server and receive data returned by the downstream server, the scheduling delay time of the thread, the offline time of the thread, the request time used to characterize the time it takes for the middle-layer application to interact with the downstream server, and the sending time used to characterize the time it takes for the middle-layer application to send a request to the downstream server.

7. The method according to claim 6, characterized in that The exception category includes at least one of a sending timeout exception, a layer interval timeout exception, a thread scheduling timeout exception, a thread offline time exception, and a downstream server feedback timeout exception; The abnormal condition corresponding to the sending timeout exception is that the ratio of the sending time to the request time is greater than or equal to a first preset value; The abnormal condition corresponding to the layer interval timeout exception is that the time interval between the user space and the kernel space is greater than or equal to a second preset value; The abnormal condition corresponding to the thread scheduling timeout exception is that the thread scheduling delay time is greater than or equal to a third preset value; The abnormal condition corresponding to the thread offline time abnormality is that the thread offline time is greater than or equal to a fourth preset value; The abnormal condition corresponding to the downstream server feedback timeout exception is that the ratio of the maximum RPC time consumption to the average RPC time consumption is greater than or equal to the fifth preset value.

8. The method according to any one of claims 1 to 4, characterized in that The method further comprises: Displays the performance indicator parameters of the middle-tier application.

9. A performance detection device for an intermediate layer application, characterized in that: include: A receiving module, configured to receive a performance detection instruction for instructing to detect the performance of the middle-layer application; an acquisition module, configured to acquire performance indicator parameters of the middle-tier application when the middle-tier application is in a running state, wherein the middle-tier application, when in a running state, is capable of processing requests sent by an upstream server and sending them to a downstream server, and receiving results returned by the downstream server; The detection module is used to detect the performance of the middle-layer application based on the performance indicator parameters and the preset abnormal conditions corresponding to each type of abnormality, wherein, for each type of abnormality, it is determined whether there are parameters in the performance indicator parameters that meet the abnormal conditions corresponding to this type of abnormality; if there are parameters that meet the abnormal conditions corresponding to this type of abnormality, it is determined that this type of abnormality exists in the middle-layer application.

10. A computer-readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processing device, the steps of the method according to any one of claims 1 to 8 are implemented.

11. An electronic device, characterized in that: include: a storage device having at least one computer program stored thereon; At least one processing device, configured to execute the at least one computer program in the storage device to implement the steps of the method according to any one of claims 1 to 8.

Images