A method for optimizing request scheduling and a terminal

Abstract

The application provides a request scheduling optimization method and a terminal. Historical average response time of each interface is obtained according to historical data; average response time of each interface within a preset time length is monitored and counted, and when average response time of any interface exceeds preset multiple of historical response time, part of requests of the interface is scheduled to a corresponding interface of a higher machine type; processing capacity of the higher machine type is superior to that of an original machine type. When it is found that average response time of any interface exceeds preset multiple of historical average response time, part of requests of the interface is scheduled to a higher machine type with stronger processing capacity than that of an original machine type to reduce burden of the original machine type, dynamic management of requests of each machine type is performed, load imbalance is avoided, and response speed of each interface is ensured.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to an optimization method and terminal for request scheduling. Background Technology

[0002] In modern internet systems, to support high-concurrency scenarios, servers typically employ a microservice architecture. Multiple application instances are deployed, and these instances register with a service registry. When a client needs to use a service, it retrieves a list of routing addresses from the registry and, based on specific routing rules, routes the request to the appropriate instance.

[0003] In this scenario, regardless of the machine on which the instance is deployed, it appears as the same node to the client, with no distinguishing features. Traffic can only be evenly distributed or scheduled to the corresponding instance according to a fixed strategy. Even if some interfaces have different response times, there is no way to handle them specifically, and there is no intelligent solution for increased request latency. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide an optimized method and terminal for request scheduling to solve the problem of request response time delay.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0006] An optimization method for request scheduling includes the following steps:

[0007] S1. Obtain the historical average response time of each interface based on the historical data of the original model;

[0008] S2. Monitor and count the average response time of each interface within a preset time period, and when the average response time of any interface exceeds a preset multiple of the historical average response time, schedule part of the request of this interface to the corresponding interface of the host computer; the processing capability of the host computer is better than that of the original computer.

[0009] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:

[0010] An optimized terminal for request scheduling includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps:

[0011] S1. Obtain the historical average response time of each interface based on the historical data of the original model;

[0012] S2. Monitor and count the average response time of each interface within a preset time period, and when the average response time of any interface exceeds a preset multiple of the historical average response time, schedule part of the request of this interface to the corresponding interface of the host computer; the processing capability of the host computer is better than that of the original computer.

[0013] The beneficial effects of this invention are as follows: It provides an optimized request scheduling method and terminal, which confirms the historical average response time of each interface based on the historical data of the original model, and judges whether the processing capacity of the interface is stable based on the historical average response time. When it is found that the average response time of any interface exceeds the preset multiple of the historical response time, in order to ensure the response speed, some requests of this interface are scheduled to a host model with stronger processing capacity than the original interface model, thereby reducing the burden on the original model, dynamically managing the requests of each model, avoiding load imbalance, and ensuring the response speed of each interface. Attached Figure Description

[0014] Figure 1 This is a flowchart of an optimization method for request scheduling in an embodiment of the present invention;

[0015] Figure 2 This is a schematic diagram of an optimized terminal for request scheduling in an embodiment of the present invention;

[0016] Label Explanation:

[0017] 1. An optimized terminal for request scheduling; 2. Memory; 3. Processor. Detailed Implementation

[0018] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0019] Please refer to Figure 1 An optimization method for request scheduling includes the following steps:

[0020] S1. Obtain the historical average response time for each interface based on historical data;

[0021] S2. Monitor and count the average response time of each interface within a preset time period, and when the average response time of any interface exceeds a preset multiple of the historical average response time, schedule part of the request of this interface to the corresponding interface of the host computer; the processing capability of the host computer is better than that of the original computer.

[0022] As can be seen from the above description, the beneficial effects of the present invention are as follows: the historical average response time of each interface is confirmed based on historical data, and the processing capacity of the interface is judged to be stable based on the historical average response time. When it is found that the average response time of any interface exceeds the preset multiple of the historical average response time, in order to ensure the response speed, some requests of this interface are scheduled to a host machine with stronger processing capacity than the original interface, thereby reducing the burden on the original machine. The requests of each machine are dynamically managed to avoid load imbalance and ensure the response speed of each interface.

[0023] Understandably, the host computer model has better processing power than the original model, which is because the host computer can provide more computing resources, storage space and richer software support, thereby supporting more complex data processing.

[0024] Specifically, the preset magnification ratio is between 1.2 and 1.5, preferably 1.5.

[0025] In an embodiment of the present invention, step S2 specifically includes the following steps:

[0026] S21. Record the instance deployment data for each machine type and save it to the registry center;

[0027] S22. Monitor and calculate the average response time of each interface within a preset time period. When the average response time of any interface exceeds the preset multiple of the historical average response time, according to the instance deployment data of the registration center, schedule the request of this interface to the corresponding interface of the host machine according to the preset ratio.

[0028] As described above, by saving the instance data deployed on each type of machine to the registry center, the interface data of each application instance can be obtained. When the request needs to be scheduled in the subsequent process, the instance data in the registry center can be used to quickly match the interfaces, thereby quickly scheduling some requests from the original machine to the corresponding interfaces of the host machine according to the matching results, which increases the flexibility and accuracy of the scheduling process.

[0029] In an embodiment of the present invention, step S2 further includes the step:

[0030] When the average response time of this interface is lower than the historical average response time, requests that have been scheduled to the host machine will be redirected back to this interface.

[0031] As can be seen from the above description, when the service response time is lower than the historical standard, the request can be recalled from the host machine to prevent idle and wasted resources, while maintaining service quality and efficiency.

[0032] In embodiments of the present invention, the machine type includes a standard machine, a medium-sized machine, and a large machine; the medium-sized machine is a host machine type of the standard machine, and the large machine is a host machine type of the medium-sized machine.

[0033] As described above, a layered service system is constructed by setting up ordinary machines, mid-range machines, and mainframes with progressively increasing processing capabilities, clearly defining the relationships and roles of different machine types. By handling requests with varying loads at different machine levels, processing efficiency is ensured while increasing system scalability and flexibility. Specifically, the number of ordinary machines, mid-range machines, and mainframes increases sequentially, with ordinary machines having the most application instances deployed, followed by mid-range machines, and mainframes having the fewest.

[0034] In an embodiment of the present invention, step S2 further includes the step:

[0035] An alarm is triggered when the average response time of any interface of the mainframe exceeds the historical average response time.

[0036] As described above, establishing an alarm mechanism enhances system robustness. When the system load exceeds the processing capacity of all machine types, the alarm handling mechanism promptly notifies the system administrator or automatically triggers additional resource allocation. This early warning mechanism allows for preventative measures to be taken before problems escalate into serious failures, ensuring stable system operation and service continuity.

[0037] Please refer to Figure 2 An optimized terminal for request scheduling includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform steps in the optimized request scheduling method.

[0038] As described above, a carrier for an optimized request scheduling method is provided. During the execution of the above method, the historical average response time of each interface is confirmed based on historical data. The historical average response time is used as a benchmark to determine whether the processing capacity of the interface is stable. When it is found that the average response time of any interface exceeds the historical average response time, in order to ensure the response speed, some requests of this interface are scheduled to a higher-level machine with stronger processing capacity than the original interface, thereby reducing the burden on the original machine. The requests of each machine are dynamically managed to avoid load imbalance and ensure the response speed of each interface.

[0039] This invention provides an optimization method and terminal for request scheduling, which is mainly applied to the data processing process under a microservice architecture. The following is a detailed description with reference to the embodiments.

[0040] Please refer to Figure 1 Embodiment 1 of the present invention is as follows:

[0041] An optimization method for request scheduling includes the following steps:

[0042] S1. Obtain the historical average response time for each interface based on historical data;

[0043] S2. Monitor and calculate the average response time of each interface within a preset time period. When the average response time of any interface exceeds the preset multiple of the historical average response time, schedule part of the request of this interface to the corresponding interface of the host computer. The processing capability of the host computer is better than that of the original machine.

[0044] In this embodiment, the historical average response time of each interface is confirmed based on historical data. The processing capacity of the interface is then judged based on the historical average response time. When the average response time of any interface is found to exceed a preset multiple of the historical average response time, in order to ensure the response speed, some requests of this interface are scheduled to a host machine with stronger processing capacity than the original interface, thereby reducing the burden on the original machine. The requests of each machine are dynamically managed to avoid load imbalance and ensure the response speed of each interface.

[0045] Embodiment 2 of the present invention is as follows:

[0046] Based on Example 1, step S2 specifically includes the following steps:

[0047] S21. Record the instance deployment data for each machine type and save it to the registry center; by saving the instance data deployed on each machine type to the registry center, the interface data of each application instance can be obtained, which facilitates interface matching in the subsequent scheduling process.

[0048] S22. Monitor and statistically analyze the average response time of each interface within a preset time period. When the average response time of any interface exceeds the preset multiple of the historical average response time, according to the instance deployment data of the registration center, schedule the requests of this interface to the corresponding interface of the host machine according to the preset ratio. That is, the instance data of the registration center is used to quickly match interfaces, thereby quickly scheduling some requests of the original machine to the corresponding interface of the host machine according to the matching results, which increases the flexibility and accuracy of the scheduling process.

[0049] Embodiment 3 of the present invention is as follows:

[0050] Based on Example 2, the following application is made: Three machine types are set up: ordinary machine, medium machine and main machine. The processing power of the three machine types increases in sequence. Each machine type has at least two application instances of the same type. The application instance data deployed on each machine type is cached in the registry center.

[0051] Initially, a default traffic distribution method was used, with 60 requests coming in per second. Ten requests were evenly distributed across each instance on a regular machine. At this point, the historical latency for the interface was 100 milliseconds. After continuous monitoring, it was found that the average latency of this interface gradually increased to 150 milliseconds. Therefore, the traffic allocated to the regular machines was gradually reduced and redirected to mid-range machines. Specifically, the redirection ratio was between 30% and 50%, preferably 50%. When the redirection ratio was 50%, at least 10 requests were allocated to the mid-range machines. Subsequent monitoring showed that the latency was still gradually increasing, so the 50% traffic was continued to be migrated from the mid-range machines to mainframes. In this way, the interface response time was reduced by increasing the performance of the machine types.

[0052] Embodiment four of the present invention is as follows:

[0053] Based on Embodiment 2, step S2 further includes the following step:

[0054] When the average response time of this interface is lower than the historical average response time, requests that have been scheduled to the host machine will be redirected back to this interface. In other words, when the service response time is lower than the historical standard, requests can be redirected from the host machine to prevent idle and wasted resources, while maintaining service quality and efficiency.

[0055] An alarm is triggered when the average response time of any interface on the mainframe exceeds the historical average response time. This alarm mechanism enhances system robustness. When the system load exceeds the processing capacity of all machine types, the alarm mechanism promptly notifies the system administrator or automatically triggers additional resource allocation. This early warning mechanism allows for preventative measures before problems escalate into serious failures, ensuring stable system operation and service continuity.

[0056] Embodiment five of the present invention is as follows:

[0057] In a cloud computing service provider's environment, to ensure user experience and improve system processing efficiency, the following methods are used to optimize request scheduling:

[0058] Step 1: First, obtain the historical average response time for each API by analyzing historical data over a period of time. For example, historical data shows that the average response time for the GetUserDetails API was 200ms over the past week.

[0059] Step 2: The system continuously monitors and calculates the average response time of each interface over the past 5 minutes. Assume that during a monitoring period, the average response time of the GetUserDetails interface rises to 250ms, exceeding the historical average response time.

[0060] Step 2.1 (S21): Before monitoring begins, the deployment data (including machine type information) of all instances has been recorded and saved to the registry center. For example, the GetUserDetails interface is distributed across 10 ordinary machine type instances.

[0061] Step 2.2 (S22): When the average response time of the GetUserDetails interface exceeds the historical data, the system will, according to the instance deployment data of the registry center, schedule the request from the ordinary machine instance to the corresponding interface instance of the medium-sized machine according to a preset ratio, such as 30%.

[0062] Step 3: If, after a period of time, the average response time of the GetUserDetails interface on the medium-sized instance decreases to 180ms, which is lower than the historical average response time, the system will reverse some of the requests that were scheduled from the medium-sized instance to the regular instance and redirect them back to the regular instance.

[0063] Step 4: In this embodiment, the machine types are divided into ordinary machines, mid-range machines, and mainframe machines. When the response time of a certain interface on a mid-range machine still exceeds the historical average response time, the request is further scheduled to the corresponding interface on a mainframe machine.

[0064] Step 5: If the response time of the GetUserDetails interface on a mainframe instance is still higher than the historical average response time, the system will issue an alarm, prompt the system administrator, or automatically start the resource optimization process, such as increasing the number of mainframe instances or optimizing the code implementation.

[0065] Please refer to Figure 2 Embodiment five of the present invention is as follows:

[0066] An optimized terminal 1 for request scheduling includes a memory 2, a processor 3, and a computer program stored in the memory 2 and executable on the processor 3. When the processor 3 executes the computer program, it completes the steps in the optimized request scheduling method.

[0067] In summary, the request scheduling optimization method and terminal provided by this invention confirm the historical average response time of each interface based on historical data, and use the historical average response time as a benchmark to determine whether the processing capacity of the interface is stable. When it is found that the average response time of any interface exceeds the historical average response time, in order to ensure the response speed, some requests of this interface are scheduled to a host machine with stronger processing capacity than the original interface, thereby reducing the burden on the original machine. The requests of each machine are dynamically managed to avoid load imbalance and ensure the response speed of each interface.

[0068] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An optimization method for request scheduling, characterized in that: Including the following steps: S1. Obtain the historical average response time of each interface based on the historical data of the original model; S2. Monitor and calculate the average response time of each interface within a preset time period, and when the average response time of any interface exceeds a preset multiple of the historical average response time, schedule part of the request of this interface to the corresponding interface of the host computer; the processing capability of the host computer is better than that of the original computer. Step S2 specifically includes the following steps: S21. Record the instance deployment data for each machine type and save it to the registry center; S22. Monitor and count the average response time of each interface within a preset time period. When the average response time of any interface exceeds the preset multiple of the historical average response time, according to the instance deployment data of the registration center, schedule the request of this interface to the corresponding interface of the host machine according to the preset ratio.

2. The method for optimizing request scheduling according to claim 1, characterized in that: Step S2 further includes the following steps: When the average response time of this interface is lower than the historical average response time, requests that have been scheduled to the host machine will be redirected back to this interface.

3. The method for optimizing request scheduling according to any one of claims 1-2, characterized in that: The types of machines include standard machines, medium-sized machines, and large-scale machines; the medium-sized machine is the host computer version of the standard machine, and the large-scale machine is the host computer version of the medium-sized machine.

4. The method for optimizing request scheduling according to claim 3, characterized in that: Step S2 further includes the following steps: An alarm is triggered when the average response time of any interface of the mainframe exceeds a preset multiple of the historical response time.

5. An optimized terminal for request scheduling, characterized in that: Includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the following steps: S1. Obtain the historical average response time of each interface based on the historical data of the original model; S2. Monitor and calculate the average response time of each interface within a preset time period, and when the average response time of any interface exceeds a preset multiple of the historical average response time, schedule part of the request of this interface to the corresponding interface of the host computer; the processing capability of the host computer is better than that of the original computer. Step S2 specifically includes the following steps: S21. Record the instance deployment data for each machine type and save it to the registry center; S22. Monitor and count the average response time of each interface within a preset time period. When the average response time of any interface exceeds the preset multiple of the historical average response time, according to the instance deployment data of the registration center, schedule the request of this interface to the corresponding interface of the host machine according to the preset ratio.

6. An optimized terminal for request scheduling according to claim 5, characterized in that: Step S2 further includes the following steps: When the average response time of this interface is lower than the historical average response time, requests that have been scheduled to the host machine will be redirected back to this interface.

7. An optimized terminal for request scheduling according to any one of claims 5-6, characterized in that: The types of machines include standard machines, medium-sized machines, and large-scale machines; the medium-sized machine is the host computer version of the standard machine, and the large-scale machine is the host computer version of the medium-sized machine.

8. An optimized terminal for request scheduling according to claim 7, characterized in that: Step S2 further includes the following steps: An alarm is triggered when the average response time of any interface of the mainframe exceeds a preset multiple of the historical response time.

Images