Prediction-based methods for analyzing the performance impact of changes in software system component content.

Abstract

This invention discloses a prediction-based method for analyzing the performance impact caused by changes in the content of software system components. The method includes: providing a software system comprising a main software component and at least one auxiliary software component; prior to the introduction of a change in the software system, collecting performance metrics related to a workload and each auxiliary software component, respectively and sequentially; calculating the correlation coefficients between the collected performance metrics related to the workload and each auxiliary software component; if the absolute value of the correlation coefficient is less than a threshold, establishing a prediction model using the collected performance metrics related to the corresponding auxiliary software component; sequentially recording the performance metrics related to the corresponding auxiliary software component; inputting the collected performance metrics related to the corresponding auxiliary software component into the prediction model to obtain predicted performance metrics for the corresponding auxiliary software component; and using the recorded performance metrics to calculate a performance difference value.

Description

Technical Field

[0001] This invention relates to a method for analyzing the performance impact caused by changes in the content of software system components, and more particularly to a prediction-based method for analyzing the performance impact caused by changes in the content of software system components. Background Technology

[0002] When a software system comprising multiple software components is deployed on computing devices such as server clusters to meet workload requirements, changes to the software system are often used to improve its performance. Typical scenarios for such changes include software upgrades or adjustments to component configuration parameters. Even if a change is applied to one software component, it may inevitably have some impact, causing a ripple effect on the performance and / or resource usage of other software components within the same application. For the software system development and operations team, a key issue is understanding the impact of changes when they are introduced into the software system.

[0003] Performance metrics in software application systems, such as memory utilization, CPU utilization, I / O throughput, response time, requests per second, and latency, can be monitored. However, the true "impact of change" is difficult to measure. This is because the dynamic and variable nature of workloads means that the workload before and after a change cannot be guaranteed to be the same, making it impossible to compare the impact of the change.

[0004] A traditional method for analyzing the performance impact caused by changes in the content of software system components, such as Figure 1As shown, a software application cloud service, consisting of four independent software components, is deployed to serve a primary workload. Data requests and / or responses exist between the software components, and these are sources of influence for related software components. The cloud service could be an Enterprise Resource Planning (ERP) system, with the primary workload originating from an external system, such as a computer mainframe in a factory, and handled by software component 1. Software component 1 handles all operational requests and responses to this external system. Each of the remaining software components supports a specific functionality and has internal data requests and responses with other software components. A performance metric collector installed on a server continuously monitors the performance metrics of all software components. In this case, these performance metrics for the primary workload are those of software component 1. If the ERP administrator wants to know how all software components are affected after upgrading software component 2, the traditional approach is to compare the actual running performance metrics with the current performance metrics and use the comparison results to examine the impact of the change. This can be used to adjust the configuration parameters of the software components or as a reference for further upgrades. This is typically achieved through benchmarking. The limitation of this approach is that, for meaningful comparisons, it is necessary to identify workload performance metrics that are nearly identical in the runtime before and after the change. Otherwise, the comparison results would be unreliable because different workload patterns often lead to different performance metrics for software components in the system. This is not easy to achieve in a production environment because workloads change dynamically. Therefore, this type of benchmark cannot accurately describe the impact of changes introduced into the system.

[0005] To provide a precise way to assess the impact of changes in order to save operating costs, this invention discloses an innovative method. Summary of the Invention

[0006] This paragraph extracts and summarizes certain features of the invention. Other features will be disclosed in subsequent paragraphs. Its purpose is to cover various modifications and similar arrangements within the spirit and scope of the claims.

[0007] According to one embodiment of the present invention, a prediction-based method for analyzing the performance impact caused by changes in the content of software system components includes the steps of: a) providing a software system deployed in a computing hardware environment, the software system including a main software component that fulfills requests from a workload, and at least one auxiliary software component that processes specific tasks of the main software component; b) prior to the introduction of a change in the software system, collecting performance metrics related to the workload and each auxiliary software component, respectively and sequentially; c) calculating the correlation coefficient between the collected performance metrics related to the workload and the performance metrics related to each auxiliary software component; d) if the absolute value of the correlation coefficient is greater than a threshold, using the collected performance metrics related to the workload... e) Establish a predictive model using the collected performance metrics for the corresponding auxiliary software component to predict the performance metrics of the corresponding auxiliary software component over a future period; f) Sequentially record the performance metrics for the corresponding auxiliary software component and the workload during an evaluation period that begins when the change to the software system is introduced; g) Input the performance metrics for the workload and the corresponding auxiliary software component collected in step b) into the predictive model to obtain the predicted performance metrics for the corresponding auxiliary software component; and g) Use the collected performance metrics for the corresponding auxiliary software component and the predicted performance metrics for the corresponding auxiliary software component to calculate a performance variance value.

[0008] According to another embodiment of the present invention, a prediction-based method for analyzing the performance impact caused by changes in the content of software system components includes the steps of: a) providing a software system deployed in a computing hardware environment, the software system including a main software component that fulfills requests from a workload, and at least one auxiliary software component that processes specific tasks of the main software component; b) prior to the introduction of a change in the software system, collecting performance metrics for the workload and each auxiliary software component, respectively and sequentially; c) calculating the correlation coefficient between the collected performance metrics for the workload and the performance metrics for each auxiliary software component; d) if the absolute value of the correlation coefficient is less than a threshold, using the multiple e) Establish a predictive model based on the collected performance metrics of the corresponding auxiliary software component to predict the performance metrics of the corresponding auxiliary software component over a future period; f) Sequentially record the performance metrics of the corresponding auxiliary software component during an evaluation period that begins when the change to the software system is introduced; g) Input the performance metrics of the corresponding auxiliary software component collected in step b) into the predictive model to obtain the predicted performance metrics of the corresponding auxiliary software component; and g) Use the multiple recorded performance metrics of the corresponding auxiliary software component and the multiple predicted performance metrics of the corresponding auxiliary software component to calculate a performance variance value.

[0009] Preferably, the change to the software system can be a software system upgrade, an adjustment of software system application configuration parameters, the installation of new auxiliary software components, or the removal of existing auxiliary software components.

[0010] Preferably, the computing hardware environment can be a workstation host or a server cluster.

[0011] Preferably, the performance metric can be the amount of memory used, the number of CPUs used, the input / output throughput, the response time, the number of requests per second, or the latency.

[0012] Preferably, this performance difference value can be the Mean Percentage Error.

[0013] Preferably, the performance metrics of the multiple collections used to build the prediction model are divided into two categories.

[0014] Preferably, the prediction model is established by a time series prediction algorithm.

[0015] Preferably, the time series forecasting algorithm is an Auto Regressive Integrated Moving Average (ARIMA) algorithm or a Seasonal Auto Regressive Integrated Moving Average (SARIMA) algorithm.

[0016] According to the present invention, the correlation between the performance metrics of the workload and the performance metrics of each software component is taken into account, and a predictive model can be established to predict the future development of a certain performance metric of a software component. By comparing the predicted performance metrics with the actual performance metrics, the impact of changes to the software component can be assessed, and the results can be used for further modifications and to save operating costs. Attached Figure Description

[0017] Figure 1 This paper illustrates a deployment framework for a software system that uses traditional methods to analyze the performance impact of changes in the content of software system components.

[0018] Figure 2 This is a flowchart of a prediction-based method used in accordance with the present invention to analyze the performance impact caused by changes in the content of software system components.

[0019] Figure 3 This is another flowchart of a prediction-based method according to the present invention for analyzing the performance impact caused by changes in the content of software system components.

[0020] Figure 4 A deployment framework for a software system is illustrated, which uses a prediction-based method according to the present invention to analyze the performance impact caused by changes in the content of software system components.

[0021] Figure 5 The table lists the calculation data and results for the correlation coefficient and performance difference value.

[0022] Figure 6 It is a graph that displays performance metrics related to the workload, collected / recorded performance metrics related to the first auxiliary software component, and predicted performance metrics of the first auxiliary software component over time.

[0023] Figure 7 It is a graph that displays performance metrics related to the workload, collected / recorded performance metrics related to the second auxiliary software component, and predicted performance metrics of the second auxiliary software component over time.

[0024] Figure 8 It displays performance metrics related to the workload, collected / recorded performance metrics related to the third auxiliary software component, and charts showing the predicted performance metrics of the third auxiliary software component over time.

[0025] Explanation of reference numerals in the attached figures: 1-First auxiliary software component; 2-Second auxiliary software component; 3-Third auxiliary software component; A-Main software component; B-Performance index collector; S01~S07-Steps; S04'~S07'-Steps. Detailed Implementation

[0026] The present invention will be described in more detail with reference to the following embodiments.

[0027] Please refer to the following first. Figure 4 The figure illustrates a deployment framework for a software system used in accordance with the prediction-based method of the present invention to analyze the performance impact caused by changes in the content of software system components. Figure 4The software system comprises a main software component A, a first auxiliary software component 1, a second auxiliary software component 2, and a third auxiliary software component 3, deployed within a computing hardware environment. The computing hardware environment refers to powerful computing hardware capable of handling complex computational requests from a workload. This environment can be, but is not limited to, workstation hosts and server clusters. It contains numerous central processing units (CPUs), a large number of dynamic random access memory (DRAM) modules (or simply memory), and limited input / output throughput. CPUs and DRAM are the resources of the workload, used by the main software component A, and can be further subdivided into the actual usage by the first auxiliary software component 1, the second auxiliary software component 2, and the third auxiliary software component 3. Input / output throughput is a comprehensive efficiency value of the computing hardware environment for input and output data. The workload may consume a significant amount of input / output throughput, which is shared by the three auxiliary software components. Similarly, response time, requests per second, and latency are metrics for responding to the workload, each contributing to the response of each auxiliary software component. In this invention, performance metrics refer to the amount of memory used, the number of CPUs used, input / output throughput, response time, requests per second, and latency, and are used to analyze the impact of "changes" on all software components. In embodiments of this invention, the latency (in seconds) of the workload and the number of CPUs used by auxiliary software components are used for explanation. Changes to the software system can be of different types. For example, it can be a software system upgrade, an adjustment of software system application configuration parameters, the installation of new auxiliary software components, or the removal of existing auxiliary software components.

[0028] exist Figure 4 In this system, main software component A is the component that interacts with workloads in external systems. The performance metrics of main software component A are equivalent to the performance metrics of the workload. Main software component A receives requests from the workload, executes corresponding program operations, and returns a response to the specific source of the workload. For example, the workload might be email requests from a company, and main software component A is an email module running on the company's server. According to this invention, the software system has a technical architecture where, in addition to main software component A, which handles workload requests, the software system also has at least one auxiliary software component that processes specific tasks performed by main software component A. Figure 4In this system, the first auxiliary software component 1 directly "works" for the main software component A, retrieving data from all emails. The second auxiliary software component 2 "works" for the first auxiliary software component 1, managing the email content database for all emails. That is, the second auxiliary software component 2 indirectly "works" for the main software component A. The third auxiliary software component 3 "works" for the second auxiliary software component 2 and, under commands from the main software component A, performs data access to an external data center. Requests from the main software component A are fulfilled by the first auxiliary software component 1. Data (requests and responses) are exchanged between the main software component A and the first auxiliary software component 1, between the first auxiliary software component 1 and the second auxiliary software component 2, and between the second auxiliary software component 2 and the third auxiliary software component 3.

[0029] A performance metric collector B is also installed in the computing hardware environment. This can be a standalone data monitoring software used to collect performance metrics about each software component. It's important to emphasize that performance metric collector B can collect performance metrics about this workload because they are the same as those of the main software component A.

[0030] Please see Figure 2 This figure is a flowchart of a prediction-based method according to the present invention for analyzing the performance impact caused by changes in the content of software system components. The first step of the prediction-based method is to provide a software system deployed in a computing hardware environment, the software system including a main software component that satisfies requests from a workload, and at least one auxiliary software component that processes specific tasks of the main software component (S01). This step is only to define a suitable architecture as described above.

[0031] The second step of this prediction-based method is to collect performance metrics (S02) regarding the workload and each auxiliary software component separately and sequentially before a change is introduced into the software system. As mentioned above, latency of the workload and the number of CPUs used by the auxiliary software components are used for description. This utilizes the performance relationship between two different performance metrics to predict the future performance of one of them. In other embodiments, the performance of only one performance metric is sufficient to predict its future. An example is... Figure 5As shown, the figure also lists the calculated data and results of the correlation coefficient and performance difference values. Performance metric collector B collects performance metrics (latency) for this workload (main software component A) sequentially from T1 to T5, with data of 2, 5, 4, 2, and 3 respectively. The time interval between adjacent time points is the same, for example, 5 seconds, but this is not limited by the present invention, as long as the selected time interval can utilize fewer hardware resources or perform well in the analysis of the impact of changes. A change, for example, upgrading the first auxiliary software component 1, occurs at T6. Performance metric collector B also collects performance metrics (number of CPUs used) for the first auxiliary software component 1, the second auxiliary software component 2, and the third auxiliary software component 3 sequentially from T1 to T5. The corresponding data is displayed in the time point fields of Project Descriptions No. 2 to No. 4.

[0032] The third step of this prediction-based method is to calculate the correlation coefficients (S03) between the collected performance metrics for the workload and the performance metrics for each auxiliary software component. The correlation coefficient is a numerical measure of some type of correlation between two sets of variables. According to its calculation formula, the correlation coefficient varies between -1 and 1. Using data from T1 to T5 of Project Description No. 1 and No. 2, the correlation coefficient is 0.81. Similarly, using data from T1 to T5 of Project Description No. 1 and No. 3, the correlation coefficient is -0.18. Using data from T1 to T5 of Project Description No. 1 and No. 4, the correlation coefficient is 0.96.

[0033] Based on the result of step S03, the prediction-based method has the following different steps. If the absolute value of the correlation coefficient is greater than a threshold, the fourth step is to establish a prediction model using the multiple collected performance metrics related to the workload and the multiple collected performance metrics related to the corresponding auxiliary software components, to predict the performance metrics of the corresponding auxiliary software components over a future period (S04). Here, the threshold limits the relationship between the workload and the hardware resource usage or performance trend of each auxiliary software component. In this example, the threshold is set to 0.7, which means that the trends should be very close in both the same and opposite directions, indicating a strong correlation between the collected performance metrics related to the workload and the collected performance metrics related to the corresponding auxiliary software component. In other embodiments, the threshold can be any number between 0 and 1, and the present invention is not limited to it. Figure 5It is understood that the correlation coefficients between the collected performance metrics of the workload and the collected performance metrics of the first auxiliary software component 1, and the correlation coefficients between the collected performance metrics of the workload and the collected performance metrics of the third auxiliary software component 3, meet this requirement. In accordance with the spirit of this invention, the method of constructing the predictive model is not limited; any existing data prediction model can be used, even simple statistical formulas. A more accurate predictive model is preferred because it can save resources or provide better results. If necessary, a machine learning predictive model can be used. Preferably, it is built by a time series prediction algorithm, which can be ARIMA or SARIMA. In this embodiment, the predictive model is built by ARIMA. A prerequisite for building the predictive model is that the input must be the collected performance metrics of the workload and the collected performance metrics of the corresponding auxiliary software component before T6. Clearly, the collected performance metrics used to build the predictive model are divided into two categories.

[0034] Next, based on the results of step S04, the fifth step of the prediction-based method is to sequentially record performance metrics related to the corresponding auxiliary software component and the workload during an evaluation period that begins when the change to the software system is introduced (S05). As mentioned above, the two auxiliary software components, the first auxiliary software component 1 and the third auxiliary software component 3, are the corresponding auxiliary software components mentioned in step S05. Therefore, the performance metrics associated with them are recorded by the performance metric collector B. The verb "record" used here and the verb "collect" used in step S02 refer to the same thing, both describing how the performance metric collector B obtains data from the software components. Different verbs are used to describe performance metrics in different steps. In this embodiment, the evaluation period starts from T6 and ends at T10. The performance metrics related to the workload recorded from T6 to T10 are 1, 3, 7, 2, and 1. Five performance metric data related to the first auxiliary software component 1 or the third auxiliary software component 3 are recorded by the performance metric collector B. They are 2, 3, 4, 1 and 2 of the first auxiliary software component 1, and 1, 1, 3, 1 and 1 of the third auxiliary software component 3.

[0035] The sixth step of this prediction-based method involves inputting the performance metrics collected in step S02 regarding the workload and the corresponding auxiliary software component into the prediction model to obtain the predicted performance metrics of the corresponding auxiliary software component (S06). Figure 5In the input, the performance metrics for the workload before the change was applied were 2, 5, 4, 2, and 3; the performance metrics for the first auxiliary software component 1 were 2, 3, 2, 1, and 2; and the performance metrics for the third auxiliary software component 3 were 1, 3, 2, 1, and 2. These were all collected before the application was applied.

[0036] The final step of this prediction-based method is to calculate a performance difference value (S07) using the multiple recorded performance metrics of the corresponding auxiliary software component and the multiple predicted performance metrics of the corresponding auxiliary software component. The performance difference value is used to describe the trend and approximate magnitude of the difference between the predicted and observed values. There are many methods for generating performance difference values. In this embodiment, the Mean Percentage Error (MPE) is used. MPE is the calculated average of percentage errors, through which predictions from models that differ from the actual number of predictions can be predicted. The formula for MPE is:

[0037]

[0038] Where y i Refers to all observed data, x i It corresponds to y i The predicted value is y, where k is the degree of the estimated variable. In this embodiment, y i This refers to the numbers from T6 to T10 in project description No. 8 or No. 10. Therefore, k is 5 because 5 sets of numbers were recorded. i For the numbers T6 to T10 in Project Description No. 11 or No. 13. Using the relevant data above, the MPE of the recorded performance indicators for the first auxiliary software component 1 compared to the predicted performance indicators for the first auxiliary software component 1 is 50.00%, while the MPE of the recorded performance indicators for the third auxiliary software component 3 compared to the predicted performance indicators for the third auxiliary software component 3 is -30.00%.

[0039] Please see Figure 6This graph shows the performance metrics of the workload, the collected / recorded performance metrics of the first auxiliary software component 1, and the predicted performance metrics of the first auxiliary software component 1 over time. Before T6, the trend of the workload is similar to the trend of the collected performance metrics of the first auxiliary software component 1, with peaks and troughs occurring at the same time points. A prediction is obtained based on the steps described above (as shown by the dotted line). The recorded performance metrics of the first auxiliary software component 1 differ from the predicted performance metrics of the first auxiliary software component 1 and have different trends. On average, the changes cause the predicted performance metrics of the first auxiliary software component 1 to be 50.00% higher than they should be. Similarly, see... Figure 8 This graph shows the performance metrics of the workload, the collected / recorded performance metrics of the third auxiliary software component 3, and the predicted performance metrics of the third auxiliary software component 3 over time. Before T6, the workload trend was similar to the trend of the collected performance metrics of the third auxiliary software component 3. A prediction was also obtained based on the steps described above (as shown by the dotted line). The recorded performance metrics of the third auxiliary software component 3 differed from the predicted performance metrics and showed different trends. On average, the changes caused the predicted performance metrics of the third auxiliary software component 3 to be 30.00% lower than they should have been. Once the performance difference values ​​are obtained, the magnitude of the impact of the changes on the performance metrics can be predicted, and necessary adjustments can be made to the computing hardware environment.

[0040] When the absolute value of the correlation coefficient is less than a threshold, this invention provides another method to analyze the performance impact caused by changes in the content of software system components. Please refer to [link / reference]. Figure 3 This figure is another flowchart of a prediction-based method according to the present invention for analyzing the performance impact caused by changes in the content of software system components.

[0041] If the absolute value of the correlation coefficient is less than a threshold, the alternative fourth step is to build a predictive model using the collected performance metrics for the corresponding auxiliary software component to predict its performance over a future period (S04'). Here, the threshold remains unchanged at 0.7. An absolute value of the correlation coefficient less than 0.7 also indicates a weak or no correlation between the collected performance metrics for the workload and the collected performance metrics for the corresponding auxiliary software component. Figure 5 It can be seen that the correlation coefficient between the collected performance metrics for this workload and the collected performance metrics for the second auxiliary software component 2 meets this requirement. The prediction model was established by ARIMA. A prerequisite for establishing the prediction model is that the input must be the performance metrics for the second auxiliary software component 2 collected before T6.

[0042] Next, based on the results of step S04', the alternative fifth step of this prediction-based method is to sequentially record performance metrics for the corresponding auxiliary software component during an evaluation period that begins when the change to the software system is introduced (S05'). Here, the second auxiliary software component 2 is the corresponding software component referred to in step S05'. Therefore, the performance metrics for the second auxiliary software component 2 are recorded by the performance metric collector B. The performance metrics for the first auxiliary software component 2 recorded from T6 to T10 are 3, 2, 3, 2, and 3.

[0043] The sixth step of this prediction-based method is to input the performance metrics collected in step S02 regarding the corresponding auxiliary software component into the prediction model to obtain the predicted performance metrics of the corresponding auxiliary software component (S06'). Figure 5 In the input, the performance metrics are 2, 2, 3, 3 and 4.

[0044] The final step of this prediction-based alternative is to calculate a performance variance value (S07') using the multiple recorded performance metrics for the corresponding auxiliary software component and the multiple predicted performance metrics for the corresponding auxiliary software component. Steps S07 and S07' are identical, but the data generation method differs. The MPE is still used as the performance variance value. According to the formula, y i It's in project description No. 9, the number from T6 to T10. k is 5. x i For the numbers T6 to T10 in Project Description No. 11 or No. 13. Using the relevant data above, the recorded MPE for the performance metrics of the second auxiliary software component 2, compared to the predicted performance metrics, is 90.00%.

[0045] Please see Figure 7 This graph shows the performance metrics of the workload, the collected / recorded performance metrics of the second auxiliary software component 2, and the predicted performance metrics of the second auxiliary software component 2 over time. Prior to T6, the trend of the workload was dissimilar to the trend of the collected performance metrics of the second auxiliary software component 2. A prediction was obtained based on the alternative steps described above (as shown by the dotted line). The recorded performance metrics of the second auxiliary software component 2 differed from the predicted performance metrics of the second auxiliary software component 2 and exhibited different trends. On average, the changes resulted in the predicted performance metrics of the second auxiliary software component 2 being 90.00% higher than their expected levels.

[0046] In this embodiment, time points arrive consecutively, one after another. In practice, there can be an interruption between T5 and T6. This means that data for building the predictive model can be collected earlier than the introduction of changes. Furthermore, because workload patterns are likely based on a specific time of day or a specific day of week, it is beneficial for the software system to build predictive models at similar times of day (or a specific day of week) for each analysis. Collected / recorded performance metrics can be obtained at other times.

[0047] Analyzing the impact of changes offers several advantages. First, the affected software components and their impact values ​​can be identified. For the development and operations teams, this allows them to determine whether changes to one or more software components after the release of new software have resulted in gains or losses in the software system's performance. The engineering team can confirm whether the results meet expectations or if there are any anomalies, providing feedback to the engineering team. Second, it makes it easy to assess whether certain system parameters should be adjusted in response to such changes. For example, database / backend service configuration settings might involve adding a new cluster node, several CPUs, or memory modules to the computing hardware environment. The operations team can also analyze the quantified results to help them assess whether the changes they made achieved their intended goals. If the performance impact is too significant, one possible action might be to roll back the changes.

[0048] Although the present invention has been disclosed above with reference to embodiments, it is not intended to limit the present invention. Anyone skilled in the art can make some modifications and refinements without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the claims.

Claims

1. A prediction-based method for analyzing the performance impact caused by changes in the content of software system components, characterized in that, Includes the following steps: a) Provide a software system deployed in a computing hardware environment, the software system comprising a main software component that fulfills requests from a workload, and at least one auxiliary software component that performs specific tasks of the main software component; b) Prior to the introduction of any change to the software system, performance metrics for the workload and each auxiliary software component were collected separately and sequentially. c) Calculate the performance metrics of the workload collected in step b) and the correlation coefficients between the performance metrics of each auxiliary software component collected in step b); d) When the absolute value of the correlation coefficient is greater than a threshold, a prediction model is established based on the performance indicators of the workload collected in step b) and the performance indicators of the corresponding auxiliary software components collected in step b) to predict the performance indicators of the corresponding auxiliary software components in the future, wherein the corresponding auxiliary software components are one of the at least one auxiliary software components. e) Record the performance metrics of the corresponding auxiliary software component and the workload sequentially during an evaluation period, wherein the evaluation period begins when a change to the software system is introduced, and the change to the software system is a software system upgrade, an adjustment of software system application configuration parameters, the installation of a new auxiliary software component, or the removal of an existing auxiliary software component; f) Input the performance metrics of the workload and the corresponding auxiliary software component collected in step b) into the prediction model to obtain the predicted performance metrics of the corresponding auxiliary software component; and g) Calculate a performance difference value based on the performance index of the corresponding auxiliary software component recorded in step e) and the predicted performance index of the corresponding auxiliary software component obtained through the prediction model.

2. A prediction-based method for analyzing the performance impact caused by changes in the content of software system components, characterized in that, Includes the following steps: a) Provide a software system deployed in a computing hardware environment, the software system comprising a main software component that fulfills requests from a workload, and at least one auxiliary software component that performs specific tasks of the main software component; b) Prior to the introduction of any change to the software system, performance metrics for the workload and each auxiliary software component were collected separately and sequentially. c) Calculate the performance metrics of the workload collected in step b) and the correlation coefficients between the performance metrics of each auxiliary software component collected in step b); d) When the absolute value of the correlation coefficient is less than a threshold, a prediction model is established based solely on the performance indicators of the corresponding auxiliary software component collected in step b) to predict the performance indicators of the corresponding auxiliary software component in the future, wherein the corresponding auxiliary software component is one of the at least one auxiliary software component. e) Record the performance metrics of the corresponding auxiliary software components sequentially during an evaluation period, wherein the evaluation period begins when a change to the software system is introduced, and the change to the software system is a software system upgrade, an adjustment of software system application configuration parameters, the installation of a new auxiliary software component, or the removal of an existing auxiliary software component; f) Input the performance metrics of the corresponding auxiliary software component collected in step b) into the prediction model to obtain the prediction performance metrics of the corresponding auxiliary software component; and g) Calculate a performance difference value based on the performance index of the corresponding auxiliary software component recorded in step e) and the predicted performance index of the corresponding auxiliary software component obtained through the prediction model.

3. The prediction-based method as described in claim 1 or 2, characterized in that, The computing hardware environment is a workstation host or a server cluster.

4. The prediction-based method as described in claim 1 or 2, characterized in that, This performance metric includes the amount of memory used, the number of CPUs used, input / output throughput, response time, requests per second, or latency.

5. The prediction-based method as described in claim 1 or 2, characterized in that, The performance difference is the average percentage error.

6. The prediction-based method as described in claim 1 or 2, characterized in that, The performance metrics used to build this predictive model are divided into two categories.

7. The prediction-based method as described in claim 1 or 2, characterized in that, The prediction model was built using a time series prediction algorithm.

8. The prediction-based method as described in claim 7, characterized in that, The time series forecasting algorithm is either the differential integrated moving average autoregressive algorithm or the seasonal differential integrated moving average autoregressive algorithm.

Images