Performance monitoring method and device for synchronously collecting multiple performance indexes, equipment and medium

Abstract

The invention discloses a performance monitoring method and device for synchronous acquisition of multiple performance indexes, equipment and a medium, and relates to the technical field of computers, and the method comprises the steps: determining a periodic sampling time window based on a preset basic sampling period; when each sampling time window starts, triggering synchronous acquisition of a plurality of performance indexes of the target object; associating a plurality of performance indexes collected in the same sampling time window based on a unified time identifier corresponding to the sampling time window so as to combine into a time-aligned performance snapshot; and storing the performance snapshot in a preset cache structure. According to the scheme, the problem that the accuracy of root cause positioning is affected due to data time sequence disorder caused by asynchronous acquisition of performance indexes in the prior art is solved, so that different performance indexes have time consistency for direct comparison and correlation analysis, and the accuracy and analysis efficiency of performance anomaly root cause positioning are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer technology, and in particular to a performance monitoring method and device for synchronous collection of multiple performance indicators, equipment and a medium. BACKGROUND

[0002] At present, existing performance monitoring solutions generally rely on independent deployment of multiple monitoring modules inside an application to respectively collect different performance indicators. However, due to the independent sampling period and triggering mechanism of each monitoring module, the different indicators collected cannot be aligned in time sequence. Therefore, it is difficult to establish accurate temporal correlation between different performance indicators, thereby seriously affecting the accuracy of root cause positioning when analyzing complex performance problems such as lag and memory exceptions. SUMMARY

[0003] Embodiments of the present application provide a performance monitoring method and device for synchronous collection of multiple performance indicators, equipment and a medium to solve the problem of data time sequence disorder caused by asynchronous collection of performance indicators in the prior art, thereby affecting the accuracy of root cause positioning.

[0004] In a first aspect, a performance monitoring method for synchronous collection of multiple performance indicators is provided, and the method comprises: determining a periodic sampling time window based on a preset basic sampling period; triggering synchronous collection of multiple performance indicators of a target object at the start of each sampling time window; associating the multiple performance indicators collected in the same sampling time window based on a uniform time identifier corresponding to the sampling time window to combine a time-aligned performance snapshot; storing the performance snapshot in a preset cache structure.

[0005] In a second aspect, a performance monitoring device for synchronous collection of multiple performance indicators is provided, and the device comprises: a determination module configured to determine a periodic sampling time window based on a preset basic sampling period; a collection module configured to trigger synchronous collection of multiple performance indicators of a target object at the start of each sampling time window; a combination module configured to associate the multiple performance indicators collected in the same sampling time window based on a uniform time identifier corresponding to the sampling time window to combine a time-aligned performance snapshot; a storage module configured to store the performance snapshot in a preset cache structure.

[0006] In a third aspect, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the performance monitoring method for synchronously collecting multiple performance indicators when executing the computer program.

[0007] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program implements the steps of the performance monitoring method for synchronously collecting multiple performance indicators when executed by a processor.

[0008] The technical scheme provided by the present application has the beneficial effects that: the sampling time window shared by multiple performance indicators is determined based on the same preset basic sampling period, and the multiple performance indicators of the target object are synchronously triggered to be collected at the start of each sampling time window, so that the multiple performance indicators obtained in the same sampling time window have a unified time identifier and are associated and combined into a time-aligned performance snapshot, thereby avoiding the time deviation problem caused by inconsistent performance indicator collection times in the prior art, i.e., fundamentally solving the problem of data time sequence disorder caused by asynchronous performance indicator collection in the prior art, thereby affecting the accuracy of root cause positioning, so that different performance indicators have time consistency that can be directly compared and associated, thereby significantly improving the accuracy and analysis efficiency of performance abnormal root cause positioning. BRIEF DESCRIPTION OF DRAWINGS

[0009] In order to more clearly illustrate the technical scheme of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present application. Obviously, the drawings in the following description are only some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0010] Figure 1 is a flowchart of the performance monitoring method for synchronously collecting multiple performance indicators in an embodiment of the present application; Figure 2 is another flowchart of the performance monitoring method for synchronously collecting multiple performance indicators in an embodiment of the present application; Figure 3 is a schematic diagram of the performance monitoring device for synchronously collecting multiple performance indicators in an embodiment of the present application; Figure 4 is a schematic diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0011] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by users of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0012] like Figure 1 As shown, in one embodiment, a performance monitoring method for synchronously collecting multiple performance indicators is provided, including the following steps: S101: Determine the periodic sampling time window based on the preset basic sampling period; S102: At the beginning of each sampling time window, trigger the synchronous collection of multiple performance indicators of the target object.

[0013] As an example, the basic sampling period refers to a pre-defined, uniform, and fixed time interval, which serves as the sole time reference for monitoring all performance indicators and specifies the trigger frequency of the data acquisition action. For example, 500 milliseconds or 600 milliseconds, etc., are not limited here.

[0014] The sampling time window refers to the periodic data acquisition period defined by the basic sampling period. For example, when the basic sampling period is set to 500 milliseconds, a series of consecutive sampling time windows such as "0-500 milliseconds", "500-1000 milliseconds", and "1000-1500 milliseconds" will be generated periodically. Each window is a fixed time period for performing one complete performance data acquisition, and there is no limitation on it here.

[0015] It should be understood that the application or system process is the target object in this application, used to collect its performance metrics and monitor its running status.

[0016] In one possible approach, a base sampling period is first established as a unified time benchmark, and continuous and periodic sampling time windows are determined based on this base sampling period. At the beginning of each sampling time window, a separate background scheduling thread triggers the synchronous collection of multi-dimensional performance metrics of the target object (e.g., a mobile application), such as CPU (Central Processing Unit) utilization, memory usage, and UI rendering frame rate. The mobile application can include, but is not limited to, iOS applications, Android applications, HarmonyOS applications, and PC applications, etc., and is not limited here.

[0017] In a specific implementation, the CPU usage can be obtained by calling a system underlying API (for example, an iOS application can call a Mach kernel interface such as "host_processor_info") to obtain thread information, traversing all non-empty threads and accumulating calculation, and returning a formatted CPU usage percentage value in a thread-safe singleton mode. The memory occupancy rate can be calculated through a memory information interface (for example, an iOS application can obtain memory information through "task_info"), and can be adapted to different system versions (such as reading "phys_footprint" for iOS 13+, and reading "resident_size" for old versions), and finally returning the memory occupancy rate in MB. The interface rendering frame rate can be obtained by calculating the display link callback mechanism (for example, an iOS application can use the callback interval of "CADisplayLink"). The collection actions of all performance indicators are triggered synchronously at the beginning of the sampling time window, and the original data is collected in the sampling time window, and the data update can use atomic or lightweight locking mechanism, which effectively avoids data competition and delay in a multi-threaded environment.

[0018] As a specific example, the basic sampling period can be set to 300 milliseconds, and periodic sampling time windows can be determined accordingly (for example, the first window: 0-300 milliseconds; the second window: 300-600 milliseconds; the third window: 600-900 milliseconds; and the subsequent windows follow the same pattern). At the beginning of the first sampling time window, the CPU usage of 10%, the memory occupancy of 85MB, and the interface rendering frame rate of 60FPS are synchronously collected. At the beginning of the second sampling time window, the CPU usage of 14%, the memory occupancy of 88MB, and the interface rendering frame rate of 59FPS are synchronously collected. At the beginning of the third sampling time window, the CPU usage of 20%, the memory occupancy of 90MB, and the interface rendering frame rate of 46FPS are synchronously collected. And so on.

[0019] The effect of this embodiment is that by setting a unified time reference and defining a strictly periodic sampling time window accordingly, and then triggering the collection of all indicators synchronously at the beginning of each sampling time window, the time origin of multi-source heterogeneous performance indicators is ensured to be strictly consistent from the data collection source, and all collection tasks are executed in independent background threads, effectively avoiding additional interference to the performance of the main thread of the mobile application. This mechanism fundamentally solves the problem of data time sequence disorder and lack of correlation caused by independent and asynchronous collection of indicators in traditional solutions, making the time sequence correlation between performance events such as processor load, memory occupancy, and interface rendering frame rate clear, not only significantly improving the comparability of multi-dimensional performance data, but also providing a reliable basis for fast and accurate root cause analysis of performance bottlenecks.

[0020] S103: Based on the unified time identifier corresponding to the sampling time window, multiple performance indicators collected within the same sampling time window are associated to form a time-aligned performance snapshot.

[0021] It is understood that, in the embodiments of this application, to achieve consistent processing of multiple performance indicators across the time dimension, the system generates a unified time identifier corresponding to each sampling time window. The unified time identifier is used to characterize the position of the sampling time window in the time series and serves as the basis for associating multiple performance indicators collected within that sampling time window. When collecting performance indicators such as CPU utilization, memory usage, and UI rendering frame rate, each performance indicator obtained within the same sampling time window is associated with its corresponding unified time identifier, thereby forming a time-aligned performance data set used to characterize the running status of the mobile application within the corresponding sampling time window.

[0022] S104: Store performance snapshots in a preset cache structure.

[0023] As an example, a performance snapshot refers to a structured data unit with a strictly consistent time base, formed by binding and encapsulating multiple performance metrics (such as CPU utilization, memory usage, and UI rendering frame rate) synchronously collected within a sampling time window with a unified time identifier (e.g., a start timestamp) for that sampling time window. The preset cache structure refers to a pre-created and configured data storage area used to temporarily store the generated performance snapshots in sequence.

[0024] Understandably, in the implementation of steps S103 to S104 of this application, after the synchronous collection of all performance metrics is completed within a certain sampling time window (e.g., a window starting at 600 milliseconds and ending at 900 milliseconds), a combined step is executed: First, a unified time identifier (e.g., a start timestamp "600ms") is extracted from the sampling time window; then, the collected CPU utilization, memory usage, and UI rendering frame rate are encapsulated with this time identifier to generate a structured data object (e.g., a JSON object or structure instance containing fields such as timestamp, cpu_usage, memory_usage, and fps). This data object is a time-aligned performance snapshot, in which all metric values ​​are explicitly associated with the same point in time, ensuring the comparability and correlation of the data in terms of time sequence. Subsequently, the performance snapshot is stored in a preset cache structure in the order of its generation for subsequent querying, backtracking, or analysis.

[0025] As a specific example, after the preceding S101 and S102, the CPU usage rate of 20%, the memory occupancy rate of 90MB, and the interface rendering frame rate of 46FPS are synchronously collected in a third sampling time window starting at 600 milliseconds. The combined step S103 is performed to extract the time identifier "600ms" and bind these data values thereto, and a performance snapshot {"timestamp": 600, "cpu_usage": 20, "memory_usage": 90, "fps": 46} is generated. The analysis program or the developer can explicitly know that the indicators in the snapshot collectively describe the complete performance state of the mobile application at the 600 millisecond moment. Subsequently, the storage step is performed to sequentially store the snapshot into the cache structure to support performance trend analysis and anomaly detection.

[0026] The effect of this embodiment is that the key conversion from synchronous collection to available data is completed. That is, by forcibly binding the multiple performance indicators obtained in the same sampling time window to the same timestamp, it is ensured that the performance snapshot itself carries indisputable time consistency, effectively solving the problem that the raw data collected in steps S101 and S102 is still at the "logical association" level and cannot be transmitted, stored, and calculated as a whole. At the same time, by storing the snapshot in the preset cache structure, continuous and manageable data retention of the recent performance history is achieved, providing a reliable data basis for the closed-loop operation of the entire monitoring scheme.

[0027] In summary, the beneficial effects of one technical solution provided by the present application are: by determining a sampling time window shared by multiple performance indicators based on the same preset base sampling period, and synchronously triggering the collection of multiple performance indicators of the target object at the beginning of each sampling time window, the multiple performance indicators obtained in the same sampling time window have a unified time identifier and are associated and combined into a time-aligned performance snapshot, thereby avoiding the time deviation problem in the prior art due to inconsistent collection times of various performance indicators, i.e., fundamentally solving the problem of time sequence disorder caused by asynchronous collection of various performance indicators in the prior art, thereby affecting the accuracy of root cause positioning, so that different performance indicators have time consistency that can be directly compared and analyzed, thereby significantly improving the accuracy and analysis efficiency of performance anomaly root cause positioning.

[0028] It should be noted that the performance monitoring method provided by the present application is applicable to application programs or system processes running on various terminal devices. The terminal devices include but are not limited to mobile terminals, desktop terminals, embedded terminals, vehicle-mounted terminals, wearable devices, and the like. The present application synchronously collects and time-aligns multiple performance indicators by using a unified sampling time window, and does not depend on specific terminal forms or operating system environments, so it can be widely applied to application program performance monitoring scenarios in different terminal environments.

[0029] In one embodiment, the performance monitoring method of the present application is applied to a mobile application on a mobile terminal. By determining a sampling time window based on a preset basic sampling period during the running of the mobile application, performance indicators such as CPU usage, memory occupancy and interface rendering frame rate are synchronously collected, and time-aligned performance snapshots are formed based on a unified time identifier, thereby realizing real-time monitoring and analysis of the running state of the mobile application.

[0030] In one embodiment, as shown in Figure 1 The plurality of performance indicators include CPU usage, memory occupancy and interface rendering frame rate. The method further includes the following steps: S105: determining the running state of the target object according to the CPU usage, memory occupancy and interface rendering frame rate in the plurality of performance snapshots; wherein the running state includes a stable state and an abnormal state.

[0031] As an exemplary illustration, the running state refers to a qualitative judgment on the overall performance health of the application based on continuous performance snapshots within a period of time, by analyzing the change trend of the plurality of performance indicators and the threshold satisfaction, which can include but is not limited to the stable state and the abnormal state, etc.

[0032] The stable state refers to the running condition in which each performance indicator (such as CPU usage, memory occupancy, interface rendering frame rate, etc.) fluctuates within a preset normal threshold range and has no continuous deterioration trend. The abnormal state refers to the running condition in which one or more performance indicators continuously deviate from the normal range (such as continuous interface rendering frame rate below the threshold, continuous CPU usage or memory occupancy, etc.), indicating that the application may face or has occurred performance degradation, which needs attention or intervention.

[0033] In one implementation, by comprehensively analyzing the CPU usage, memory occupancy and interface rendering frame rate in the plurality of performance snapshots to determine the running state of the target object, the problem of false negatives or false positives caused by relying on a single indicator for judgment in traditional monitoring schemes can be effectively overcome, and the accuracy of performance problem identification and the reliability of overall judgment are improved.

[0034] In one embodiment, as shown in Figure 2 In step S105, i.e., determining the running state of the target object according to the CPU usage, memory occupancy and interface rendering frame rate in the plurality of performance snapshots, the following steps are included: S151: calculating the memory growth rate based on the memory occupancy in the continuous N performance snapshots, and calculating the frame rate fluctuation amplitude based on the interface rendering frame rate in the continuous N performance snapshots, wherein N is a positive integer greater than 1. S152: If the CPU usage in the N continuous performance snapshots is lower than the first processor threshold, the memory growth rate is lower than the preset memory growth threshold, and the frame rate fluctuation amplitude is lower than the preset stability threshold, it is determined that the running state is a stable state.

[0035] As an exemplary illustration, the memory growth rate is used to quantify the average change trend of memory occupancy in a recent time window, which is a dynamic indicator for identifying whether there is a risk of abnormal memory growth or leakage. The frame rate fluctuation amplitude is used to measure the stability of interface rendering fluency, reflecting whether there is abnormal jitter causing lag. The first processor threshold, the preset memory growth threshold, and the preset stability threshold are all predetermined decision thresholds according to the expected application performance. For example, the first processor threshold can be set to 60%, the preset memory growth threshold can be set to 1.0 MB / s, and the preset stability threshold can be set to 8 FPS standard deviation, which is only an example and does not limit the present application.

[0036] In one implementation, after obtaining N continuous time-aligned performance snapshots, the following operations are performed to determine the stable state: First, based on the N continuous performance snapshots, the memory occupancy rate is extracted to form a memory occupancy rate sequence (represented as [M1, M2, …, MN], unit: MB), and the interface rendering frame rate is extracted to form an interface rendering frame rate sequence (represented as [F1, F2, …, FN], unit: FPS). Then, the memory growth rate (unit: MB / s) is calculated by calculating the difference between the first and last values of the memory occupancy rate sequence and dividing by the corresponding total time (i.e., (MN-M1) / (total time)), or using linear regression analysis. At the same time, the frame rate fluctuation amplitude is calculated by calculating the standard deviation of the interface rendering frame rate sequence, etc., to quantify the memory change trend and rendering stability. Then, the CPU usage rate in the same group of N performance snapshots is extracted to form a CPU usage rate sequence, and a comprehensive determination is made.

[0037] That is, the following comparisons and checks are performed: comparing the calculated memory growth rate with the preset memory growth threshold (e.g., 0.5 MB / s); comparing the calculated frame rate fluctuation amplitude with the preset stability threshold (e.g., 5 FPS); and checking whether the CPU usage rate in the CPU usage rate sequence is lower than the first processor threshold (e.g., 60%). If the CPU usage rate in the CPU usage rate sequence is lower than the first processor threshold, the memory growth rate is lower than the preset memory growth threshold, and the frame rate fluctuation amplitude is lower than the preset stability threshold, it is determined that the mobile application is in a stable state in the corresponding recent N sampling time window period.

[0038] As a specific example, set N = 5, the first processor threshold value is 60%, the preset memory growth threshold value is 1.0 MB / s, and the preset stability threshold value is 8 FPS. Analyze the last 5 consecutive performance snapshots, and the key data is as follows: timestamp sequence: [1000 ms, 1500 ms, 2000 ms, 2500 ms, 3000 ms]; CPU usage sequence: [55%, 50%, 58%, 52%, 48%]; memory occupancy sequence: [150 MB, 152 MB, 153 MB, 154 MB, 151 MB]; interface rendering frame rate sequence: [58 FPS, 59 FPS, 57 FPS, 60 FPS, 58 FPS].

[0039] It is calculated that the memory growth rate is about 0.5 MB / s, and the frame rate fluctuation amplitude (standard deviation) is about 1.14 FPS. Since the CPU usage in the CPU usage sequence is lower than 60%, the memory growth rate is lower than 1.0 MB / s, and the frame rate fluctuation amplitude is lower than 8 FPS, all conditions meet the determination criteria of step S152, and it is determined that the running state of the mobile application is a stable state.

[0040] In an embodiment, as shown in FIG. 1, in step S105, that is, in determining the running state of the target object according to the CPU usage, memory occupancy, and interface rendering frame rate in the plurality of performance snapshots, the following step is further included: Figure 2 S153: If the CPU usage in the last N consecutive performance snapshots is higher than the second processor threshold value, and / or the memory growth rate is higher than the preset memory growth threshold value, and / or the frame rate fluctuation amplitude is higher than the preset stability threshold value, determine that the running state is an abnormal state. Wherein, the second processor threshold value is greater than the first processor threshold value.

[0041] As an example, the second processor threshold value is a preconfigured threshold value higher than the first processor threshold value, which is used to define an abnormally high processor load that may cause a performance risk. The abnormal state can be subdivided into subcategories such as high processor load risk, memory abnormal growth risk, and rendering stability risk according to the specific risk conditions triggered.

[0042] ​In one implementation, after the memory growth rate and frame rate fluctuation amplitude are calculated in S151, and the CPU usage sequence is obtained, further abnormal state determination and type identification logic is performed. The determination uses "and / or" logic to independently check the following three risk conditions: (condition 1) high processor load risk: check whether the CPU usage data in the last N performance snapshots is higher than the second processor threshold. (condition 2) memory abnormal growth risk: determine whether the memory growth rate calculated in S151 is higher than the preset memory growth threshold. (condition 3) rendering stability risk: determine whether the frame rate fluctuation amplitude calculated in S151 is higher than the preset stability threshold.

[0043] As long as any of the above conditions is triggered, it is determined that the mobile application is in an abnormal state in the corresponding last N sampling time window period, and the specific risk subclass can be further identified according to the specific triggered condition: (1) if only condition 1 is triggered, it is determined to be a high processor load risk. (2) if only condition 2 is triggered, it is determined to be a memory abnormal growth risk. (3) if only condition 3 is triggered, it is determined to be a rendering stability risk. (4) if multiple conditions are triggered at the same time, it is determined to be a composite risk, which can be identified comprehensively (for example, if conditions 1 and 2 are triggered at the same time, it is identified as a high processor load and memory abnormal growth composite risk. If conditions 1 and 3 are triggered at the same time, it is identified as a high processor load and rendering stability composite risk. If conditions 2 and 3 are triggered at the same time, it is identified as a memory abnormal growth and rendering stability composite risk. If conditions 1, 2, and 3 are triggered at the same time, it is identified as a high processor load, memory abnormal growth, and rendering stability composite risk).

[0044] As a specific example, assume N=5, the second processor threshold is 85%, the preset memory growth threshold is 1.0 MB / s, and the preset stability threshold is 8 FPS. Now analyze a set of 5 consecutive performance snapshots, whose key data is as follows: timestamp sequence: [4000 ms, 4500 ms, 5000 ms, 5500 ms, 6000 ms]; CPU usage sequence: [70%, 88%, 82%, 90%, 85%]; memory occupancy rate sequence: [160 MB, 165 MB, 170 MB, 175 MB, 180 MB]; interface rendering frame rate sequence: [55 FPS, 30 FPS, 28 FPS, 25 FPS, 22 FPS].

[0045] The memory growth rate is calculated to be as high as 10 MB / s, the frame rate fluctuation amplitude (standard deviation) is about 12.8 FPS, and there are values (88%, 90%, 85%) in the CPU usage rate sequence that are higher than the second processor threshold of 85%. That is: Condition 1: there is CPU usage rate > 85% → trigger. Condition 2: memory growth rate (10 MB / s) > 1.0 MB / s → trigger. Condition 3: frame rate fluctuation amplitude (12.8 FPS) > 8 FPS → trigger. Since all three conditions are triggered, it is determined that the mobile application is in an abnormal state, and it is identified as a composite risk, which can be described as "simultaneous existence of high processor load, abnormal memory growth, and rendering stability risk".

[0046] The effect of the above embodiment is that by introducing the two trend and stability quantitative indicators of memory growth rate and frame rate fluctuation amplitude, and combining them with the static threshold of processor load, a multi-dimensional and dynamic stable state determination model is constructed. This model can more sensitively capture the implicit degradation trend of performance (such as slow memory leakage and occasional rendering jitter), effectively avoid the lag and misjudgment that may be caused by relying on a single point threshold or a single indicator for determination, and further strengthen the accuracy and forward-looking of state recognition.

[0047] In an embodiment, as shown in Figure 1 After step S105, that is, after determining the running state of the target object according to the CPU usage rate, memory occupancy rate, and interface rendering frame rate in multiple performance snapshots, the following steps are included: S106: If the running state is a stable state, update the basic sampling period to a first target sampling period; S107: If the running state is an abnormal state, update the basic sampling period to a second target sampling period; Wherein, the first target sampling period is greater than the basic sampling period, and the second target sampling period is less than the basic sampling period.

[0048] As an exemplary illustration, the first target sampling period refers to a longer sampling interval than the current basic sampling period when the application is in a stable state, and its purpose is to reduce the interference of collection on performance. The second target sampling period refers to a shorter sampling interval than the current basic sampling period when the application is in an abnormal state, and its purpose is to improve the monitoring granularity.

[0049] In an implementation, the current base sampling period and preset first and second target sampling periods are maintained internally. Upon completion of the running state determination, the sampling period is updated according to the determination result: if the determination result is the stable state, the current base sampling period is updated to the first target sampling period; if the determination result is the abnormal state, the current base sampling period is updated to the second target sampling period. The updating operation will affect the timing controller for driving the sampling time window generation, so that the timing controller operates according to the new period from the next sampling time window, thereby realizing the non-disturbance switching and self-adaptive adjustment of the monitoring intensity.

[0050] As a specific example, it is assumed that the initial base sampling period is 500 milliseconds, the preset first target sampling period (for the stable state) is 800 milliseconds, and the second target sampling period (for the abnormal state) is 200 milliseconds.

[0051] Scenario one (frequency reduction): according to the performance snapshots in a recent period of time (such as the last 10 sampling time windows), it is determined that the application is in a stable state, and then S106 is executed to update the base sampling period from 500 milliseconds to 800 milliseconds. Thereafter, data collection is triggered once every 800 milliseconds, and the monitoring overhead is reduced.

[0052] Scenario two (frequency increase): after a period of time, according to a new snapshot sequence, it is determined that the application enters an abnormal state due to a continuously low frame rate, and then S107 is executed to update the base sampling period from the current 800 milliseconds to 200 milliseconds. Thereafter, data collection is triggered once every 200 milliseconds, and the detailed process of performance degradation can be captured at a higher time density.

[0053] The effect of this embodiment is that, through steps S106 and S107, the state awareness result obtained in the foregoing steps is directly fed back to the timing control layer of the monitoring system, forming a "perception-adjustment" closed loop, which can intelligently "save energy" (prolong the sampling period and reduce the overhead) in the performance stable period and "focus" (shorten the sampling period and improve the precision) in the risk occurrence period, thereby ensuring the effectiveness of monitoring while significantly optimizing the resource economy of the monitoring activity itself.

[0054] In an embodiment, the cache structure includes a circular cache structure with a fixed storage capacity; the method further includes the following steps: S108: when the fixed storage capacity of the circular cache structure reaches the maximum storage capacity, the newly stored performance snapshot is replaced with the earliest stored performance snapshot, and the newly stored performance snapshot is stored in the storage location corresponding to the replaced performance snapshot.

[0055] As an example, the circular buffer structure is a data buffer implemented by a fixed-size continuous memory space, and its logical form can be a ring with the head and tail connected. The fixed storage capacity refers to the maximum number of data entries pre-allocated for the buffer structure and cannot be dynamically expanded, for example, it can be set to store the last 100 performance snapshots, which fundamentally limits the upper limit of the memory occupation of the monitoring data.

[0056] In one implementation, a ring-shaped memory region with a fixed capacity is created as a circular buffer structure according to the configuration during initialization, and a write pointer is initialized to indicate the next writable position. When a new performance snapshot is generated, the following operations are performed: first, check the position pointed to by the current write pointer. If the position already has data (indicating that the cache is full), the new performance snapshot will replace the earliest stored performance snapshot and be stored in the replaced storage position; if the position is empty, it is directly written. Then, the write pointer is moved one position forward, and when the write pointer moves to the end of the cache region, it is automatically reset to the starting position. This mechanism ensures that the latest continuous performance snapshots from the current time are always saved in the cache, realizing the rolling recording of recent performance history and the cyclic utilization of storage space.

[0057] As a specific example, assume that the circular buffer structure is configured with a fixed storage capacity of 5 snapshots. The system generates snapshots A, B, C, D, and E in time sequence and writes them in order, at which time the cache is full and the write pointer points to position 0 (which stores the earliest snapshot A). When the 6th snapshot F is generated, it is stored in position 0, replacing the original snapshot A, and then the write pointer is moved to position 1. At this time, the data sequence saved in the cache becomes [F, B, C, D, E], i.e., the latest 5 snapshots. When snapshot G is generated, it will replace snapshot B at position 1, and so on. The developer or analysis module can read the latest 5 time-aligned snapshots from the cache at any time for trend analysis.

[0058] The effect of this embodiment is that by introducing a circular buffer structure with a fixed capacity and an automatic overwrite mechanism, efficient, stable, and self-maintaining storage management of performance snapshot data is achieved. Its core advantages include: (1) memory occupation is determined and controllable, completely eliminating the risk of memory leakage or overflow caused by continuous accumulation of monitoring data, which is crucial for resource-constrained mobile terminals; (2) automatically retains the most time-sensitive data, and the rolling overwrite mechanism ensures that the storage space is always used to save the most recent and most valuable performance history, discarding obsolete information; (3) provides high-performance data access, and the sequential writing and fixed-size memory operations make the storage overhead constant and extremely low. This step seamlessly connects with the previous data collection and snapshot generation steps, together forming a low-overhead, sustainable performance data closed-loop management system.

[0059] In one embodiment, the method further includes the following steps: S109: Render a floating component on the front-end interface of the target object; use the floating component to update the CPU usage, memory usage and interface rendering frame rate each time the latest performance snapshot is generated.

[0060] As an example, a floating component can be understood as an independent graphical user interface element that floats on top of the front-end interface of a target object (e.g., a mobile application). It employs drawing logic independent of the business interface rendering tree and remains visible above all ordinary interfaces, active windows, or interactive pages of the application. The floating component can be presented semi-transparently to reduce obstruction of the application interface and allows users to freely drag it to any position on the screen, effectively avoiding interference with normal user operation. Furthermore, the floating component can be further customized with rounded corners, shadows, borders, background gradients, and other visual effects to enhance visual recognizability and information carrying capacity. No limitations are imposed here.

[0061] In one implementation, a floating component is created and rendered on the front-end interface when the mobile application starts or upon receiving a user's command to enable monitoring. The floating component can include a first display unit for showing CPU usage, a second display unit for showing memory usage, and a third display unit for showing the interface rendering frame rate. Whenever a new performance snapshot is generated, the corresponding values ​​in the three display units are updated based on the performance metrics in the new snapshot. Subsequently, the front-end rendering engine triggers a partial redraw of the floating component, allowing users to see the latest performance metric changes within milliseconds, thus achieving real-time visualization of performance information.

[0062] As a concrete example, suppose a mobile application renders a floating component in the upper right corner of the screen immediately upon launch. This floating component is rectangular and semi-transparent, displaying three performance metric areas: "CPU: xx%", "MEM: xxxMB", and "FPS: xx". Assume it is configured to generate a performance snapshot every 500 milliseconds, and three consecutive performance snapshots are generated within a certain time period: In the first snapshot, CPU utilization is 16%, memory usage is 89MB, and the UI rendering frame rate is 60fps; in the second snapshot, CPU utilization rises to 19%, memory usage rises to 100MB, and the UI rendering frame rate drops to 52fps; in the third snapshot, CPU utilization rises to 20%, memory usage reaches 105MB, and the UI rendering frame rate drops to 37fps. Immediately after each performance snapshot is generated, the above metrics are written to the corresponding display unit of the floating component, causing the floating component to complete three visual refreshes within approximately 1.5 seconds.

[0063] The effect of this embodiment is that by rendering the floating component on the front-end interface and updating it in real time based on each generated performance snapshot, the monitoring information can be presented to the developer or tester in the first time, so that the CPU, memory and frame rate status inside the application can be quickly perceived without relying on external tools. The advantages are as follows: (1) strong real-time performance, the floating component is refreshed at the pace of the sampling time window, and can immediately reflect the performance changes; (2) low invasiveness, without modifying the business interface structure; (3) high degree of visualization, the developer can directly see the performance fluctuations in the actual running scene, which is conducive to quickly diagnosing the cause of the stall or performance degradation trend.

[0064] It should be understood that the display color of the floating component can be associated with the running state of the target object, that is, when the running state is determined to be a stable state, the floating component can be displayed in a first color (such as green); when the running state is determined to be an abnormal state, the floating component can be displayed in a second color (such as red). This design allows the developer or tester to make an instant judgment on the overall stability of the application without carefully reading the specific values, greatly improving the efficiency of state perception.

[0065] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0066] As shown in Figure 3 In one embodiment, a performance monitoring device for synchronously collecting multiple performance indicators is provided, which corresponds to the performance monitoring method for synchronously collecting multiple performance indicators in the above embodiment. The performance monitoring device for synchronously collecting multiple performance indicators includes a determination module 201, a collection module 202, a combination module 203 and a storage module 204. The functions of each module are described in detail as follows: The determination module 201 is configured to determine a periodic sampling time window based on a preset basic sampling period; The collection module 202 is configured to trigger the synchronous collection of multiple performance indicators of a target object at the beginning of each sampling time window; The combination module 203 is configured to associate the multiple performance indicators collected in the same sampling time window based on a unified time identifier corresponding to the sampling time window, so as to combine the performance snapshots in time alignment; The storage module 204 is configured to store the performance snapshots in a preset cache structure.

[0067] In one embodiment, the multiple performance indicators include CPU usage, memory occupancy and interface rendering frame rate; the device further includes: a processing module configured to determine a running state of the target object according to CPU usage, memory occupancy and interface rendering frame rate in the plurality of performance snapshots; wherein the running state comprises a stable state and an abnormal state.

[0068] In an embodiment, the processing module is further configured to: calculate a memory growth rate based on the memory occupancy in the continuous N performance snapshots, and calculate a frame rate fluctuation amplitude based on the interface rendering frame rate in the continuous N performance snapshots, wherein N is a positive integer greater than 1; if the CPU usage in the continuous N performance snapshots is lower than a first processor threshold, and the memory growth rate is lower than a preset memory growth threshold, and the frame rate fluctuation amplitude is lower than a preset stability threshold, determine that the running state is the stable state.

[0069] In an embodiment, the processing module is further configured to: if the CPU usage in the continuous N performance snapshots is higher than a second processor threshold, and / or the memory growth rate is higher than the preset memory growth threshold, and / or the frame rate fluctuation amplitude is higher than the preset stability threshold, determine that the running state is the abnormal state; wherein the second processor threshold is greater than the first processor threshold.

[0070] In an embodiment, the apparatus further comprises: a first updating module configured to, if the running state is the stable state, update the basic sampling period to a first target sampling period; a second updating module configured to, if the running state is the abnormal state, update the basic sampling period to a second target sampling period; wherein the first target sampling period is greater than the basic sampling period, and the second target sampling period is less than the basic sampling period.

[0071] In an embodiment, the cache structure comprises a circular cache structure with a fixed storage capacity; the apparatus further comprises: a covering module configured to, when the fixed storage capacity of the circular cache structure reaches a maximum storage capacity, replace a performance snapshot stored earliest with a newly stored performance snapshot, and store the newly stored performance snapshot in a storage location corresponding to the replaced performance snapshot.

[0072] In an embodiment, the apparatus further comprises: The rendering module is used to render a floating component on the front-end interface of the target object; through the floating component, the CPU usage, memory usage and interface rendering frame rate are updated and displayed each time a new performance snapshot is generated.

[0073] Specific limitations regarding the performance monitoring device for simultaneous acquisition of multiple performance indicators can be found in the limitations of the performance monitoring method for simultaneous acquisition of multiple performance indicators described above, and will not be repeated here. Each module in the aforementioned performance monitoring device for simultaneous acquisition of multiple performance indicators can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0074] In one embodiment, an electronic device is provided; in another embodiment, a computer device is provided, the internal structure of which can be as shown in the diagram. Figure 4 As shown, the computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. When the computer program is executed by the processor, it implements the steps of a performance monitoring method that synchronously acquires multiple performance indicators.

[0075] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the performance monitoring method for synchronous acquisition of multiple performance indicators in the above embodiment, such as steps S101-S109. To avoid repetition, these steps will not be described again here.

[0076] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the steps of the performance monitoring method for synchronous acquisition of multiple performance indicators described in the above embodiments, such as steps S101-S109, which will not be repeated here to avoid repetition. The computer-readable storage medium can be non-volatile or volatile.

[0077] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by a computer program instructing relevant hardware, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0078] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0079] The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, but not limit it. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features. Such modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A performance monitoring method for synchronously acquiring multiple performance indicators, characterized in that, The method includes: Based on the preset basic sampling period, the periodic sampling time window is determined; At the beginning of each sampling time window, multiple performance metrics of the target object are synchronously collected. Based on the unified time identifier corresponding to the sampling time window, the multiple performance indicators collected within the same sampling time window are associated to form a time-aligned performance snapshot. The performance snapshot is stored in a preset cache structure.

2. The method according to claim 1, characterized in that, The multiple performance metrics include CPU utilization, memory usage, and UI rendering frame rate; the method also includes: The running state of the target object is determined based on the CPU utilization, memory usage, and UI rendering frame rate in multiple performance snapshots; wherein the running state includes a stable state and an abnormal state.

3. The method according to claim 2, characterized in that, Determining the running state of the target object based on CPU utilization, memory usage, and UI rendering frame rate from multiple performance snapshots includes: The memory growth rate is calculated based on the memory usage rate in N consecutive performance snapshots, and the frame rate fluctuation is calculated based on the interface rendering frame rate in the N consecutive performance snapshots, where N is a positive integer greater than 1. If the CPU utilization rate is lower than the first processor threshold in N consecutive performance snapshots, and the memory growth rate is lower than the preset memory growth threshold, and the frame rate fluctuation is lower than the preset stability threshold, then the running state is determined to be the stable state.

4. The method according to claim 3, characterized in that, The step of determining the running state of the target object based on CPU utilization, memory usage, and UI rendering frame rate from multiple performance snapshots further includes: If the CPU utilization rate in N consecutive performance snapshots is higher than the second processor threshold, and / or the memory growth rate is higher than the preset memory growth threshold, and / or the frame rate fluctuation is higher than the preset stability threshold, the running state is determined to be the abnormal state. Wherein, the threshold of the second processor is greater than the threshold of the first processor.

5. The method according to claim 2, characterized in that, After determining the running state of the target object based on the CPU utilization, memory usage, and UI rendering frame rate from multiple performance snapshots, the process includes: If the operating state is the stable state, then the basic sampling period is updated to the first target sampling period; If the operating state is the abnormal state, then the basic sampling period is updated to the second target sampling period; Wherein, the first target sampling period is greater than the basic sampling period, and the second target sampling period is less than the basic sampling period.

6. The method according to claim 1, characterized in that, The cache structure includes a circular cache structure with a fixed storage capacity; the method further includes: When the fixed storage capacity of the circular cache structure reaches the maximum storage capacity, the newly stored performance snapshot replaces the earliest stored performance snapshot, and the newly stored performance snapshot is stored in the storage location corresponding to the replaced performance snapshot.

7. The method according to any one of claims 2-5, characterized in that, The method further includes: Render a floating component on the front-end interface of the target object; The floating component updates the CPU usage, memory usage, and UI rendering frame rate each time a new performance snapshot is generated.

8. A performance monitoring device for simultaneous acquisition of multiple performance indicators, characterized in that, The device includes: The determination module is used to determine the periodic sampling time window based on a preset basic sampling period; The acquisition module is used to trigger the synchronous acquisition of multiple performance indicators of the target object at the beginning of each sampling time window. The combination module is used to associate the multiple performance indicators collected within the same sampling time window based on the unified time identifier corresponding to the sampling time window, so as to combine them into a time-aligned performance snapshot; A storage module is used to store the performance snapshot in a preset cache structure.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the performance monitoring method for synchronous acquisition of multiple performance indicators as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the performance monitoring method for synchronous acquisition of multiple performance indicators as described in any one of claims 1-7.

Images