A current-limiting threshold prediction method, device, apparatus, program product, and storage medium

Abstract

Embodiments of the present application disclose a traffic limiting threshold prediction method, device, equipment, program semantics and storage medium, relating to the field of financial technology, comprising: obtaining interface traffic data of each transaction service interface according to a preset period through each transaction service interface; for each period, if the current period is not the initial period, processing each interface traffic data according to the target traffic data of the previous period, the interface traffic data of the current period and the interface type of each transaction service interface to obtain traffic input data of the current period; inputting the traffic input data into a pre-trained traffic prediction model to obtain traffic prediction data of the next period output by the traffic prediction model; and determining the traffic limiting threshold of each transaction service interface based on the traffic prediction data of the next period and the interface type. The method can improve the flexibility and accuracy of determining the traffic limiting threshold.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of financial technology, and in particular to a method, apparatus, device, program semantics and storage medium for predicting flow limit thresholds. Background Technology

[0002] Rate limiting is a common performance and capacity assurance technique in distributed systems. In the financial industry, when service request traffic (such as transaction service requests) reaches a predetermined threshold, rate limiting can quickly close the loop (e.g., drop) the traffic exceeding the threshold, thus controlling the flow of traffic to the service provider. While rate limiting technology itself is not complex, implementing it effectively in real-world scenarios and maximizing its impact can be challenging. Users often encounter issues such as persistent rate limiting or rate limiting failing to trigger, negatively affecting user experience. Setting appropriate rate limiting thresholds can improve accuracy and prevent these problems.

[0003] Current methods for determining rate limiting thresholds mostly involve setting a fixed threshold based on CPU utilization and system load. While this approach ensures a certain level of throughput, in real-world applications, some intensive tasks generate a large number of service requests that are not directly related to CPU utilization and do not significantly increase CPU usage. Therefore, determining the rate limiting threshold based on CPU utilization is neither flexible nor accurate enough, and cannot guarantee the accuracy of the threshold setting. This can easily lead to incorrect or no rate limiting, thus affecting the user experience. Summary of the Invention

[0004] This invention provides a method, apparatus, device, program semantics, and storage medium for predicting rate limiting thresholds. It can accurately predict the rate limiting threshold for the next time period based on the actual traffic usage of different interfaces in historical time periods, improving the flexibility and accuracy of rate limiting thresholds. It can cope with possible traffic fluctuations in the future, avoid false rate limiting or no rate limiting, and improve user experience.

[0005] In a first aspect, embodiments of the present invention provide a method for predicting a current limiting threshold, comprising:

[0006] The interface traffic data of each transaction service interface is obtained according to a preset period through the pre-defined transaction service interfaces.

[0007] For each period, if the current period is not the initial period, the traffic data of each interface is processed according to the predetermined target traffic data of the previous period, the traffic data of each interface in the current period, and the interface type of each transaction service interface to obtain the traffic input data of the current period; wherein, the interface type is a core interface or a non-core interface.

[0008] The traffic input data is input into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model.

[0009] Based on the traffic prediction data for the next period and the interface types, the rate limiting thresholds for each transaction service interface are determined, and rate limiting is applied to each transaction service interface in the next period according to the rate limiting thresholds.

[0010] Secondly, embodiments of the present invention provide a current limiting threshold prediction device, the device comprising:

[0011] The data acquisition module is used to acquire interface traffic data of each transaction service interface according to a preset period through each pre-defined transaction service interface.

[0012] The data processing module is used to process the traffic data of each interface according to the predetermined target traffic data of the previous period, the traffic data of each interface in the current period, and the interface type of each transaction service interface for each period, if the current period is not the initial period, to obtain the traffic input data of the current period; wherein, the interface type is a core interface or a non-core interface.

[0013] The data prediction module is used to input the traffic input data into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model.

[0014] The threshold determination module is used to determine the rate limiting threshold of each transaction service interface based on the traffic prediction data of the next period and each interface type, and to limit the rate of each transaction service interface in the next period according to each rate limiting threshold.

[0015] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements a current limiting threshold prediction method as described in any of the embodiments of the present invention.

[0016] Fourthly, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a current limiting threshold prediction method as described in any of the embodiments of the present invention.

[0017] Fifthly, embodiments of the present invention provide a computer program product, including a computer program that, when executed by a processor, implements a current limiting threshold prediction method as described in any of the embodiments of the present invention.

[0018] In this embodiment of the invention, interface traffic data of each transaction service interface is acquired according to a preset period through pre-defined transaction service interfaces. For each period, if the current period is not the initial period, the interface traffic data is processed according to the pre-determined target traffic data of the previous period, the interface traffic data of the current period, and the interface type of each transaction service interface to obtain the traffic input data of the current period. The interface type is either a core interface or a non-core interface. The traffic input data is input into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model. Based on the traffic prediction data for the next period and the interface type, the rate limiting threshold for each transaction service interface is determined, and rate limiting is applied to each transaction service interface in the next period according to the rate limiting threshold. This method can accurately predict the traffic trends of different types of transaction service interfaces in the next time period based on the actual traffic usage of each transaction service interface in historical time periods, enabling the server to accurately determine the rate limiting threshold for the next time period based on the traffic trends. The method of this invention improves the flexibility and accuracy of determining the rate limiting threshold, which helps to improve the performance and stability of the system. At the same time, it can cope with possible traffic fluctuations, avoid false rate limiting or no rate limiting, and improve user experience. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a first flowchart of a current limiting threshold prediction method provided in an embodiment of the present invention;

[0021] Figure 2 This is a second flowchart of a current limiting threshold prediction method provided in an embodiment of the present invention;

[0022] Figure 3 A flowchart of a method for configuring rate limiting parameters provided in an embodiment of the present invention;

[0023] Figure 4 This is a schematic diagram of the structure of a current limiting threshold prediction device provided in an embodiment of the present invention;

[0024] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0026] Figure 1 This is a first flowchart of a rate limiting threshold prediction method provided by an embodiment of the present invention. The method of this embodiment can accurately predict the rate limiting threshold for the next time period based on the actual traffic usage of different interfaces in historical time periods, improving the flexibility and accuracy of the rate limiting threshold. It can cope with possible subsequent traffic fluctuations, avoid erroneous rate limiting or no rate limiting, and improve user experience. The information collected in the method of this embodiment is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of relevant countries and regions, and necessary confidentiality measures are taken. It does not violate public order and good morals, and corresponding operation entry points are provided for users to choose to authorize or refuse. This method can be executed by a rate limiting threshold prediction device provided by an embodiment of the present invention, which can be implemented in software and / or hardware. The following embodiments will illustrate this using the integration of the device in an electronic device as an example. The electronic device can be a server or computer device, etc., see reference. Figure 1 The method may specifically include the following steps:

[0027] Step 101: Obtain the interface traffic data of each transaction service interface according to the preset period through the pre-defined transaction service interfaces.

[0028] The transaction service interface defines how the client (caller) requests the service and how the server (callee) responds to the service request. When a user uses a transaction service (such as a query service or a payment service) through a client, the client can send the corresponding transaction request to the server through each transaction service interface. Interface traffic data is a collection of information such as the amount of data transmitted through the transaction service interface within a certain period of time, the number of requests, and related performance metrics. In this solution, interface traffic data includes, but is not limited to, time information, traffic information, and call information. Traffic information includes, but is not limited to, the service interface name (the name that identifies the service interface being monitored), concurrency (how many requests are being processed at the same time), the number of requests processed per second (Transactions Per Second, TPS), and the interface response time. Call information includes whether the interface call is abnormal. The preset period is a predetermined duration based on the domain big data and the actual operating environment of the system (such as a banking system), for example, the preset period could be 6 months.

[0029] Specifically, the server can collect interface traffic data of the transaction service interface in each period and predict the rate limiting threshold for the next period based on the interface traffic data of the current period. For example, if the preset period is 6 months, the rate limiting threshold for each transaction service interface from June to December can be predicted at the end of June based on the interface traffic data from January to June.

[0030] Step 102: For each period, if the current period is not the initial period, process the traffic data of each interface according to the predetermined target traffic data of the previous period, the traffic data of each interface in the current period, and the interface type of each transaction service interface to obtain the traffic input data of the current period.

[0031] The initial period is the first period in which the traffic limiting threshold is predicted. The target traffic data is determined based on the traffic input data of the previous period. Interface types are categorized as either core or non-core interfaces. Core interfaces are crucial for business operations, while non-core interfaces contribute to the overall system functionality but are less important, or their failures have a smaller impact on business. If the current period is the initial period, meaning there is no previous period, the traffic input data is determined directly based on the interface traffic data and interface type for the current period. If the current period is not the initial period, the traffic input data needs to be determined based on the target traffic data of the previous period, the interface traffic data of the current period, and the interface type. For example, if the current period is the initial period (January to June 2024), the traffic input data is determined based on the interface traffic data and interface type from January to June 2024. If the current period is July to December 2024, the traffic input data is determined based on the traffic input data from January to June 2024, and the interface traffic data and interface type from July to December 2024.

[0032] Specifically, the importance of interface traffic data varies depending on the interface type. For interface traffic data from less important non-core interfaces, the server can perform data compression or aggregation to calculate representative data, which is then used to replace the original interface traffic data. Since non-core interface traffic data has a relatively small impact on the system, replacing the original interface traffic data with representative data does not affect the accuracy of rate limiting threshold determination and can also reduce the computational complexity and efficiency of rate limiting threshold prediction. For interface traffic data from more important core interfaces, no filtering or compression is required. Furthermore, the traffic input data for the current period is determined based on the target traffic data from the previous period, the processed interface traffic data from non-core interfaces, and the interface traffic data from core interfaces.

[0033] In one optional implementation, after obtaining the interface traffic data for the current period, the interface traffic data is cleaned according to the time information of each interface traffic data to obtain candidate interface traffic data; traffic data of non-core interface type is filtered from all candidate interface traffic data; for each non-core interface traffic data, non-core interface sub-data in each preset time period is obtained from the current non-core interface traffic data; aggregated data of each non-core interface sub-data is determined according to a preset aggregation period; each non-core interface sub-data is updated according to the aggregated data to obtain aggregated traffic data of each non-core interface. The traffic input data for the current period is obtained based on the target traffic data of the previous period, the aggregated traffic data of each non-core interface, and the candidate interface traffic data of each core interface.

[0034] Step 103: Input the traffic input data into the pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model.

[0035] The traffic forecasting model is pre-trained and used to predict future traffic data based on historical traffic data. The traffic forecasting model in this solution is a time series model, such as the Prophet model. The Prophet model is a model used for time series forecasting that can capture trends and seasonal variations in data. The Prophet model can automatically detect and process various seasonal patterns in time series data, including annual, monthly, weekly, and daily seasonality. The Prophet model also allows users to specify holidays and their impact on the time series data.

[0036] In one optional implementation, before acquiring interface traffic data for each transaction service interface according to a preset period, the server can train the Prophet model based on a large amount of pre-collected historical interface traffic data. After obtaining the historical interface traffic data, the historical interface traffic data is cleaned to remove outliers. Based on the interface type corresponding to the interface traffic data, the interface traffic data of non-core interfaces is aggregated; for example, on a weekly basis, the interface traffic data with the highest concurrency in each week is selected and replaced with the interface traffic data of that week. A training sample set and a training test set are established based on the processed interface traffic data of non-core interfaces and core interfaces. After obtaining the training sample set, it is input into the Prophet model to train it. The predictive performance of the Prophet model is evaluated using the training test set, and the model parameters are adjusted according to the evaluation results until the evaluation results meet preset conditions, resulting in a trained Prophet model, i.e., a trained traffic prediction model.

[0037] The Prohet model's parameters include seasonality parameters and trend parameters. Seasonal parameters include seasonal pattern parameters and seasonal strength parameters. Trend parameters control the flexibility of the Prohet model in detecting and adapting to changes within a trend, determining its sensitivity to potential trend changes in the data. A larger trend parameter value indicates that the Prohet model will consider data with sudden and significant changes. Seasonal strength parameters control the flexibility and intensity of seasonal effects in the Prohet model, determining the model's "confidence" or "uncertainty" regarding seasonal patterns. A larger seasonal pattern parameter value indicates that the Prohet model is more inclined to capture strong seasonal variations in the data. The seasonal pattern parameter defines whether the seasonal pattern is additive or multiplicative. Additive seasonality means that the seasonal effect is added to the basic trend by a fixed amount; regardless of changes in the trend itself, the magnitude of the seasonal effect remains constant. In this scheme, the Prohet model is used to predict interface traffic data for a trading service interface. The settings of seasonality and trend parameters not only affect the quality of the Prohet model's fit to historical data but also directly relate to the accuracy and reliability of future predictions. By training the Prophet model with a large amount of historical interface traffic data, accurate seasonal and trend parameters for predicting interface traffic data can be obtained.

[0038] Furthermore, after obtaining the trained traffic prediction model and the traffic input data for the current period, the traffic input data for the current period is input into the traffic prediction model to obtain the traffic prediction data for the next period predicted by the traffic prediction model.

[0039] Step 104: Determine the rate limiting threshold for each transaction service interface based on the traffic prediction data for the next period and the interface types, and implement rate limiting for each transaction service interface in the next period according to the rate limiting threshold.

[0040] The predicted data includes interface traffic data for each transaction service interface in the next cycle. This traffic data includes, but is not limited to, time information, traffic information, and call information for each transaction service interface. Traffic information includes, but is not limited to, service interface name, concurrency, TPS, and interface response time. Rate limiting thresholds instruct the server how to limit the rate of each transaction service interface. These thresholds include concurrency thresholds, TPS thresholds, and response time thresholds. Specifically, different interface types correspond to different levels of importance for their respective transaction service interfaces. For core interfaces with high importance, smaller threshold ranges may be set to ensure service quality. For non-core interfaces, larger threshold ranges can be set to allow for greater flexibility and throughput. After obtaining the traffic prediction data, it can be visualized, displaying the traffic prediction data for each transaction service interface in the form of line graphs, etc., to facilitate observation of its changing trends and thus accurately set the rate limiting thresholds for each transaction service interface.

[0041] In one optional implementation, after obtaining the traffic prediction data for the next period, a recommended rate limiting threshold for each transaction service interface is calculated based on the traffic prediction data for the next period. For each transaction service interface, if the interface type of the current transaction service interface is a core interface, then the rate limiting threshold for the current transaction service interface is determined to be the recommended rate limiting threshold. If the interface type of the current service interface is a non-core interface, the rate limiting threshold for the current transaction service interface is determined based on the traffic information of the current interface traffic data and the recommended rate limiting threshold. The traffic information includes the concurrency of the transaction service interface.

[0042] The technical solution of this embodiment acquires interface traffic data for each transaction service interface according to a preset period. For each period, if the current period is not the initial period, the interface traffic data is processed based on the predetermined target traffic data of the previous period, the interface traffic data of the current period, and the interface type of each transaction service interface to obtain the traffic input data for the current period. The interface type is either a core interface or a non-core interface. The traffic input data is input into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model. Based on the traffic prediction data for the next period and the interface type, a rate limiting threshold for each transaction service interface is determined, and rate limiting is applied to each transaction service interface in the next period according to the rate limiting threshold. This technical solution can accurately predict the traffic trends of different types of transaction service interfaces in the next time period based on the actual traffic usage of each transaction service interface in historical time periods, enabling the server to accurately determine the rate limiting threshold for the next time period based on the traffic trends. The method of this invention improves the flexibility and accuracy of determining the rate limiting threshold, which helps to improve the performance and stability of the system. At the same time, it can cope with possible traffic fluctuations, avoid false rate limiting or no rate limiting, and improve user experience.

[0043] Figure 2 This is a second flowchart of a current limiting threshold prediction method provided in an embodiment of the present invention. This embodiment is a refinement based on the above embodiment. The specific method can be as follows: Figure 2 As shown, the method may include the following steps:

[0044] Step 201: Obtain the interface traffic data of each transaction service interface according to the preset period through the pre-set transaction service interfaces.

[0045] Step 202: For each period, if the current period is not the initial period, clean the traffic data of each interface according to the time information of each interface traffic data to obtain the traffic data of each candidate interface.

[0046] The time information includes the timestamp when each interface traffic data was generated. Data cleaning includes checking data consistency and handling invalid and missing values. In this solution, after obtaining the traffic data for each interface, the system determines whether any data interruptions have occurred based on the timestamp of each traffic data entry for each transaction service interface. If a data interruption occurs more than a preset number of times in a data entry, that data entry is deleted. Candidate traffic data is obtained after cleaning the traffic data from each interface in the current period.

[0047] For example, with a preset count of three, interface traffic data 1 includes 8 data entries: 2024-01-01 (timestamp): 100 (data); 2024-01-02: 150; 2024-01-03: Missing; 2024-01-04: 150; 2024-01-05: Missing; 2024-01-06: 150; 2024-01-07: Missing; 2024-01-08: 200. It can be determined that interface traffic data 1 has three instances of missing data, and each missing data entry causes a data interruption, further confirming the need to delete this interface traffic data. For example, interface traffic data 2 includes 8 data entries: 2024-01-01: 100; 2024-01-02: 150; 2024-01-03: Missing; 2024-01-04: Missing; 2024-01-05: Missing; 2024-01-06: 150; 2024-01-07: 200; 2024-01-08: 200. It can be determined that there are three instances of missing data in interface traffic data 2, but these three instances are consecutive, thus only causing one data interruption. Therefore, it is determined that this interface traffic data should be retained.

[0048] Step 203: Filter out the traffic data of non-core interfaces from all candidate interface traffic data, and aggregate the traffic data of each non-core interface to obtain the aggregated traffic data of each non-core interface.

[0049] Specifically, the importance of interface traffic data varies depending on the interface type. For the interface traffic data of non-core interfaces with lower importance, the server can aggregate the interface traffic data of non-core interfaces to calculate representative data. This representative data can then replace the original interface traffic data, thereby reducing the computational complexity of predicting the rate limiting threshold. Optionally, this solution involves aggregating the traffic data of each non-core interface to obtain aggregated traffic data for each non-core interface. This includes: for each non-core interface, obtaining the non-core interface sub-data within each preset time period from the current non-core interface traffic data; determining the aggregated data for each non-core interface sub-data; and updating the non-core interface sub-data based on the aggregated data to obtain the aggregated traffic data for each non-core interface.

[0050] The preset time period is determined in advance based on the total amount of domain big data, interface traffic data, and the actual operating environment of the system. It is used to determine the time interval for data aggregation of interface traffic data. In this solution, the preset time interval can be one week. Data aggregation is the process of summarizing a large amount of data into smaller and more meaningful datasets.

[0051] Specifically, after obtaining the traffic data for each non-core interface, the data is segmented according to a preset time period to obtain non-core interface sub-data for each time period. Aggregation calculations are then performed on the non-core interface sub-data for each time period to obtain aggregated data for each non-core interface sub-data. Aggregation calculations include summation, averaging, counting, taking the maximum or minimum value, etc. In this solution, the aggregation calculation is to take the maximum value, that is, select the maximum value from each non-core interface sub-data and determine this maximum value as the aggregated data for the non-core interface sub-data. The aggregated data replaces all data within the original preset time period to obtain the aggregated traffic data for the non-core interfaces. For example, the non-core interface data includes data from four weeks, with 100 data entries per week. The data with the largest traffic information value in each week is selected as the aggregated data for that week, and this aggregated data replaces all data for that week. After data aggregation, the system only needs to process 4 data entries. Without data aggregation, the system would need to process 400 data entries.

[0052] Since the interface traffic data of non-core interfaces has little impact on the system, replacing the original interface traffic data with representative data will not affect the accuracy of the rate limiting threshold determination. It can also reduce the computational complexity of rate limiting threshold prediction and improve the efficiency of rate limiting threshold prediction.

[0053] Step 204: Obtain traffic input data based on the target traffic data of the previous period, the aggregated traffic data of each non-core interface, and the candidate interface traffic data of each core interface.

[0054] The target traffic data is determined based on the traffic input data from the previous period. The traffic input data is the data fed into the traffic prediction model. Specifically, to continuously improve the accuracy of threshold prediction, after obtaining the traffic prediction data and rate limiting threshold from the previous period, the accuracy of the rate limiting threshold from the previous period can be evaluated based on the interface traffic data of each transaction service interface in the current period. Based on the evaluation results and the traffic prediction model, the input traffic data from the previous period is optimized to obtain the target traffic data. The target traffic data from the previous period, the aggregated traffic data of each non-core interface in the current period, and the candidate traffic data of each core interface are determined as the traffic input data for the current period.

[0055] Step 205: Input the traffic input data into the pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model.

[0056] Step 206: Calculate the recommended flow limit threshold for each transaction service interface based on the traffic prediction data for the next cycle.

[0057] The recommended traffic threshold is determined based on the traffic prediction data for the next period and serves as an instruction to the server on how to limit the flow of traffic to each transaction service interface in the next period. After obtaining the traffic prediction data for the next period, the recommended flow limit threshold for each transaction service interface is determined based on this data. In this solution, considering that systems in financial business scenarios often have significant performance redundancy, abnormally high or low data points are filtered out after obtaining the traffic prediction data. The filtered traffic prediction data is then flexibly adjusted to ensure that the flow limit threshold always maintains a certain level of redundancy. For example, if the concurrency in the traffic prediction data is 100, the corresponding recommended flow limit threshold can be set to 100. To ensure that the flow limit threshold always maintains a certain level of redundancy, it can be adjusted by 30%, resulting in a final recommended flow limit threshold of 130.

[0058] Step 207: For each transaction service interface, if the interface type of the current transaction service interface is a core interface, then determine that the rate limiting threshold of the current transaction service interface is the recommended rate limiting threshold.

[0059] Specifically, the importance of interface traffic data varies depending on the interface type. For the interface traffic data of core interfaces with higher importance, the recommended rate limiting threshold can be directly determined as the rate limiting threshold for the transaction service interface.

[0060] Step 208: If the current service interface is a non-core interface, determine the rate limiting threshold of the current transaction service interface based on the traffic information of the current interface traffic data.

[0061] The traffic information includes the concurrency of the transaction service interfaces. In this solution, for non-core interfaces, since their impact on system business services is relatively small, the current rate limiting threshold for the transaction service interface can be determined based on the concurrency of the interface traffic data and the recommended rate limiting threshold. In practical applications, it is common for 20% of the transaction service interfaces to handle 80% of the business volume, while most transaction service interfaces normally handle relatively small transaction volumes and do not require very granular rate limiting configuration. Therefore, for non-core interfaces, the rate limiting threshold can be determined using a tiered configuration mode, that is, the concurrency threshold in the rate limiting threshold is determined based on the predicted concurrency of the interface traffic data. For example, the rate limiting thresholds corresponding to the concurrency of each traffic prediction data are shown in Table 1 below:

[0062] Concurrency of traffic prediction data Rate limiting threshold 0-10 10 11-30 30 31-60 60 61-100 100

[0063] Table 1

[0064] Step 209: Implement rate limiting for each transaction service interface in the next cycle based on each rate limiting threshold.

[0065] In this embodiment, the technical solution involves acquiring interface traffic data for each transaction service interface according to a preset period, based on pre-defined transaction service interfaces. For each period, if the current period is not the initial period, the interface traffic data is cleaned according to the time information of each interface traffic data to obtain candidate interface traffic data. Traffic data for non-core interfaces is selected from all candidate interface traffic data, and the traffic data for each non-core interface is aggregated to obtain aggregated traffic data for each non-core interface. Traffic input data is obtained based on the target traffic data of the previous period, the aggregated traffic data of each non-core interface, and the candidate interface traffic data of each core interface. Recommended rate limiting thresholds for each transaction service interface are calculated based on the traffic prediction data for the next period. For each transaction service interface, if the interface type of the current transaction service interface is a core interface, the rate limiting threshold for the current transaction service interface is determined to be the recommended rate limiting threshold. If the interface type of the current service interface is a non-core interface, the rate limiting threshold for the current transaction service interface is determined based on the traffic information of the current interface traffic data and the recommended rate limiting threshold; wherein, the traffic information includes the concurrency of the transaction service interface. Rate limiting is applied to each transaction service interface in the next cycle based on various rate limiting thresholds. The technical solution in this embodiment, by aggregating traffic data from non-core interfaces, reduces the system's computational load and improves the efficiency of rate limiting threshold prediction while ensuring the accuracy of the prediction. Setting different rate limiting thresholds for different types of transaction service interfaces improves the accuracy of rate limiting threshold determination, avoids erroneous rate limiting or no rate limiting, and enhances user experience.

[0066] Figure 3 This is a flowchart illustrating a method for configuring rate limiting parameters provided in an embodiment of the present invention. The specific method is as follows: Figure 3 As shown, the method may include the following steps:

[0067] Step 301: Based on the rate limiting threshold and interface traffic data of each transaction service interface in the current period, perform a rate limiting assessment on the rate limiting threshold of each transaction service interface in the current period to obtain the rate limiting assessment result.

[0068] The rate limiting assessment result is either pass or fail. Specifically, the rate limiting threshold for the current period is predicted by a traffic prediction model based on the traffic input data of the previous period. To continuously improve the accuracy of threshold prediction, after obtaining the traffic prediction data and rate limiting threshold of the previous period, the accuracy of the rate limiting threshold of the previous period can be evaluated based on the interface traffic data of each transaction service interface in the current period. Based on the evaluation results and the traffic prediction model, the input traffic data of the previous period is then optimized to obtain the target traffic data.

[0069] After obtaining the interface traffic data for the current period, a rate limiting assessment is performed based on the interface traffic data and the rate limiting threshold for the current period. For example, if an interface reaches a concurrency of 120 in the current period, and its preset rate limiting threshold is 100, it is determined that the traffic of this interface exceeds the rate limiting threshold. The actual traffic data is compared with the corresponding rate limiting threshold. If the actual traffic is less than or equal to the rate limiting threshold, the rate limiting measures for this interface are considered effective, and the assessment result is determined to be "pass". If the actual traffic is greater than the rate limiting threshold, the rate limiting measures are considered to have failed to effectively control the traffic, and the assessment result is determined to be "fail". For example, for an interface with a concurrency of 120, since it exceeds the rate limiting threshold of 100, the rate limiting assessment result for this interface is "fail". Further, an assessment report is generated based on the assessment results of all interface traffic data and their corresponding rate limiting thresholds. The assessment report includes the rate limiting assessment result, actual traffic data, and rate limiting threshold for each interface, and an overall assessment result is obtained based on the assessment results. For example, if more than 50% of the evaluation reports are "not passed", then the overall evaluation result is determined to be "not passed".

[0070] Step 302: When the flow restriction assessment result is passed, determine the target flow data of the previous cycle as the flow input data of the previous cycle.

[0071] Specifically, the flow control assessment results can reflect whether the flow input data of the previous period is accurate. If the flow control assessment result is passed, it means that the flow control threshold set in the previous period can effectively control the flow, and it can be further determined that there is no need to adjust the flow input data of the previous period, that is, the target flow data of the previous period is determined to be the flow input data of the previous period.

[0072] Step 303: When the flow restriction assessment result is unsuccessful, optimize the flow input data of the previous period based on the parameter values ​​of the model parameters of the flow prediction model and the assessment result to obtain the target flow data of the previous period.

[0073] Specifically, if the flow restriction assessment result is unsatisfactory, it indicates that the flow input data of the previous period needs to be adjusted. Optionally, in this scheme, the flow input data of the previous period is optimized based on the parameter values ​​of the flow prediction model and the assessment results to obtain the target flow data for the previous period. This includes: determining the seasonality level of the flow input data of the previous period based on trend parameter values, seasonal parameter values, preset trend parameter thresholds, and preset seasonal parameter thresholds; determining the aggregation period of the flow input data of the previous period based on the seasonality level; and aggregating the flow input data of the previous period based on the aggregation period to obtain the target flow data.

[0074] Seasonal parameters include seasonal pattern parameters and seasonal intensity parameters. Trend parameters and seasonal parameters are crucial in traffic forecasting models. They reflect the characteristics of traffic input data from the previous period. Preset seasonal parameter thresholds include a first seasonal parameter threshold and a second seasonal parameter threshold; preset trend parameter thresholds include a first trend threshold and a second trend threshold. These preset trend parameter thresholds and preset seasonal parameter thresholds are used to determine the seasonal correlation of traffic input data, i.e., the seasonality level. A stronger seasonality level indicates a higher seasonal correlation in the traffic input data.

[0075] In this scheme, when the trend parameter value is less than a first preset trend threshold and the seasonal intensity parameter is less than a first seasonal threshold, the seasonality level of the traffic input data is determined to be weak. When the trend parameter value is greater than a second preset trend threshold and the seasonal intensity parameter is greater than a second seasonal threshold, the seasonality level of the traffic input data is determined to be strong. In other cases, the seasonality level of the traffic input data is determined to be strong. For example, the first trend parameter threshold can be 0.001, and the first seasonal parameter threshold can be 0.01. The second trend parameter threshold can be 0.01, and the first seasonal parameter threshold can be 1. That is, when the trend parameter value < 0.001 and the seasonal intensity parameter < 0.01, the seasonality level of the traffic input data is determined to be weak. When the trend parameter value > 0.01 and the seasonal intensity parameter > 0.01, the seasonality level of the traffic input data is determined to be strong.

[0076] The aggregation period refers to the time span during which traffic data from a certain period is merged into a single data point. Different seasonality levels correspond to different aggregation periods. After obtaining the seasonality level, the aggregation period can be determined based on it. Traffic input data from the previous period is then aggregated according to the aggregation period to obtain the target traffic data. For example, for traffic input data with a strong seasonality level, the aggregation period can be determined to be one day. For traffic input data with a weak seasonality level, the aggregation period can be determined to be one week. For traffic input data with a very strong seasonality level, no data aggregation is performed, i.e., the aggregation period is determined to be 0. Further, the aggregated traffic input data is then used as the target traffic data for the previous period.

[0077] By dynamically adjusting the aggregation period based on the seasonality of the traffic input data and aggregating the traffic input data of the previous period according to the aggregation period, the computational load of the system can be reduced without affecting the accuracy of the flow restriction threshold predicted by the traffic prediction model.

[0078] The technical solution of this embodiment assesses the rate limiting thresholds of each transaction service interface in the current period based on the rate limiting thresholds and interface traffic data of each interface in the current period, obtaining a rate limiting assessment result. The rate limiting assessment result is either "pass" or "fail". When the rate limiting assessment result is "pass", the target traffic data of the previous period is determined as the traffic input data of the previous period. When the rate limiting assessment result is "fail", the traffic input data of the previous period is optimized based on the parameter values ​​of the model parameters of the traffic prediction model and the assessment result to obtain the target traffic data of the previous period. This technical solution, by periodically evaluating interface services that exceed the recommended threshold, can continuously improve the accuracy of the traffic prediction data output by the rate limiting prediction model, further improving the accuracy of rate limiting threshold prediction, avoiding false rate limiting or no rate limiting events, and improving user experience.

[0079] Figure 4 This is a schematic diagram of a current limiting threshold prediction device provided in an embodiment of the present invention. This device is suitable for executing the current limiting threshold prediction method provided in this embodiment of the present invention. Figure 4 As shown, the device may specifically include:

[0080] The data acquisition module 401 is used to acquire interface traffic data of each transaction service interface according to a preset period through each pre-set transaction service interface.

[0081] The data processing module 402 is used to process the traffic data of each interface according to the predetermined target traffic data of the previous period, the traffic data of each interface in the current period, and the interface type of each transaction service interface for each period, if the current period is not the initial period, to obtain the traffic input data of the current period; wherein, the interface type is a core interface or a non-core interface.

[0082] The data prediction module 403 is used to input the traffic input data into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model.

[0083] The threshold determination module 404 is used to determine the rate limiting threshold of each transaction service interface based on the traffic prediction data of the next period and each interface type, and to limit the rate of each transaction service interface in the next period according to each rate limiting threshold.

[0084] Optionally, the interface traffic data includes time information, traffic information, and call information; the data processing module 402 is specifically used to: clean the interface traffic data according to the time information of each interface traffic data to obtain candidate interface traffic data;

[0085] Traffic data for non-core interfaces is filtered out from all candidate interface traffic data, and the traffic data of each non-core interface is aggregated to obtain aggregated traffic data for each non-core interface.

[0086] The traffic input data is obtained based on the target traffic data of the previous period, the aggregated traffic data of each non-core interface, and the candidate interface traffic data of each core interface.

[0087] Optionally, the data processing module 402 is also used to: for the traffic data of each non-core interface, obtain the non-core interface sub-data in each preset time period from the traffic data of the current non-core interface;

[0088] Determine the aggregated data for each non-core interface sub-data;

[0089] The aggregated traffic data of each non-core interface is obtained by updating the sub-data of each non-core interface based on the aggregated data.

[0090] Optionally, the threshold determination module 404 is specifically used to: calculate the recommended flow limiting threshold for each transaction service interface based on the flow prediction data for the next period;

[0091] For each transaction service interface, if the interface type of the current transaction service interface is a core interface, then the rate limiting threshold of the current transaction service interface is determined to be the recommended rate limiting threshold.

[0092] If the current service interface is a non-core interface, the rate limiting threshold of the current transaction service interface is determined based on the traffic information of the current interface traffic data; wherein, the traffic information includes the concurrency of the transaction service interface.

[0093] Optionally, the data processing module 402 is further configured to: perform a rate limiting assessment on the rate limiting threshold of each transaction service interface in the current period based on the rate limiting threshold and interface traffic data of each transaction service interface in the current period, and obtain a rate limiting assessment result; wherein the rate limiting assessment result is either pass or fail;

[0094] When the flow restriction assessment result is passed, the target flow data of the previous cycle is determined as the flow input data of the previous cycle;

[0095] When the flow restriction assessment result is unsuccessful, the flow input data of the previous period is optimized based on the parameter values ​​of the model parameters of the flow prediction model and the assessment result to obtain the target flow data of the previous period.

[0096] Optionally, the data processing module 402 is further configured to: determine the seasonality level of the traffic input data of the previous period based on the trend parameter value, the seasonal parameter value, the preset trend parameter threshold, and the preset seasonal parameter threshold;

[0097] The aggregation period for the traffic input data of the previous period is determined based on the seasonality level.

[0098] Based on the aggregation period, the traffic input data of the previous period is aggregated to obtain the target traffic data.

[0099] The current limiting threshold prediction device provided in this embodiment of the invention can execute the current limiting threshold prediction method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution. Content not described in detail in this embodiment can be referred to the description in any method embodiment of the invention.

[0100] This invention also provides a computer program product.

[0101] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer program products, which may include one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be an application-specific or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0102] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, with reference to... Figure 5 , Figure 5 The electronic device 12 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this application. Figure 5 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0103] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0104] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0105] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0106] A program / utility 40 having a set (at least one) of program modules 46 may be stored, for example, in memory 28. Such program modules 46 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 46 typically perform the functions and / or methods described in the embodiments of this application.

[0107] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with electronic device 12, and / or with any device that enables electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0108] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing a rate limiting threshold prediction method provided in this embodiment of the invention: It acquires interface traffic data of each transaction service interface according to a preset period through pre-defined transaction service interfaces; for each period, if the current period is not the initial period, it processes the interface traffic data according to the predetermined target traffic data of the previous period, the interface traffic data of the current period, and the interface type of each transaction service interface to obtain the traffic input data of the current period; wherein the interface type is a core interface or a non-core interface; it inputs the traffic input data into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model; it determines the rate limiting threshold of each transaction service interface based on the traffic prediction data of the next period and the interface type, and applies rate limiting to each transaction service interface in the next period according to the rate limiting threshold.

[0109] This invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements a rate limiting threshold prediction method as provided in all embodiments of this invention: acquiring interface traffic data for each transaction service interface according to a preset period; for each period, if the current period is not the initial period, processing the interface traffic data based on the predetermined target traffic data of the previous period, the interface traffic data of the current period, and the interface type of each transaction service interface to obtain the traffic input data for the current period; wherein the interface type is a core interface or a non-core interface; inputting the traffic input data into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model; determining the rate limiting threshold for each transaction service interface based on the traffic prediction data for the next period and the interface type, and rate limiting the transaction service interfaces in the next period according to the rate limiting threshold. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electronic device, apparatus, or device that is electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an electronic device, apparatus, or device that executes instructions.

[0110] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in conjunction with an electronic device, apparatus, or device that executes instructions.

[0111] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0112] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0113] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for predicting a current limiting threshold, characterized in that, The method includes: The interface traffic data of each transaction service interface is obtained according to a preset period through the pre-defined transaction service interfaces. For each period, if the current period is not the initial period, the traffic data of each interface is processed according to the predetermined target traffic data of the previous period, the traffic data of each interface in the current period, and the interface type of each transaction service interface to obtain the traffic input data of the current period; wherein, the interface type is a core interface or a non-core interface. The traffic input data is input into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model. Based on the traffic prediction data for the next period and each interface type, the rate limiting threshold for each transaction service interface is determined, and rate limiting is applied to each transaction service interface in the next period according to each rate limiting threshold. The interface traffic data includes time information, traffic information, and call information; based on the pre-acquired target traffic data of the previous period, the interface traffic data of the current period, and the interface type of each transaction service interface, the interface traffic data is processed to obtain the traffic input data of the current period, including: Based on the time information of each interface traffic data, the traffic data of each interface is cleaned to obtain the traffic data of each candidate interface. Traffic data for non-core interfaces is filtered out from all candidate interface traffic data, and the traffic data of each non-core interface is aggregated to obtain aggregated traffic data for each non-core interface. The traffic input data is obtained based on the target traffic data of the previous period, the aggregated traffic data of each non-core interface, and the candidate interface traffic data of each core interface.

2. The method according to claim 1, characterized in that, The traffic data of each non-core interface is aggregated to obtain the aggregated traffic data of each non-core interface, including: For traffic data of each non-core interface, obtain the non-core interface sub-data in each preset time period from the current traffic data of the non-core interface; Determine the aggregated data for each non-core interface sub-data; The aggregated traffic data of each non-core interface is obtained by updating the sub-data of each non-core interface based on the aggregated data.

3. The method according to claim 1, characterized in that, Based on the traffic prediction data for the next cycle and the interface types, the rate limiting thresholds for each transaction service interface are determined, including: The recommended flow control threshold for each transaction service interface is calculated based on the traffic prediction data for the next cycle. For each transaction service interface, if the interface type of the current transaction service interface is a core interface, then the rate limiting threshold of the current transaction service interface is determined to be the recommended rate limiting threshold. If the current transaction service interface is a non-core interface, the rate limiting threshold of the current transaction service interface is determined based on the traffic information of the current interface traffic data; wherein, the traffic information includes the concurrency of the transaction service interface.

4. The method according to claim 1, characterized in that, Before processing the interface traffic data based on the pre-acquired target traffic data of the previous period, the interface traffic data of the current period, and the interface type of each transaction service interface, the method further includes: Based on the rate limiting thresholds and interface traffic data of each transaction service interface in the current period, a rate limiting assessment is performed on the rate limiting thresholds of each transaction service interface in the current period to obtain a rate limiting assessment result; wherein, the rate limiting assessment result is either pass or fail. When the flow restriction assessment result is passed, the target flow data of the previous cycle is determined as the flow input data of the previous cycle; When the flow restriction assessment result is unsuccessful, the flow input data of the previous period is optimized based on the parameter values ​​of the model parameters of the flow prediction model and the assessment result to obtain the target flow data of the previous period.

5. The method according to claim 4, characterized in that, The model parameters include trend parameters and seasonality parameters. Based on the parameter values ​​of the traffic prediction model and the evaluation results, the traffic input data of the previous period is optimized to obtain the target traffic data of the previous period, including: The seasonality level of the traffic input data in the previous period is determined based on trend parameter values, seasonal parameter values, preset trend parameter thresholds, and preset seasonal parameter thresholds. The aggregation period for the traffic input data of the previous period is determined based on the seasonality level. Based on the aggregation period, the traffic input data of the previous period is aggregated to obtain the target traffic data.

6. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements a current limiting threshold prediction method according to any one of claims 1-5.

7. A current limiting threshold prediction device, characterized in that, include: The data acquisition module is used to acquire interface traffic data of each transaction service interface according to a preset period through each pre-defined transaction service interface. The data processing module is used to process the traffic data of each interface according to the predetermined target traffic data of the previous period, the traffic data of each interface in the current period, and the interface type of each transaction service interface for each period, if the current period is not the initial period, to obtain the traffic input data of the current period; wherein, the interface type is a core interface or a non-core interface. The data prediction module is used to input the traffic input data into a pre-trained traffic prediction model to obtain the traffic prediction data for the next period output by the traffic prediction model. The threshold determination module is used to determine the rate limiting threshold of each transaction service interface based on the traffic prediction data of the next period and each interface type, and to limit the rate of each transaction service interface in the next period according to each rate limiting threshold. The interface traffic data includes time information, traffic information, and call information; the data processing module is specifically used to: clean the interface traffic data according to the time information of each interface traffic data to obtain candidate interface traffic data; Traffic data for non-core interfaces is filtered out from all candidate interface traffic data, and the traffic data of each non-core interface is aggregated to obtain aggregated traffic data for each non-core interface. The traffic input data is obtained based on the target traffic data of the previous period, the aggregated traffic data of each non-core interface, and the candidate interface traffic data of each core interface.

8. 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 program, it implements a current limiting threshold prediction method as described in any one of claims 1 to 5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements a current limiting threshold prediction method as described in any one of claims 1 to 5.

Images