Scheduling method and device for pressure measurement resources and storage medium

Abstract

The invention discloses a pressure measurement resource scheduling method and device and a storage medium. The method comprises the steps of obtaining a feature variable of a to-be-executed pressure measurement task in a current pressure measurement scene; determining an estimated resource occupation amount of the to-be-executed pressure measurement task according to the characteristic variable; determining an execution time period of the pressure measurement task through task execution information of the pressure measurement task and an estimated resource occupation amount; and scheduling the pressure measurement resources corresponding to the pressure measurement task according to the execution time period. According to the method, the resource usage amount at the future moment is obtained by evaluating the scene complexity and establishing the resource demand prediction model, and scene operation and resource allocation coordination are intelligently scheduled on the basis of the resource usage amount, so that the scene task arrangement complexity of a user is reduced, and the scene task on-time completion rate and the resource utilization rate are improved.

Description

Technical Field

[0001] This application relates to the field of stress testing technology, and in particular to a method, device and storage medium for scheduling stress testing resources. Background Technology

[0002] In traditional load testing, after the user configures the scenario and initiates the load testing task, whether it's executed immediately or on a schedule, the system only checks for available resources when the execution time arrives. If no resources are available at that point, the task will fail. Typically, the user needs to manually check the resource usage of the load testing machine and re-initiate the task. It's clear that this traditional process completely lacks scheduling capabilities.

[0003] After improvements, some systems introduced the concept of queues, placing tasks that were not scheduled for execution into a queue. A scheduled task automatically scans the resource pool for available resources, executing the task at the head of the queue as soon as a resource becomes available, until all tasks in the queue are completed. However, this can easily lead to resource contention in the queue, preventing user-initiated immediately executable tasks from being executed on time, and these tasks are also placed in the queue, creating a vicious cycle. Other systems introduced the concept of retries, continuously and automatically retrying tasks that were not scheduled for execution until they were completed. This is a relatively brute-force approach, and if not properly controlled, it can also lead to preemption.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device and storage medium for scheduling stress testing resources, which aims to solve the technical problem of uneven allocation of stress test machine resources when performing stress testing tasks.

[0006] To achieve the above objectives, this application proposes a method for scheduling stress testing resources, the method comprising:

[0007] Obtain the characteristic variables of the load testing task to be executed in the current load testing scenario;

[0008] Based on the aforementioned characteristic variables, the estimated resource consumption of the load testing task to be executed is determined.

[0009] The execution time period of the stress test task is determined by the task execution information of the stress test task and the estimated resource consumption.

[0010] Based on the execution time period, the load testing resources corresponding to the load testing task are scheduled.

[0011] In one embodiment, the step of determining the estimated resource consumption of the load testing task to be executed based on the feature variables includes:

[0012] The feature variables are input into the resource prediction model, which is constructed based on the gradient boosting decision tree algorithm and is used to calculate the estimated resource consumption of the stress test task.

[0013] The estimated resource consumption of the stress test task is calculated using the resource prediction model.

[0014] In one embodiment, before the step of calculating the estimated resource consumption of the load testing task using the resource prediction model, the method further includes:

[0015] Obtain historical load testing tasks and determine the actual resource usage and scenario feature tags of the historical load testing tasks;

[0016] Incremental training samples are generated based on the actual resource usage data and the scene feature labels;

[0017] The resource prediction model is iteratively trained using the incremental training samples, and the resource prediction model is obtained based on the training results of the iterative training.

[0018] In one embodiment, the step of determining the execution time period of the load testing task based on the task execution information of the load testing task and the estimated resource consumption includes:

[0019] Determine the target optimization strategy corresponding to the workload of the stress testing task, wherein the optimization parameters corresponding to the workload are obtained, and the target optimization algorithm is configured to generate the target optimization strategy through the optimization parameters, wherein the optimization parameters include population size, number of iterations and constraints.

[0020] A multi-objective function is generated based on the task execution information and the estimated resource consumption, and the multi-objective function is iteratively calculated using the objective optimization strategy.

[0021] The execution time period is obtained based on the iteration results.

[0022] In one embodiment, the step of generating a multi-objective function based on the task execution information and the estimated resource consumption, and iteratively calculating the multi-objective function using the objective optimization algorithm, includes:

[0023] Generate multiple scheduling schemes for the multi-objective function;

[0024] The target solution set is selected from the scheduling scheme using preset screening conditions, and the iteration calculation is terminated based on the generational optimization magnitude of the target solution set. The preset screening conditions include non-dominated sorting and crowding distance.

[0025] If the generational optimization magnitude is greater than the preset convergence threshold, the iterative calculation is terminated.

[0026] In one embodiment, after determining the execution time period of the load testing task based on the task execution information of the load testing task and the estimated resource consumption, the method further includes:

[0027] When a load testing task to be executed is received based on the execution time period, the resource saturation of the execution time period is determined by the estimated resource usage.

[0028] If the resources are determined to be saturated during the execution time period, recommended information on the available execution time period will be output.

[0029] In one embodiment, the step of scheduling the load testing resources corresponding to the load testing task according to the execution time period includes:

[0030] Generate resource scheduling instructions for the execution time period and monitor the execution status of the load testing tasks within the execution time period in real time. The execution status includes execution progress and resource occupancy status.

[0031] When the actual resource consumption deviates from the predicted value based on the execution status, the resource scheduling instruction is executed to schedule the stress test resources.

[0032] In one embodiment, the step of generating resource scheduling instructions for the execution time period and monitoring the execution status of the load testing task within the execution time period in real time further includes:

[0033] Identify resource preemption conflicts within the specified execution time period;

[0034] Locate the target load testing task corresponding to the resource preemption conflict event, and schedule the target load testing task based on task priority. The scheduling process includes implementing preemptive scheduling or queuing.

[0035] The resource preemption conflict events are fed back to the prediction model optimization mechanism.

[0036] In addition, to achieve the above objectives, this application also proposes a scheduling device for stress testing resources, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the stress testing resource scheduling method described above.

[0037] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the stress testing resource scheduling method described above.

[0038] The technical solution proposed in this application has at least the following technical effects:

[0039] This application's technical solution obtains the characteristic variables of the load testing task to be executed in the current load testing scenario; determines the estimated resource consumption of the task based on the characteristic variables; determines the execution time period of the load testing task based on the task execution information and estimated resource consumption; and schedules the load testing resources corresponding to the task based on the execution time period. By assessing scenario complexity and establishing a resource demand prediction model to obtain future resource usage, the application intelligently schedules scenario execution and coordinates resource allocation, thereby reducing the complexity of users in orchestrating scenario tasks and improving the on-time completion rate and resource utilization of scenario tasks. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 A flowchart illustrating the scheduling method for stress testing resources in this application (Example 1).

[0043] Figure 2 This is a schematic diagram of the hardware operating environment involved in the scheduling method of stress testing resources in this application embodiment.

[0044] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0045] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0046] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0047] The main solution of this application embodiment is: to obtain the characteristic variables of the load testing task to be executed in the current load testing scenario; to determine the estimated resource consumption of the load testing task to be executed based on the characteristic variables; to determine the execution time period of the load testing task through the task execution information and the estimated resource consumption of the load testing task; and to schedule the load testing resources corresponding to the load testing task according to the execution time period.

[0048] Due to the highly concentrated timing of user task initiation and the lack of intelligent control mechanisms in resource allocation within the existing pressure machine cluster, resource overload during peak hours leads to task congestion and a sharp drop in completion rate, while idle resources during off-peak hours result in waste. At the same time, users' blind grabbing of resources further exacerbates the low efficiency of resource utilization, resulting in a continuous imbalance between resource supply and task demand in the temporal and spatial dimensions. Therefore, it is urgent to achieve a coordinated improvement in task completion rate and resource utilization.

[0049] This application provides a solution that obtains future resource usage by assessing scenario complexity and establishing a resource demand prediction model. Based on this, the system intelligently schedules scenario operation and coordinates resource allocation, thereby reducing the complexity of users in orchestrating scenario tasks and improving the on-time completion rate and resource utilization of scenario tasks.

[0050] Based on this, embodiments of this application provide a method for scheduling stress testing resources, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the stress testing resource scheduling method of this application. In this embodiment, the stress testing resource scheduling method includes steps S10 to S50:

[0051] Step S10: Obtain the feature variables of the load testing task to be executed in the current load testing scenario;

[0052] Step S20: Determine the estimated resource consumption of the load testing task to be executed based on the feature variables;

[0053] Step S30: Determine the execution time period of the load testing task based on the task execution information of the load testing task and the estimated resource consumption;

[0054] Step S40: Schedule the load testing resources corresponding to the load testing task according to the execution time period.

[0055] In this embodiment, the load testing tasks to be executed in the current load testing scenario are obtained. The load testing scenario refers to the execution scenario of different types of load testing tasks. Specifically, the load testing scenario is related to the load testing type of the load testing task to be executed, and includes one or more.

[0056] The load testing tasks to be executed based on the aforementioned load testing scenarios are stress detection tasks initiated by users in various load testing scenarios according to the current load testing requirements. Their initiation time and specific task information are uncontrollable; therefore, the number of load testing tasks to be executed is one or more, initiated by users at irregular intervals based on load testing needs. To address this, considering the unordered nature of the load testing tasks to be executed, a sequence of tasks to be executed is created in each load testing scenario to arrange the tasks.

[0057] Furthermore, the task execution information of each load testing task is registered in the task sequence to be executed. Therefore, the task sequence to be executed contains one or more load testing tasks, and each load testing task has corresponding task execution information based on its specific test content. The task execution information is the scheduled start time and expected duration of the load testing task.

[0058] Specifically, the task execution information of the load testing task is related to the test plan of the load testing task. This task execution information is only used to characterize the execution information of the load testing task and cannot be used to characterize the specific load testing plan. In the sequence of tasks to be executed, each registered load testing task is a task to be executed. In another embodiment, it also includes a sequence of executed tasks. The sequence of tasks to be executed and the sequence of executed tasks can be used to register information about all load testing tasks currently being performed. For example, for a sequence containing 10 load testing tasks, the predetermined start time and expected duration of each load testing task are collected.

[0059] The sequence of tasks to be executed mentioned above is actually a part of the initial scheduling sequence. The initial scheduling sequence is a task sequence formed based on the load testing task scheduling process. Specifically, the lack of a preset priority management mechanism in the load testing task scheduling process leads to resource contention between user-initiated immediate execution tasks and queued tasks, resulting in a vicious cycle of task backlog and execution failure.

[0060] Therefore, this embodiment proposes that before obtaining the task execution information of each load testing task in the task sequence to be executed, a preset task priority rule is obtained and an initial scheduling sequence is created based on this rule. The initial scheduling sequence is characterized by an executed task sequence and a task sequence to be executed. Specifically, when a load testing task initiated by a user is received, the load testing tasks are prioritized according to the preset task priority rule, and the load testing tasks are inserted into the task sequence to be executed in the initial scheduling sequence based on the priority ranking. The initial scheduling sequence includes an executed task sequence and a task sequence to be executed. The load testing tasks arranged in the executed task sequence are the load testing tasks that have been completed.

[0061] The preset task priority rules can be configured based on task deadlines, task size, or user level. For example, urgent tasks or tasks assigned by high-privilege users can be set as priority. The creation of the initial scheduling sequence is achieved by separating the task status into executed and pending task sequences. Specifically, the pending task sequence uses a doubly linked list structure to store task nodes to support dynamic insertion. When a user-initiated load testing task is inserted into the pending sequence, its insertion logic includes a conflict detection module to identify resource overlap among multiple tasks within the same time period. Based on the identified resource overlap, the task time window is recorded using a hash table.

[0062] Specifically, the preset task priority rules generate a priority score for each load testing task using a weighted calculation model. The score determines the sorting position of the load testing task in the execution sequence. When a user initiates a new load testing task, the load testing task is given a priority score according to the preset task priority rules, and then inserted into a specific position in the execution sequence based on the score, such as inserting it at the head of the queue if the score is higher than a threshold.

[0063] Furthermore, the executed task sequence records the historical task execution status through a log database, while the pending task sequence uses a memory cache for real-time access. Specifically, the recorded historical task execution status distinguishes between executed historical load testing tasks and pending load testing tasks, avoiding data interference between new, unexecuted load testing tasks and completed load testing tasks. Simultaneously, the priority scoring model dynamically adjusts the order of load testing tasks in the pending queue based on the real-time received priority scoring results, ensuring that high-priority load testing tasks have priority access to idle resources. For example, when the time windows of two load testing tasks overlap, the system automatically delays the load testing task with the lower priority score to an idle period based on the priority score, thereby eliminating resource contention.

[0064] Obtain preset task priority rules and create an initial scheduling sequence based on these rules. For example, priority rules can be formulated based on factors such as task type, importance, and urgency, placing high-priority tasks at the top of the sequence. Specifically, load testing tasks for critical business systems can be set to the highest priority, while load testing tasks for non-core systems can be set to lower priority.

[0065] The system receives load testing tasks initiated by users and inserts them into the initial scheduling sequence of tasks to be executed. This initial scheduling sequence includes both executed and pending task sequences. Furthermore, the system can insert newly received load testing tasks into appropriate positions within the pending task sequence based on their priority. For example, a high-priority task can be inserted at the beginning of the pending sequence, while a low-priority task can be inserted at the end.

[0066] Through the above technical solution, this application can achieve priority management and dynamic scheduling of load testing tasks. Creating an initial scheduling sequence by pre-setting task priority rules ensures that important tasks are executed first. Dynamically inserting new tasks into the execution sequence flexibly addresses new load testing needs. This method improves the utilization efficiency of load testing resources, avoids long waiting times for high-priority tasks, and also rationally arranges the execution order of low-priority tasks.

[0067] Furthermore, the estimated resource consumption of each load testing task is calculated using a resource prediction model. Specifically, feature variables are extracted from each load testing task and input as input parameters to the resource prediction model. These feature variables include, but are not limited to, information related to the load testing task such as task type, number of concurrent users, and transaction complexity. The resource prediction model outputs data representing the estimated resource consumption of resources such as CPU, memory, and network bandwidth based on the calculation of these feature variables. In particular, when calculating the estimated resource consumption of the load testing task using the resource prediction model, the feature variables are input into the resource prediction model, which is constructed based on a gradient boosting decision tree algorithm and used to calculate the estimated resource consumption of the load testing task.

[0068] The estimated resource consumption of the stress test task is calculated using the resource prediction model.

[0069] In this embodiment, when determining the estimated resource usage of each stress test task through the resource prediction model, there may be a problem of prediction result deviation due to incomplete selection of feature variables or unclear model input parameters, which in turn affects the accuracy of subsequent resource scheduling.

[0070] Therefore, in this embodiment, a further method is proposed to extract feature variables for each load testing task, input these feature variables into a resource prediction model, and output the estimated resource consumption of each load testing task through model calculation. The feature variables include the scenario complexity index corresponding to the load testing task, historical resource usage data, and current task configuration parameters. The scenario complexity index includes interface call level, data interaction volume, or transaction complexity; the historical resource usage data includes peak CPU utilization, average memory consumption, or network bandwidth fluctuation range; and the current task configuration parameters include specific task information such as the number of concurrent users, load testing script type, or data-driven method.

[0071] Furthermore, the resource prediction model is constructed based on the gradient boosting decision tree algorithm and is generated by training with the feature variables of historical stress testing tasks and actual resource usage data. The model output is a multi-dimensional predicted value of resource occupancy.

[0072] Specifically, in the process of predicting resource consumption, feature variables are extracted from the load testing task. The scenario complexity index in the feature variables is obtained by parsing the load testing script to obtain the interface call level and data interaction volume. The number of concurrent users and the load testing script type are extracted from the configuration information of the load testing task to form the structured feature variable set.

[0073] Based on the extracted feature variables described above, these variables are input into a pre-trained resource prediction model. The model calculates resource usage based on the non-linear relationships between the parameters represented by these feature variables. For example, when the interface call level increases to 5 levels, the resource prediction model automatically adjusts the predicted memory usage, increasing it from 2.5GB to 3.2GB. Thus, the resource prediction model can dynamically reflect the impact of different feature variables on resource usage, outputting more accurate prediction results. This provides reliable input for subsequent multi-objective function construction and resource scheduling, avoiding resource allocation conflicts or task execution delays caused by prediction bias.

[0074] In another preferred embodiment, when determining the estimated resource consumption of each load testing task using the resource prediction model, the extracted feature variables for each load testing task include the type of the load testing task, the number of concurrent users, the request frequency, and the data size. For example, for a web application load testing task, the feature variables may include the HTTP request type (GET / POST), the number of requests per second, and the request data packet size.

[0075] Furthermore, the extracted feature variables are input into the resource prediction model. The resource prediction model can be constructed using machine learning algorithms such as random forests or neural networks. The input layer of the model corresponds to each feature variable, and the output layer corresponds to the estimated resource indicators such as CPU utilization, memory usage, and network bandwidth. Thus, through the calculation of the resource prediction model, the estimated resource usage for each load testing task is output. The prediction result can be a vector containing predicted resource usage values ​​for multiple dimensions such as CPU, memory, and network; specifically, it can be derived based on the specific testing process of the executed load testing task.

[0076] Based on this, this application can accurately predict resource requirements based on the characteristics of load testing tasks, providing a reliable basis for subsequent task scheduling. Compared with fixed allocation or empirical estimation, this model-based prediction method can better adapt to different types and scales of load testing tasks, improving the accuracy and flexibility of resource allocation. At the same time, the multi-dimensional characteristics of the prediction results also create conditions for fine-grained resource scheduling.

[0077] Furthermore, the calculation of the estimated resource usage shown above is essentially based on a pre-trained resource prediction model. Considering the accuracy of resource usage estimation, the training of the resource prediction model is real-time. It can be understood that the resource prediction model can be trained in real-time in the background based on historical load testing tasks, adjusting its configuration parameters, and can perform resource usage estimation for the currently scheduled load testing task while running in the foreground. That is, before the step of calculating the estimated resource usage of the load testing task using the resource prediction model, the following steps are also included:

[0078] Obtain historical load testing tasks and determine the actual resource usage and scenario feature tags of the historical load testing tasks;

[0079] Incremental training samples are generated based on the actual resource usage data and the scene feature labels;

[0080] The resource prediction model is iteratively trained using the incremental training samples, and the resource prediction model is obtained based on the training results of the iterative training.

[0081] In the above, before inputting the feature variables into the resource prediction model to estimate resource occupancy, the resource prediction model is obtained through incremental training. The training of this resource prediction model is based on an existing data model and relies on the initial dataset. This makes it unable to dynamically adapt to the complex changes in newly added load testing scenarios, leading to accumulated resource prediction biases and affecting the accuracy of subsequent scheduling.

[0082] This embodiment further proposes a process for training a resource prediction model by collecting actual resource usage data from each historical load testing task. Specifically, by collecting actual resource usage data from each historical load testing task and scene feature labels corresponding to each load testing task, incremental training samples are generated from the actual resource usage data and scene feature labels to iteratively train the resource prediction model in order to obtain a more accurate resource prediction model.

[0083] In the actual training process, the scene feature labels represent at least one of the following: the load testing task type, the number of concurrent users, and the depth of the interface call chain in the historical load testing tasks. The incremental training samples generated based on the actual resource usage data and the scene feature labels can be represented as resource usage records in historical data associated with timestamps and task identifiers.

[0084] During the iterative training of the resource prediction model, the model parameters are dynamically adjusted based on the error backpropagation of incremental samples, while historical training weights are retained to balance the risk of overfitting. Specifically, the actual resource usage data of the historical load testing tasks is extracted from the monitoring logs of the distributed load testing machine, and the scene feature labels are automatically labeled based on the metadata of the load testing scripts. Therefore, the incremental training samples are generated by extracting the actual resource usage data and scene feature labels at preset intervals. For example, training sample generation is triggered after every ten load testing tasks are completed, and the generated training samples are used to train the current resource prediction model.

[0085] Specifically, the resource prediction model employs a neural network structure and incorporates an early stopping mechanism during training. Training terminates when the loss function on the validation set decreases by less than one percent for three consecutive training epochs. Through incremental training, the resource prediction model learns resource consumption patterns under newly added scene feature labels, such as the resource usage differences between high-concurrency short-duration tasks and low-concurrency long-duration tasks, thereby improving the accuracy of estimated resource usage.

[0086] In another preferred embodiment, the pre-training based on the resource prediction model is implemented as follows: The actual resource usage data of each load testing task in the historical load testing tasks is collected, and the scene feature labels corresponding to the actual resource usage data are determined. For example, for a web application load testing task, resource usage data such as CPU utilization, memory usage, and network bandwidth are collected, while scene features such as the number of concurrent users, request types, and database query complexity of the task are recorded.

[0087] The actual resource usage data and scene feature labels are used to generate incremental training samples. Specifically, the collected resource usage data and corresponding scene feature labels are combined into training sample pairs. Each training sample pair includes input features (scene features) and output labels (actual resource usage).

[0088] The resource prediction model is iteratively trained using the incremental training samples to obtain the final model. Further, machine learning algorithms, such as random forests or neural networks, are used to train the resource prediction model based on the incremental training samples. The input parameters of the resource prediction model are scene features, and the output parameter is the predicted resource usage. As new training samples are continuously added, the model continuously optimizes its prediction accuracy through iterative training.

[0089] Through iterative training of the resource prediction model, it can be dynamically updated and optimized. Based on this, the resource prediction model can adapt to different types of load testing tasks and changing system environments, improving the accuracy of resource usage prediction. Furthermore, by continuously collecting training sample data from historical load testing tasks and iteratively training the resource prediction model based on new training samples, the predictive ability of resource demand can be continuously improved, thereby supporting more accurate load testing resource scheduling decisions.

[0090] Subsequently, based on the calculated estimated resource usage and characteristic variables corresponding to the load testing resources, the process of determining the execution time period of the load testing task is as follows: Specifically, the step of determining the execution time period of the load testing task using the task execution information of the load testing task and the estimated resource usage includes:

[0091] Determine the target optimization strategy corresponding to the workload of the stress testing task, wherein the optimization parameters corresponding to the workload are obtained, and the target optimization algorithm is configured to generate the target optimization strategy through the optimization parameters, wherein the optimization parameters include population size, number of iterations and constraints.

[0092] A multi-objective function is generated based on the task execution information and the estimated resource consumption, and the multi-objective function is iteratively calculated using the objective optimization strategy.

[0093] The execution time period is obtained based on the iteration results.

[0094] In this embodiment, the target optimization strategy addresses the technical problem that during iterative calculation, differences in task volume may lead to insufficient optimization efficiency or unreasonable resource allocation, making it unable to adapt to the dynamic needs of tasks of different scales and affecting the accuracy of execution time periods and scheduling effects. Specifically, optimization parameters are obtained based on the task volume of the load testing task, and a target optimization algorithm is configured using these parameters to obtain the target optimization strategy. Specifically, the target optimization strategy is essentially a target optimization algorithm with optimization parameters, used to iteratively calculate a multi-objective function to obtain the execution time period of the load testing task. The optimization parameters include population size, number of iterations, and constraints; and the target optimization strategy is used to iteratively calculate the multi-objective function, outputting the iteration results.

[0095] In the above definitions, the population size is dynamically adjusted based on historical data or real-time statistical results of the load testing task; the larger the task volume, the higher the corresponding population size setting. The number of iterations is set based on the balance between task complexity and resource allocation accuracy; the number of iterations increases synchronously as the task volume increases. The constraints are generated based on the total resources of the stress testing machine and the task execution time window, including the resource usage limit and the task deadline. Specifically, the association configuration between the population size and the number of iterations is implemented through a preset mapping table or calculation model, and the constraints are dynamically corrected based on real-time data output by the resource pool monitoring module.

[0096] When the workload of the stress testing task is under high load, a larger population size parameter needs to be automatically matched to increase the exploration range of the solution space, while extending the iteration number parameter to ensure that the algorithm converges to the optimal solution. The constraints are updated through real-time load data of the stress test resource pool. For example, when the resource occupancy rate reaches a preset threshold, the constraint adjustment is triggered to limit the resource request amount of subsequent tasks.

[0097] As shown above, based on the task execution information of each load testing task and the calculated estimated resource consumption and characteristic variables of each load testing task, a multi-objective function is constructed. This multi-objective function represents a data object that comprehensively considers multiple optimization objectives such as task execution time and resource utilization, transforming the resource scheduling problem into a mathematical optimization problem. Specifically, the multi-objective function consists of a first objective function generated based on the task execution information and a second objective function generated based on the estimated resource consumption. The specific generation process of the multi-objective function is as follows:

[0098] 1) Generate the first objective function based on the task execution information of the current load testing task:

[0099] The first objective function is:

[0100]

[0101] In the above formula, n load testing tasks are defined as follows: 1, 2, 3, ..., n; the load testing duration extracted from the task execution information of each load testing task is defined as t1, t2, ..., tn. m The scheduled start time for a certain load testing task is defined as T. p This parameter is derived from the task issuance time carried in the task execution information; the execution time period of a certain load testing task is defined as T. e This parameter is the quantity that needs to be optimized and solved. Therefore, based on the first objective function, it is also defined as the sum of the difference between the execution time period and the planned start time obtained from the task execution information in the stress test task.

[0102] 2) Generate a second objective function based on the task execution information of the current load testing task:

[0103] The second objective function is:

[0104]

[0105] The estimated resource usage of the load testing task is defined as S; the future time period is divided into minutes, defined as m minutes; the checkSourceUse method is used to determine whether a load testing task will be executed within a certain minute. If it will be executed, its resource usage needs to be accumulated. The total resource usage within a certain minute is defined as:

[0106]

[0107] 3) The multi-objective function composed of the first and second objective functions described above is:

[0108]

[0109] As shown above, by selecting a suitable objective optimization algorithm to iterate the multi-objective function, the task arrangement that optimizes the two objectives is calculated, and then the task execution time obtained from the calculation results is used to schedule the load testing resources for multiple load testing tasks.

[0110] The target optimization strategy is generated based on the configuration parameters of the target optimization algorithm described above, and the multi-objective function is iteratively calculated using the target optimization strategy. Specifically, the step of generating a multi-objective function based on the task execution information and the estimated resource consumption, and iteratively calculating the multi-objective function using the target optimization algorithm, includes:

[0111] Generate multiple scheduling schemes for the multi-objective function;

[0112] The target solution set is selected from the scheduling scheme using preset screening conditions, and the iteration calculation is terminated based on the generational optimization magnitude of the target solution set. The preset screening conditions include non-dominated sorting and crowding distance.

[0113] If the generational optimization magnitude is greater than the preset convergence threshold, the iterative calculation is terminated.

[0114] When using a multi-objective optimization algorithm to iteratively calculate a multi-objective function, as defined above, there are problems such as a single initial solution set generation method and insufficient screening conditions. This leads to the optimization process easily getting trapped in local optima, failing to effectively balance solution diversity and convergence speed, and affecting the generation efficiency and quality of the scheduling scheme. Therefore, in this embodiment, multiple scheduling schemes generated from the multi-objective function are used as the initial solution set. Preset screening conditions are used to select the target solution set from the initial solution set, and the generational optimization magnitude of the target solution set is extracted. The success of each iterative calculation process is judged based on the generational optimization magnitude, thereby obtaining the final iterative result.

[0115] When generating multiple scheduling schemes for the multi-objective function as the initial solution set, random initialization or heuristic initialization based on historical scheduling data can be used to ensure the diversity of the initial solution set. Based on the selection of the initial solution set, the non-dominated sorting in the preset selection criteria is applied to hierarchically sort the initial solution set according to the Pareto front of the objective function. The crowding distance in the preset selection criteria measures the distribution density between solutions in the same layer, prioritizing the retention of sparsely distributed solutions to maintain diversity. The generational optimization magnitude is the iteration parameter obtained for each selected target solution set, used to characterize the current iteration process, i.e., quantifying the optimization progress by calculating the fitness difference or solution distribution change in adjacent iterations. The preset convergence threshold is dynamically adjusted according to the resource constraints and time limitations of the actual scheduling scenario, for example, set to a fitness change of less than 5% or a solution distribution change of less than 10%.

[0116] Specifically, during the iteration process, the initial solution set is generated randomly or based on historical data to create multiple possible scheduling schemes, covering different combinations of resource allocation and task execution order. The non-dominated sorting divides the solution set into multiple non-dominated levels, where solutions within each level are not mutually dominant across multiple objective functions, ensuring that the selected solutions are Pareto optimal. The crowding distance is calculated by summing the adjacent distances of solutions in the same level across all objective dimensions, prioritizing solutions with high crowding to avoid excessive clustering of solutions. Finally, the generational optimization magnitude is used to determine whether the optimization is stabilizing by comparing the average fitness or the change in the solution set coverage between the current and previous generations. When the generational optimization magnitude of multiple consecutive iterations is lower than a preset convergence threshold, the calculation terminates and the current optimal solution set is output. Therefore, by dynamically adjusting the selection conditions and convergence judgment mechanism, convergence can be accelerated while ensuring solution set diversity, improving the quality and generation efficiency of the scheduling scheme.

[0117] In the specific iterative process, multiple scheduling schemes with multi-objective functions are generated as the initial solution set. For example, 100 different task scheduling orders can be randomly generated as the initial solution set. The target solution set is then selected from the initial solution set using preset screening criteria. These criteria include non-dominated sorting and congestion distance. Specifically, the initial solution set is first non-dominated sorted, dividing it into different levels. Then, the congestion distance for each solution is calculated, and solutions with larger congestion distances are retained. The target solution set is obtained through these two steps. The generational optimization magnitude of the target solution set is then extracted. The average change in the objective function value between the current and previous generations of target solution sets can be calculated as the generational optimization magnitude.

[0118] The generational optimization magnitude is compared with a preset convergence threshold. For example, the preset convergence threshold can be set to 0.1%. If the generational optimization magnitude is greater than 0.1%, the iterative calculation continues. If it is less than or equal to 0.1%, the iterative calculation terminates. The above steps are repeated until the generational optimization magnitude of the selected target solution set is greater than the preset convergence threshold, at which point the iterative calculation terminates. The final output target solution set is the iterative result of the multi-objective function.

[0119] This iterative calculation effectively avoids getting trapped in local optima, improving the convergence efficiency and solution quality of multi-objective optimization algorithms. Furthermore, by setting reasonable termination conditions, it avoids wasting computational resources due to excessive iteration. This iterative optimization method can more quickly and accurately determine the execution time of load testing tasks, providing a reliable basis for subsequent resource scheduling.

[0120] As shown above, each generation of the population represents a resource allocation scheme, and a set of candidate solutions that meet the constraints is selected through non-dominated sorting. After multiple iterations, the algorithm outputs a scheduling scheme that maximizes resource utilization and optimizes task completion rate, ultimately generating the execution time period for the load testing task. This process effectively matches task requirements of different scales through a parameter adaptive mechanism, avoiding local optima or wasted computational resources caused by fixed parameters.

[0121] Specifically, a pre-configured objective optimization algorithm is used to iteratively calculate the multi-objective function, and the iterative results are output. Specifically, the Non-Dominated Sorting Genetic Algorithm (NSGA-II) can be used as the multi-objective optimization algorithm. An initial population is generated, and the individuals in the population are sorted using non-dominated sorting and crowding calculation. Then, offspring populations are generated through selection, crossover, and mutation operations. The parent and offspring populations are merged, and non-dominated sorting and crowding calculation are performed again to select superior individuals to form a new generation population. The above process is repeated until the maximum number of iterations is reached or the convergence condition is met. The final output non-dominated solution set is the iterative result, which includes the execution time period of the load testing task.

[0122] In this embodiment, the optimization algorithm parameters are adaptively configured according to the scale of the load testing task, improving optimization efficiency. Simultaneously, the multi-objective optimization algorithm, considering multiple objectives, yields a balanced scheduling scheme that satisfies both the need to maximize resource utilization and ensures on-time task completion. This intelligent scheduling method significantly improves the utilization efficiency of load testing resources and reduces the need for manual intervention.

[0123] Furthermore, considering that load testing tasks are initiated by users at irregular intervals and their execution time is uncertain, the execution time of newly initiated load testing tasks may overlap with the execution time period of load testing tasks to be executed as calculated iteratively. Therefore, after determining the execution time period of the load testing task using the task execution information of the load testing task and the estimated resource consumption, the method further includes:

[0124] When a load testing task to be executed is received based on the execution time period, the resource saturation of the execution time period is determined by the estimated resource usage.

[0125] If the resources are determined to be saturated during the execution time period, recommended information on the available execution time period will be output.

[0126] In this embodiment, when the execution time of a newly initiated load testing task overlaps with the currently calculated execution time period, the newly initiated load testing task may fail to execute because the execution time period is already allocated to a corresponding load testing task, occupying all the load testing resources within that execution time period. Therefore, based on the newly initiated load testing task, it is determined whether the load testing resources within the execution time period that overlaps with its execution time are saturated.

[0127] This determination of resource saturation is essentially based on whether there are execution time gaps among the load testing tasks to be executed within the specified execution time period, and whether there are remaining load testing resources in the load testing resource pool after allocating load testing resources for the load testing tasks. Therefore, if there are no remaining resources in the load testing resource pool after allocating load testing resources for the load testing tasks within the specified execution time period, the execution time period is determined to be resource-saturated; that is, no more load testing tasks can be inserted into the execution time period, and no more load testing tasks can be allocated to it. Based on this, it is determined whether the load testing resources of other execution time periods are saturated, and when it is determined that there are non-saturated execution time periods, recommended executable time periods are output. Specifically, adjacent execution time periods to the execution time period to which the load testing task's execution time belongs are given priority for recommendation.

[0128] Furthermore, based on the execution time period of the load testing task included in the iteration results, the load testing resources of the stress testing machine are dynamically scheduled so that the load testing task has usable application resources during execution. That is, the step of scheduling the load testing resources corresponding to the load testing task according to the execution time period includes:

[0129] Generate resource scheduling instructions for the execution time period and monitor the execution status of the load testing tasks within the execution time period in real time. The execution status includes execution progress and resource occupancy status.

[0130] When the actual resource consumption deviates from the predicted value based on the execution status, the resource scheduling instruction is executed to schedule the stress test resources.

[0131] After obtaining the execution time period of the load testing task through a multi-objective optimization algorithm, the actual resource consumption may deviate from the predicted value due to dynamic changes in resource occupancy during the actual scheduling process. If the scheduling strategy cannot be adjusted in time, it will cause resource allocation conflicts or task execution delays. Therefore, the execution time period is converted into a load testing machine control command, and the execution progress and resource occupancy status of each load testing task in the sequence of tasks to be executed are monitored in real time. Thus, when the resource occupancy status determines that the actual resource consumption deviates from the predicted value, the load testing machine control command is executed to schedule the load testing machine resources.

[0132] The generation of pressure machine control commands is based on the difference between the execution time period and the current system time. The time difference is mapped to the start and stop signals of the pressure machine through a timestamp conversion mechanism. The real-time monitoring process periodically collects CPU utilization, memory usage, and network bandwidth data of each pressure testing task through the resource monitoring module to form a time series of resource usage status. The judgment of whether the actual resource consumption deviates from the predicted value is based on a preset deviation threshold. For example, when the CPU utilization exceeds the predicted value by 5% or the memory usage is lower than the predicted value by 10%, a scheduling command is triggered. The specific operation of scheduling pressure machine resources includes dynamically allocating idle pressure machines to overloaded tasks or reclaiming idle pressure machine resources.

[0133] Specifically, the pressure machine control command generation module receives the execution time period output by the multi-objective optimization algorithm, synchronizes it with the system clock, and generates a control command queue containing the task ID, target pressure machine number, and start time. The resource monitoring module acquires real-time load data of each pressure machine at fixed sampling intervals. When it detects a continuous deviation between the resource consumption curve of a task and the output value of the prediction model, it triggers a deviation alarm and activates the scheduling command execution engine. The command execution engine prioritizes selecting idle pressure machines in the same rack for resource replenishment based on the online status and load of the pressure machines in the current resource pool. If no resources are available for allocation, it sends a delayed execution request to the task management module. During this process, real-time feedback data on resource occupancy status is synchronously recorded in the log database for use in the training dataset of the subsequent optimization of the resource prediction model. Through the above closed-loop control mechanism, the balance between resource allocation and demand can be dynamically maintained during task execution, avoiding system resource overload or waste caused by prediction errors.

[0134] The execution time period is converted into stress test control commands, and the execution progress and resource usage status of each stress test task in the task sequence to be executed are monitored in real time. Specifically, the resource monitoring module collects indicators such as CPU utilization, memory utilization, and network bandwidth utilization of the stress test cluster to form resource usage status data. At the same time, the task scheduling module tracks the execution progress of each stress test task and records information such as the number of completed test cases and the number of requests sent.

[0135] Furthermore, when the actual resource consumption deviates from the predicted value based on the resource occupancy status, load generator control commands are executed to schedule load generator resources. For example, when the actual CPU utilization of a load testing task exceeds the predicted value by 20%, the resource scheduling mechanism is triggered. This allows for the dynamic increase of the number of load generators for that task, or the suspension of other low-priority tasks to release resources.

[0136] As a specific implementation, load testing control commands can include operations such as starting a new load tester, stopping an idle load tester, and adjusting load testing parameters. When starting a new load tester, an idle machine is first selected from the resource pool, and then the load testing environment is deployed on the target machine via a remote script, along with the test script. When stopping an idle load tester, test data is saved first, and then related processes are closed to release resources. When adjusting load testing parameters, configuration items such as the number of concurrent users and the request interval can be dynamically modified.

[0137] Based on this mechanism, stress test machine resources can be flexibly allocated according to the actual execution of tasks, avoiding resource waste or shortage. Simultaneously, real-time monitoring and dynamic adjustments improve the execution efficiency and resource utilization of stress testing tasks. Furthermore, automated resource scheduling reduces manual intervention and lowers operational costs.

[0138] Furthermore, the step of generating resource scheduling instructions for the execution time period and monitoring the execution status of the load testing tasks within the execution time period in real time also includes:

[0139] Identify resource preemption conflicts within the specified execution time period;

[0140] Locate the target load testing task corresponding to the resource preemption conflict event, and schedule the target load testing task based on task priority. The scheduling process includes implementing preemptive scheduling or queuing.

[0141] The resource preemption conflict events are fed back to the prediction model optimization mechanism.

[0142] In this embodiment, when dynamically scheduling stress machine resources, resource preemption conflicts may occur due to multiple stress testing tasks simultaneously requesting resources. This can cause some tasks to fail to execute on time or result in unreasonable resource allocation, affecting overall scheduling efficiency and task completion rate. Therefore, by monitoring resource preemption conflict events during the execution period, the target stress testing task with the resource preemption conflict is identified, and the target stress testing task is scheduled based on task priority. The scheduling process includes implementing preemptive scheduling or queuing, and the conflict events of resource preemption conflicts are recorded and fed back to the prediction model optimization mechanism.

[0143] The detection of resource preemption conflicts is achieved by observing the overlap of resource request time windows of multiple load testing tasks within the current execution time period. Specifically, when the resource request time windows of multiple load testing tasks overlap, a resource preemption conflict is determined to have occurred. Furthermore, based on the execution order of the target load testing tasks, load testing tasks within the execution time period can be executed sequentially according to priority rules. These priority rules include at least one parameter among task urgency, task type, or user level.

[0144] Furthermore, regarding the detected resource preemption conflict events, after locating the target load testing task corresponding to the conflict event, during the scheduling process of the target load testing task, the preemptive scheduling terminates the resource occupation of low-priority tasks and reallocates resources to high-priority tasks, allowing high-priority load testing tasks to complete first. The queuing waiting process involves inserting low-priority tasks at the end of the queue and delaying their completion. The conflict event record includes the conflict occurrence time, the identifier of the task involved, and resource type information. When fed back to the prediction model optimization mechanism, the parameters of the resource prediction model are updated through incremental training samples.

[0145] Specifically, when multiple load testing tasks are detected requesting the same type of stress machine resources within the same time period, a resource preemption conflict detection mechanism is triggered. By comparing priority markers in the task attribute database, the lowest-priority target load testing task among the conflicting tasks is identified. If the target load testing task is in an inactive state, it is moved to a waiting queue and marked with a delayed execution timestamp; if the target load testing task has already occupied resources, a resource release command is sent to the corresponding stress machine node. After each conflict resolution, log data containing the conflict time, task ID, and resource type is automatically generated. This cleaned log data is used as training samples to input into the resource prediction model, optimizing the prediction accuracy of resource usage for subsequent tasks. Through this closed-loop feedback mechanism, the system can gradually reduce the probability of resource conflicts caused by prediction errors, while ensuring that high-priority tasks receive priority execution.

[0146] In other words, during the dynamic scheduling of stress test resources, when multiple stress test tasks simultaneously request the same stress test resource within a waiting time period, the system detects a resource preemption conflict event through the real-time resource status monitoring module. At this point, the conflict analysis module determines the target set of stress test tasks causing the conflict based on task identifiers and resource allocation records, and extracts the task priority tags for each task. The scheduling decision module, based on preset priority rules, marks high-priority tasks as preemptive scheduling objects, while moving low-priority tasks into a waiting queue and setting a delayed execution flag. After completing the scheduling process, the event recording module generates log data containing the conflict occurrence time, involved task identifiers, and the final handling method, and transmits this data to the incremental training sample pool in the prediction model optimization mechanism via a data interface to update the training dataset of the resource prediction model. Based on this, resource preemption conflicts can be effectively identified and resolved, avoiding a vicious cycle of resource allocation caused by task backlog. Through a priority-driven scheduling decision mechanism, critical tasks are ensured to acquire resources first, while the resource prediction model is dynamically optimized through conflict event feedback, thereby improving the accuracy and adaptability of subsequent resource scheduling schemes.

[0147] In this embodiment, the resource usage at future moments is obtained by assessing the complexity of the scenario and establishing a resource demand prediction model. Based on this, the scenario operation is intelligently scheduled and resource allocation is coordinated, thereby reducing the complexity of users in arranging scenario tasks and improving the on-time completion rate and resource utilization of scenario tasks.

[0148] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the scheduling method of stress testing resources in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0149] This application provides a scheduling device for stress testing resources. The scheduling device for stress testing resources includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the scheduling method for stress testing resources in the first embodiment described above.

[0150] The following is for reference. Figure 2 The diagram illustrates a structural schematic of a scheduling device suitable for implementing stress testing resources in the embodiments of this application. The scheduling device for stress testing resources in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 2 The stress testing resource scheduling device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0151] like Figure 2As shown, the stress testing resource scheduling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the stress testing resource scheduling device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the stress testing resource scheduling device to communicate wirelessly or wiredly with other devices to exchange data. Although a stress testing resource scheduling device with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0152] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0153] The stress testing resource scheduling device provided in this application, employing the stress testing resource scheduling method in the above embodiments, can solve the technical problem of uneven allocation of pressure machine resources when performing stress testing tasks. Compared with the prior art, the beneficial effects of the stress testing resource scheduling device provided in this application are the same as those of the stress testing resource scheduling method provided in the above embodiments, and other technical features in this stress testing resource scheduling device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0154] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0155] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0156] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the stress testing resource scheduling method in the above embodiments.

[0157] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), or any suitable combination thereof.

[0158] The aforementioned computer-readable storage medium may be included in the scheduling device for stress testing resources; or it may exist independently and not be assembled into the scheduling device for stress testing resources.

[0159] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the load testing resource scheduling device, the load testing resource scheduling device implements the technical content of the load testing resource scheduling method embodiment shown above.

[0160] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming 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).

[0161] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0162] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0163] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described load testing resource scheduling method, which can solve the technical problem of uneven allocation of pressure machine resources when performing load testing tasks. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the load testing resource scheduling method provided in the above embodiments, and will not be repeated here.

Claims

1. A method for scheduling stress testing resources, characterized in that, The method for scheduling the stress testing resources includes the following steps: Obtain the characteristic variables of the load testing task to be executed in the current load testing scenario; Based on the aforementioned characteristic variables, the estimated resource consumption of the load testing task to be executed is determined. The execution time period of the stress test task is determined by the task execution information and estimated resource consumption of the stress test task. Based on the execution time period, the load testing resources corresponding to the load testing task are scheduled.

2. The method for scheduling stress testing resources as described in claim 1, characterized in that, The step of determining the estimated resource consumption of the load testing task to be executed based on the feature variables includes: The feature variables are input into the resource prediction model, which is constructed based on the gradient boosting decision tree algorithm and is used to calculate the estimated resource consumption of the stress test task. The estimated resource consumption of the stress test task is calculated using the resource prediction model.

3. The method for scheduling stress testing resources as described in claim 2, characterized in that, Before the step of calculating the estimated resource consumption of the stress testing task using the resource prediction model, the method further includes: Obtain historical load testing tasks and determine the actual resource usage and scenario feature tags of the historical load testing tasks; Incremental training samples are generated based on the actual resource usage data and the scene feature labels; The resource prediction model is iteratively trained using the incremental training samples, and the resource prediction model is obtained based on the training results of the iterative training.

4. The method for scheduling stress testing resources as described in claim 1, characterized in that, The step of determining the execution time period of the load testing task based on the task execution information of the load testing task and the estimated resource consumption includes: Determine the target optimization strategy corresponding to the workload of the stress testing task, wherein the optimization parameters corresponding to the workload are obtained, and the target optimization algorithm is configured to generate the target optimization strategy through the optimization parameters, wherein the optimization parameters include population size, number of iterations and constraints. A multi-objective function is generated based on the task execution information and the estimated resource consumption, and the multi-objective function is iteratively calculated using the objective optimization strategy. The execution time period is obtained based on the iteration results.

5. The method for scheduling stress testing resources as described in claim 4, characterized in that, The step of generating a multi-objective function based on the task execution information and the estimated resource consumption, and iteratively calculating the multi-objective function using the objective optimization algorithm, includes: Generate multiple scheduling schemes for the multi-objective function; The target solution set is selected from the scheduling scheme using preset screening conditions, and the iteration calculation is terminated based on the generational optimization magnitude of the target solution set. The preset screening conditions include non-dominated sorting and crowding distance. If the generational optimization magnitude is greater than the preset convergence threshold, the iterative calculation is terminated.

6. The method for scheduling stress testing resources as described in claim 1, characterized in that, After determining the execution time period of the load testing task based on the task execution information and the estimated resource consumption, the method further includes: When a load testing task to be executed is received based on the execution time period, the resource saturation of the execution time period is determined by the estimated resource usage. If the resources are determined to be saturated during the execution time period, recommended information on the available execution time period will be output.

7. The method for scheduling stress testing resources as described in claim 1, characterized in that, The step of scheduling the load testing resources corresponding to the load testing task according to the execution time period includes: Generate resource scheduling instructions for the execution time period and monitor the execution status of the load testing tasks within the execution time period in real time. The execution status includes execution progress and resource occupancy status. When the actual resource consumption deviates from the predicted value based on the execution status, the resource scheduling instruction is executed to schedule the stress test resources.

8. The method according to claim 7, characterized in that, The step of generating resource scheduling instructions for the execution time period and monitoring the execution status of the load testing tasks within the execution time period in real time further includes: Identify resource preemption conflicts within the specified execution time period; Locate the target load testing task corresponding to the resource preemption conflict event, and schedule the target load testing task based on task priority. The scheduling process includes implementing preemptive scheduling or queuing. The resource preemption conflict events are fed back to the prediction model optimization mechanism.

9. A scheduling device for stress testing resources, characterized in that, The stress test resource scheduling device stores a computer program, which, when executed by a processor, implements the stress test resource scheduling method according to any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the stress testing resource scheduling method according to any one of claims 1-8.

Images