Task scheduling method and device, equipment, medium and product

Abstract

The invention discloses a task scheduling method and device, equipment, a medium and a product. The method comprises the following steps: in response to a received transaction request, obtaining task relevance and task response time between tasks in the transaction request; determining a critical path and a non-critical path in each transaction request according to the task relevance and the task response time between the tasks; determining an optimal asynchronous thread pool parameter according to the request concurrence number of the transaction request and the hardware resource use condition; and dynamically adjusting a task scheduling sequence in a corresponding transaction request according to the critical path, the non-critical path and the optimal asynchronous thread pool parameter. According to the invention, the response time is reduced to the maximum extent, so that the overall time consumption of each transaction request is greatly shortened, and the service processing capability is improved.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and in particular to a task scheduling method, apparatus, device, medium, and product. Background Technology

[0002] In a microservice architecture, a complex request process often consists of cross-module access, cross-unit access, and other time-consuming tasks. When these accesses or tasks are processed sequentially, it often results in long response times. Furthermore, in high-concurrency mode, processing the request will preempt resources, causing request processing to queue, competing for server resources, and affecting service capabilities. Summary of the Invention

[0003] This invention provides a task scheduling method, apparatus, device, medium, and product to solve the technical problem of low request processing efficiency in the prior art.

[0004] According to one aspect of the present invention, a task scheduling method is provided, comprising:

[0005] Upon receiving a transaction request, the task correlation and task response time between each task in the transaction request are obtained;

[0006] Determine the critical and non-critical paths in each transaction request based on the task correlation and task response time between each task.

[0007] The optimal asynchronous thread pool parameters are determined based on the number of concurrent transaction requests and the usage of hardware resources.

[0008] The task scheduling order in the corresponding transaction request is dynamically adjusted based on the critical path, the non-critical path, and the optimal asynchronous thread pool parameters.

[0009] According to another aspect of the present invention, a task scheduling apparatus is provided, comprising:

[0010] The parameter acquisition module is used to, in response to receiving a transaction request, acquire the task correlation and task response time between each task in the transaction request;

[0011] The path determination module is used to determine the critical and non-critical paths in each transaction request based on the task correlation and task response time between each task.

[0012] The parameter determination module is used to determine the optimal asynchronous thread pool parameters based on the number of concurrent requests for the transaction request and the hardware resource usage.

[0013] The scheduling order adjustment module is used to dynamically adjust the task scheduling order in the corresponding transaction request based on the critical path, the non-critical path and the optimal asynchronous thread pool parameters.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the task scheduling method according to any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the task scheduling method described in any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the task scheduling method described in any embodiment of the present invention.

[0020] The technical solution of this invention, after receiving a transaction request, obtains the task correlation between each task in the transaction request and the task response time of each task; determines the critical path and non-critical path in each transaction request based on the task correlation and task response time; simultaneously, calculates the optimal asynchronous thread pool parameters based on the request concurrency and hardware resource usage of the transaction request; and then dynamically adjusts the task scheduling order in the transaction request according to the critical path, non-critical path, and optimal asynchronous thread pool parameters, so as to minimize the response time required after all tasks in each transaction request are completed, thereby maximizing the reduction of response time and greatly shortening the overall time of each transaction request, thus improving service processing capacity.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart of a task scheduling method provided in an embodiment of the present invention;

[0024] Figure 2 This is a flowchart of another task scheduling method provided in an embodiment of the present invention;

[0025] Figure 3 This is a schematic diagram illustrating the implementation of a task execution sequence provided by existing technology;

[0026] Figure 4 This is a schematic diagram illustrating the implementation of a task execution path provided in an embodiment of the present invention;

[0027] Figure 5 This is a schematic diagram illustrating the implementation of a task response time according to an embodiment of the present invention;

[0028] Figure 6 This is a schematic diagram illustrating the implementation of a critical path according to an embodiment of the present invention;

[0029] Figure 7 This is a schematic diagram illustrating the implementation of a non-critical path and asynchronous thread according to an embodiment of the present invention;

[0030] Figure 8 This is a schematic diagram of the structure of a task scheduling device provided in an embodiment of the present invention;

[0031] Figure 9 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] To address the issues of long response times and uneven resource allocation during high concurrency in serial access across multiple modules and units, the invention embodiments analyze and judge the number of concurrent requests, the dependencies between each access or task, whether it is serial, response time, waiting and blocking, etc., to obtain the critical path graph, parallel task data, thread pool parameters, etc. Based on these results, the code can be modified to reduce response time and improve performance.

[0035] In one embodiment, Figure 1 This is a flowchart of a task scheduling method provided by an embodiment of the present invention. This embodiment is applicable to situations where the task scheduling order in a transaction request needs to be dynamically adjusted in a microservice architecture. The method can be executed by a task scheduling device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0036] S110. In response to receiving a transaction request, obtain the task correlation and task response time between each task in the transaction request.

[0037] In one example, a transaction request refers to a request initiated by a user or system to modify data, interact with resources, or execute business processes. Generally, a transaction request may involve cross-module, cross-unit access, and time-consuming units such as data queries. It's important to note that cross-module access refers to one functional module calling the interface or method of another functional module within the same microservice—that is, a code-level call within the same service; cross-unit access refers to one microservice unit calling the interface of another microservice unit—that is, a network-level call across services; and data queries refer to accesses requiring network connections, such as across databases or servers.

[0038] In this embodiment, time-consuming units such as cross-module access, cross-unit access, and data query can be divided into multiple tasks. Task division can be based on the business functions within a transaction request, or it can be understood as based on the existence of service access via a network link; that is, each service access corresponds to one task. Service access refers to requesting an external service to achieve the purpose of data acquisition. Generally, a transaction request can include one or more tasks. For example, assuming a transaction request is a transfer transaction, this request involves two cross-module accesses: querying the balance and transferring funds; that is, the transaction request can include two tasks.

[0039] In one example, task correlation is used to characterize the relationships between multiple tasks due to business logic, data dependencies, or execution order. It can be understood as the execution result, status, or parameters of one task affecting the execution of other tasks. Task correlation between multiple tasks can also be called the sequential correlation between multiple tasks. Task response time is used to characterize the total time required from when a task is initiated by the system to when the system returns a result; task response time can also be called task processing time or system interaction time, that is, the total time required for interaction between two different systems when completing a task. In one embodiment, obtaining the task correlation between each task in a transaction request includes: obtaining the start and end markers of each task in the transaction request; determining the task dependencies between each task based on the start and end markers of each task; and determining the task correlation between each task based on the dependencies.

[0040] In one example, a start marker is used to mark a specific event, time point, or state trigger point that formally begins the execution of a task; an end marker is used to mark a specific event, time point, or state result that indicates the completion or termination of a task. Generally, the start and end markers of a task correspond and together form a closed loop of a task completion cycle.

[0041] In one example, different tasks can use different tag numbers to ensure the uniqueness of each tag number, thereby guaranteeing the accuracy of task dependency queries based on the tag number. For instance, suppose a transaction request includes three tasks: Task 1, Task 2, and Task 3. Task 1's start and end tags can be 1-start and 1-end, Task 2's start and end tags can be 2-start and 2-end, and Task 3's start and end tags can be 3-start and 3-end.

[0042] In one example, task dependency refers to the dependence between multiple tasks due to logical, data, or execution order constraints. In another example, the task dependency between each task can be determined based on the start and end markers of each task, and the execution order of each task can be determined based on the task dependency, thus obtaining the task association between each task.

[0043] For example, suppose a transaction request includes three tasks, namely task 1, task 2 and task 3, and the end marker 1-end of task 1 points to the start marker 2-start of task 2, and the end marker 2-end of task 2 points to the start marker 3-start of task 3. Then it can be determined that the execution of task 2 depends on the output of task 1, and the execution of task 3 depends on the output of task 2.

[0044] S120. Determine the critical and non-critical paths in each transaction request based on the task correlation and task response time between each task.

[0045] In one example, the critical path refers to the longest path in the entire transaction process corresponding to the transaction request, which determines the total duration of the transaction request / response (i.e., the shortest duration). Activities on the critical path are called critical activities. The non-critical path refers to the non-longest path in the entire transaction process corresponding to the transaction request, and activities on the non-critical path are called non-critical activities. In this embodiment, the entire transaction process corresponding to a transaction request includes one critical path and at least one non-critical path.

[0046] In this embodiment, all task execution paths corresponding to a transaction request in the entire transaction process are constructed based on the task relationships between each task. Furthermore, all task execution paths are parallel execution paths, meaning that tasks on one execution path can be executed simultaneously with tasks on another. After determining all task execution paths corresponding to a transaction request in the entire transaction process, the response times of all tasks included in a single execution path are added together to obtain the total response time of that path. The execution path with the longest total response time is then designated as the critical path, while the other execution paths are designated as non-critical paths.

[0047] For example, suppose a transaction request includes task 1, task 2, task 3, task 4, task 5, task 6, and task 7, and task 1, task 2, task 4, task 6, and task 7 constitute a task execution path. The response time of the task execution path constituted by task 1, task 2, task 4, task 6, and task 7 is duration 1, and the response time of the task execution path constituted by task 1, task 3, task 5, task 6, and task 7 is duration 2. Since duration 1 is greater than duration 2, the task execution path constituted by task 1, task 2, task 4, task 6, and task 7 is a critical path, and the task execution path constituted by task 1, task 3, task 5, task 6, and task 7 is a non-critical path.

[0048] S130. Determine the optimal asynchronous thread pool parameters based on the number of concurrent transaction requests and hardware resource usage.

[0049] In one embodiment, the request concurrency refers to the total number of transaction requests issued simultaneously within the same time period; hardware resource usage refers to the usage of core hardware resources of the electronic device used to process transaction requests. For example, hardware resource usage may include, but is not limited to, at least one of the following: hardware resource usage threshold and actual hardware resource usage; wherein, the hardware resource usage threshold refers to a set critical value for hardware resources. When the actual usage of hardware resources exceeds or falls below this value, the system will determine that the hardware resource status is abnormal and trigger corresponding processing; the actual hardware resource usage is used to characterize the hardware resources actually used when completing the transaction request corresponding to the request concurrency.

[0050] In one example, a thread pool is used to maintain multiple threads, waiting for a supervisor to assign tasks for concurrent execution, avoiding the cost of creating and destroying threads when processing short-lived tasks; an asynchronous thread pool refers to threads in the thread pool processing tasks asynchronously, that is, after a task is submitted to the thread pool, there is no need to block and wait for the result. The thread pool executes the task asynchronously in the background and returns the result or notification status through a preset method (such as a callback function or a Future object) after completion.

[0051] In one example, the asynchronous thread pool parameters include at least one of the following: the maximum number of threads in the thread pool;

[0052] Initial Thread Count. The maximum thread count of a thread pool represents the maximum number of threads that can run concurrently when the actual hardware resource usage of an electronic device reaches a corresponding hardware resource usage threshold. The initial thread count refers to the number of threads that need to be initialized when the electronic device starts up. Generally, the initial thread count is less than the maximum thread count of the thread pool; that is, the initial threads are a subset of the threads in the thread pool. For example, the initial thread count can be 20% of the maximum thread count. Assuming the maximum thread count of the thread pool is 30, the corresponding initial thread count could be 6.

[0053] In one example, the optimal asynchronous thread pool parameters are used to characterize the optimal scheduling of tasks among all transaction requests that can be completed concurrently, and / or the thread parameters in the thread pool can be optimized when the actual usage of hardware resources reaches the corresponding hardware resource usage threshold.

[0054] For example, suppose the maximum number of concurrent transactions can be 20, and each transaction request requires 2 asynchronous threads, that is, a total of 40 asynchronous threads are required; however, if the actual usage of hardware resources reaches the corresponding hardware resource usage threshold, the electronic device can only support 30 asynchronous threads. In this case, the maximum number of threads in the thread pool in the optimal asynchronous thread pool parameters can only be 30.

[0055] For example, suppose the maximum number of concurrent transactions is 20, and each transaction request requires 2 asynchronous threads, that is, a total of 40 asynchronous threads are required; however, if the actual usage of hardware resources reaches the corresponding hardware resource usage threshold, the electronic device can only support 50 asynchronous threads. In this case, the maximum number of threads in the thread pool in the optimal asynchronous thread pool parameters can only be 40.

[0056] S140. Dynamically adjust the task scheduling order in the corresponding transaction request based on the critical path, non-critical path and optimal asynchronous thread pool parameters.

[0057] In one example, task scheduling order is used to characterize the sequential order in which multiple tasks are executed or processed. In this embodiment, each task in the critical path can be executed using the main thread; simultaneously, each task in the corresponding non-critical path can be executed using an asynchronous thread. It should be noted that the start time of executing the first task in the non-critical path using an asynchronous thread can be later than the start time of executing the first task in the critical path using the main thread, as long as it ensures that the execution result of a task in the non-critical path is completed before the execution result of a task in the main thread is scheduled.

[0058] It's important to note that the response time of each transaction request is determined by the sum of the response times of all tasks within the critical path of that transaction request. In one example, the main thread can execute each task in the critical path, and asynchronous threads can be allocated to each non-critical path based on the optimal asynchronous thread pool parameters, including the maximum and initial number of threads. This ensures the normal operation of each task in the non-critical path, and consequently, the normal operation of each task in the critical path within the corresponding transaction request. This maximizes the reduction of the response time for each transaction request.

[0059] The technical solution of this embodiment obtains the task correlation between each task in the transaction request and the task response time of each task after receiving the transaction request; determines the critical path and non-critical path in each transaction request based on the task correlation and task response time; calculates the optimal asynchronous thread pool parameters based on the request concurrency and hardware resource usage of the transaction request; and then dynamically adjusts the task scheduling order in the transaction request according to the critical path, non-critical path and optimal asynchronous thread pool parameters to minimize the response time required after all tasks in each transaction request are completed, thereby maximizing the reduction of response time and greatly shortening the overall time of each transaction request, thus improving service processing capacity.

[0060] In one embodiment, Figure 2 This is a flowchart of another task scheduling method provided by an embodiment of the present invention. This embodiment further refines the process of determining critical and non-critical paths, as well as the process of determining the optimal asynchronous thread pool parameters, based on the above embodiments. Figure 2 As shown, the method includes:

[0061] S210. In response to receiving a transaction request, obtain the task correlation and task response time between each task in the transaction request.

[0062] S220. Based on the task correlation and task response time between each task, determine the path with the longest total response time in a transaction request, and use it as the critical path in the corresponding transaction request.

[0063] In one example, a task execution path refers to the executable path contained within the entire transaction process corresponding to a transaction request; generally, a transaction request may include one or more task execution paths, and each task execution path may contain multiple tasks. Furthermore, each task execution path is a concurrently executable path.

[0064] In this embodiment, the task correlation between each task can be obtained, and all tasks with task correlation can be formed into a task execution path. Then, the response times of all tasks included in each task execution path are added together, and the sum of the response times is taken as the total response time corresponding to the task execution path. Then, the task execution path with the longest total response time in a transaction request is taken as the critical path in the transaction request.

[0065] S230. Treat all paths in the transaction request other than the critical path as non-critical paths in the corresponding transaction request.

[0066] In this embodiment, after obtaining the critical path in the entire transaction process corresponding to a transaction request, all other paths in the entire transaction process corresponding to the transaction request, excluding the critical path, are regarded as non-critical paths in the transaction request.

[0067] In one embodiment, after designating the paths other than the critical path in the transaction request as non-critical paths in the corresponding transaction request, the task scheduling method further includes: adding each task in the non-critical path to an asynchronous thread pool for management and calling it using the Future pattern; wherein, the non-critical path corresponds one-to-one with the asynchronous thread.

[0068] In one example, a non-critical path corresponds one-to-one with an asynchronous thread. This can be understood as all tasks on a non-critical path being executed by a single asynchronous thread. In another example, the Future pattern is a design pattern in concurrent programming. For multithreading, if thread A needs to wait for the result of thread B, it doesn't need to wait indefinitely for B; it can obtain a future Future first, and then retrieve the actual result after B has completed its task. In this embodiment, each task on a non-critical path can be added to a corresponding asynchronous thread. Furthermore, the main thread can use the Future pattern to call the execution result of the last task in each asynchronous thread. That is, after the last task in each asynchronous thread completes its execution, the result is stored in the corresponding parameter in the main thread for later use.

[0069] S240. Determine the actual usage of hardware resources based on the number of concurrent requests for transaction requests.

[0070] In one example, actual hardware resource usage may include, but is not limited to, at least one of the following: actual CPU usage and actual memory usage. Actual CPU usage represents the CPU resources used to complete the transaction requests corresponding to the number of concurrent requests; that is, actual CPU usage can also be referred to as actual CPU usage. Actual memory usage represents the memory resources used to complete the transaction requests corresponding to the number of concurrent requests; that is, actual memory usage can also be referred to as actual memory usage.

[0071] In this embodiment, the number of concurrent transaction requests within the same time period can be determined; then, the actual hardware resource usage of all transaction requests corresponding to the number of concurrent requests is added together to obtain the actual hardware resource usage.

[0072] S250. If the actual usage of hardware resources does not reach the hardware resource usage threshold, determine the optimal asynchronous thread pool parameters based on the number of concurrent requests.

[0073] In one example, hardware resource usage thresholds may include, but are not limited to, at least one of the following: CPU usage threshold and memory usage threshold. The CPU usage threshold represents a critical value set for CPU resources (such as utilization rate or load). When the actual CPU usage exceeds or falls below this value, the system considers the CPU to be in an "abnormal state" and triggers preset actions (such as alarms or rate limiting). The memory usage threshold refers to a critical value set for memory resources (such as utilization rate or available capacity). When the actual memory usage exceeds or falls below this value, the system determines the memory state is abnormal and triggers corresponding processing.

[0074] In this embodiment, regarding the situation where the actual hardware resource usage does not reach the hardware resource usage threshold, it can be understood that when completing all transaction requests for the concurrent request count, the actual hardware resource usage of all transaction requests is still less than the hardware resource usage threshold. In this case, the electronic device cannot support more threads, meaning the optimal asynchronous thread pool parameters can be directly determined based on the concurrent request count. In one embodiment, the asynchronous thread pool parameters include at least one of the following: maximum number of threads in the thread pool; initial number of threads;

[0075] The asynchronous thread pool parameters are determined based on the number of concurrent requests, including: determining the maximum number of threads in the thread pool under the optimal path based on the number of concurrent requests; and determining the initial number of threads under the optimal path based on the maximum number of threads in the thread pool and a preset ratio.

[0076] In this embodiment, the maximum number of threads that can be supported in the same time period can be determined based on the number of concurrent requests, and the maximum number of threads that can be supported can be used as the maximum number of threads in the thread pool under the optimal path; then the product of the maximum number of threads in the thread pool and a preset ratio can be used as the initial number of threads under the optimal path.

[0077] For example, suppose the maximum number of concurrent transactions is 20, and each transaction request requires 2 asynchronous threads, that is, a total of 40 asynchronous threads are required; however, if the actual usage of hardware resources reaches the corresponding hardware resource usage threshold, the electronic device can support 50 asynchronous threads. In this case, the maximum number of threads in the optimal asynchronous thread pool parameter is determined based on the number of transaction requests, that is, the maximum number of threads in the thread pool can only be 40.

[0078] S260. If the actual usage of hardware resources reaches the hardware resource usage threshold, determine the optimal asynchronous thread pool parameters based on the hardware resource usage threshold.

[0079] In the embodiment, the situation where the actual use of hardware resources reaches the hardware resource usage threshold can be understood as follows: when all transaction requests of the request concurrency are completed, the actual use of hardware resources used by all transaction requests has reached the hardware resource usage threshold. At this time, the electronic device cannot support all asynchronous threads in all transaction requests corresponding to the request concurrency. In other words, the optimal asynchronous thread pool parameters can be determined directly based on the hardware resource usage threshold.

[0080] In one embodiment, the asynchronous thread pool parameters include at least one of the following: maximum number of threads in the thread pool; initial number of threads;

[0081] The asynchronous thread pool parameters are determined based on hardware resource usage thresholds, including: determining the maximum number of threads in the thread pool under the optimal path based on hardware resource usage thresholds; and determining the initial number of threads under the optimal path based on the maximum number of threads in the thread pool and a preset ratio.

[0082] In this embodiment, the maximum number of threads that can be supported in the same time period can be determined based on the hardware resource usage threshold, and the maximum number of threads that can be supported can be used as the maximum number of threads in the thread pool under the optimal path; then the product of the maximum number of threads in the thread pool and the preset ratio can be used as the initial number of threads under the optimal path.

[0083] For example, suppose the maximum number of concurrent transactions can be 20, and each transaction request requires 2 asynchronous threads, that is, a total of 40 asynchronous threads are required; however, if the actual usage of hardware resources reaches the corresponding hardware resource usage threshold, the electronic device can only support 30 asynchronous threads. In this case, the maximum number of threads in the optimal asynchronous thread pool parameters is determined according to the hardware resource usage threshold, and the maximum number of threads in the optimal asynchronous thread pool parameters can only be 30.

[0084] S270. Dynamically adjust the task scheduling order in the corresponding transaction request based on the critical path, non-critical path and optimal asynchronous thread pool parameters.

[0085] The technical solution of this embodiment, based on the above embodiments, determines the optimal asynchronous thread pool parameters based on the request concurrency when the actual hardware resource usage obtained from the transaction request concurrency does not reach the hardware resource usage threshold; and, when the actual hardware resource usage obtained from the transaction request concurrency reaches the hardware resource usage threshold, the optimal asynchronous thread pool parameters can be determined based on the hardware resource usage threshold. This achieves reasonable planning of the optimal maximum thread count and initial thread count of the thread pool, thereby ensuring the rational utilization of hardware resources.

[0086] In one embodiment, the task scheduling implementation process may include the following steps:

[0087] Step 1: Organize and tag tasks.

[0088] In this embodiment, time-consuming units such as cross-module and cross-unit access and data query involved in a transaction request can be divided into multiple tasks, namely Task 1, Task 2, Task 3... Task N. Start and end markers are set in the code of each task, and different tasks can use different marker numbers.

[0089] Figure 3 This is a schematic diagram illustrating an implementation of a task execution sequence provided by existing technology, such as... Figure 3 As shown, tasks 1, 2, 3...N in the transaction request are executed sequentially. This can be understood as the existing technology using serial execution of N tasks, that is, executing N tasks one by one in order.

[0090] Step 2: Analyze the task relationships between the various tasks.

[0091] In this embodiment, static code can be executed to analyze the logical dependencies between the inputs and outputs of each task, so as to obtain the sequential correlation between each task, which serves as the task correlation between each task.

[0092] Figure 4 This is a schematic diagram illustrating the implementation of a task execution path provided in an embodiment of the present invention, as shown below. Figure 4As shown, assuming a transaction request corresponds to 9 tasks, namely Task 1, Task 2, Task 3... Task 8 and Task 9, and there are task relationships between Task 1, Task 2, Task 6, Task 8 and Task 9, Task 1, Task 3, Task 7, Task 8 and Task 9, and Task 4, Task 5 and Task 9, then Task 1, Task 2, Task 6, Task 8 and Task 9 can be combined into one task execution path, Task 1, Task 3, Task 7, Task 8 and Task 9 can be combined into another task execution path, and Task 4, Task 5 and Task 9 can be combined into yet another task execution path. This gives us three task execution paths that can be executed in parallel for the transaction request.

[0093] Step 3: Dynamically collect the task response time of each task.

[0094] In this embodiment, the actual processing time of each task in the transaction request can be calculated by deploying code, and used as the task response time.

[0095] Figure 5 This is a schematic diagram illustrating the implementation of a task response time according to an embodiment of the present invention. For example... Figure 5 As shown, assume a transaction request includes N tasks, and the task response time for each task is T1, T2, T3...TN.

[0096] Step 4: Identify the tasks on the critical path and non-critical paths.

[0097] In this embodiment, the path with the longest total response time can be calculated based on task relevance and task response time, and used as the associated path. Figure 6 This is a schematic diagram illustrating the implementation of a critical path according to an embodiment of the present invention. Figure 6 In such Figure 4 Based on the above, assuming that the total response time of T1+T2+T6+T8+T9 is the longest, the task execution path consisting of task 1, task 2, task 6, task 8 and task 9 is taken as the critical path in the transaction request.

[0098] Step 5: Optimal task scheduling in non-critical paths.

[0099] Figure 7 This is a schematic diagram illustrating the implementation of a non-critical path and asynchronous thread according to an embodiment of the present invention. Figure 7 As shown, this embodiment is as follows Figure 4Based on the example shown, the task execution paths consisting of tasks 1, 3, 7, 8, and 9, as well as the task execution path consisting of tasks 4, 5, and 9, are all non-critical paths in this transaction request. Tasks in these two non-critical paths can be added to an asynchronous thread pool for management and invoked using the Future pattern.

[0100] It should be noted that, Figure 7 The scheme shown can also be understood as the implementation scheme of the task execution order of multiple tasks being executed in parallel, as proposed in this invention.

[0101] It should be noted that the total execution time of tasks 3 and 7 is less than the total execution time of tasks 2 and 6. Furthermore, task 7 must complete before task 8 to ensure that task 8 can execute normally without waiting for the result of task 7. After task 7 completes, the resources of thread 1 are proactively released; similarly, after task 5 completes, the resources of thread 2 are proactively released.

[0102] Step 6: Calculate the asynchronous thread pool parameters.

[0103] In this embodiment, the asynchronous thread pool parameters under the optimal path, namely the maximum number of threads and the initial number of threads, can be calculated based on the number of concurrent transactions, CPU usage threshold, and memory usage threshold.

[0104] Step 7: Output the structure graph of the critical path, the scheduling graph of the non-critical path, and the asynchronous thread pool parameters.

[0105] Step 8: Optimize or refactor the code based on the structure diagram of the critical path, the scheduling diagram of the non-critical path, and the asynchronous thread pool parameters to ensure that the task scheduling order is optimal.

[0106] The technical solution in this embodiment combines static code analysis (analyzing the correlation and dependency of each task through code analysis or the correlation of request / response messages) and dynamic collection of transaction request response time (collecting the actual response time of each access or task through data tracking). It first calculates the critical path, and then calculates parameters such as task scheduling and thread pool on the non-critical path, outputting the calculation results. Developers can modify the execution order and parallel connection of code blocks based on these results, minimizing response time and resource waste without changing the business logic, thereby improving performance.

[0107] In one embodiment, Figure 8 This is a schematic diagram of the structure of a task scheduling device provided in an embodiment of the present invention. Figure 8 As shown, the device includes: a parameter acquisition module 810, a path determination module 820, a parameter determination module 830, and a scheduling order adjustment module 840.

[0108] The parameter acquisition module 810 is used to obtain the task correlation and task response time between each task in the transaction request in response to receiving the transaction request.

[0109] The path determination module 820 is used to determine the critical and non-critical paths in each transaction request based on the task correlation and task response time between each task.

[0110] The parameter determination module 830 is used to determine the optimal asynchronous thread pool parameters based on the number of concurrent transaction requests and the usage of hardware resources.

[0111] The scheduling order adjustment module 840 is used to dynamically adjust the task scheduling order in the corresponding transaction request based on the critical path, non-critical path, and optimal asynchronous thread pool parameters.

[0112] In one embodiment, obtaining the task correlation between each task in a transaction request is specifically used for:

[0113] Obtain the start and end markers for each task in the transaction request;

[0114] The task dependencies between each task are determined based on the start and end tags of each task;

[0115] Determine the task relationships between each task based on dependencies.

[0116] In one embodiment, the path determination module 820 includes:

[0117] The critical path determination unit is used to determine the path with the longest total response time in a transaction request based on the task correlation and task response time between each task, and use it as the critical path in the corresponding transaction request.

[0118] The non-critical path determination unit is used to identify paths other than the critical path in a transaction request as non-critical paths in the corresponding transaction request.

[0119] In one embodiment, the task scheduling device further includes:

[0120] The management module is used to add each task in the non-critical path to the asynchronous thread pool for management and to call it using the Future pattern; there is a one-to-one correspondence between the non-critical path and the asynchronous thread.

[0121] In one embodiment, the parameter determination module 830 includes:

[0122] The resource usage determination unit is used to determine the actual usage of hardware resources based on the number of concurrent transaction requests.

[0123] The parameter determination unit is used to determine the optimal asynchronous thread pool parameters based on the hardware resource usage threshold if the actual usage of hardware resources does not reach the hardware resource usage threshold.

[0124] The parameter determination unit is also used to determine the optimal asynchronous thread pool parameters based on the number of concurrent requests if the actual usage of hardware resources reaches the hardware resource usage threshold.

[0125] In one embodiment, the asynchronous thread pool parameters include at least one of the following: maximum number of threads in the thread pool; initial number of threads;

[0126] The asynchronous thread pool parameters are determined based on hardware resource usage thresholds, specifically for:

[0127] Determine the maximum number of threads in the thread pool under the optimal path based on the hardware resource usage threshold;

[0128] The initial number of threads under the optimal path is determined based on the maximum number of threads in the thread pool and the preset ratio.

[0129] In one embodiment, the asynchronous thread pool parameters include at least one of the following: maximum number of threads in the thread pool; initial number of threads;

[0130] The asynchronous thread pool parameters are determined based on the number of concurrent requests, specifically for:

[0131] Determine the maximum number of threads in the thread pool for the optimal path based on the number of concurrent requests;

[0132] The initial number of threads under the optimal path is determined based on the maximum number of threads in the thread pool and the preset ratio.

[0133] The task scheduling device provided in the embodiments of the present invention can execute the task scheduling method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0134] In one embodiment, Figure 9 This is a structural block diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 9 The diagram illustrates a schematic representation of an electronic device 10 that can be used to implement embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0135] like Figure 9 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0136] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0137] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as task scheduling methods.

[0138] In some embodiments, the task scheduling method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the task scheduling method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the task scheduling method by any other suitable means (e.g., by means of firmware).

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

[0140] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0141] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on 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.

[0142] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0143] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0144] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0145] This invention also provides a computer program product, including a computer program that, when executed by a processor, can implement the task scheduling method provided in any embodiment of this application.

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

[0147] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0148] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A task scheduling method, characterized in that, include: Upon receiving a transaction request, the task correlation and task response time between each task in the transaction request are obtained; Determine the critical and non-critical paths in each transaction request based on the task correlation and task response time between each task. The optimal asynchronous thread pool parameters are determined based on the number of concurrent transaction requests and the usage of hardware resources. The task scheduling order in the corresponding transaction request is dynamically adjusted based on the critical path, the non-critical path, and the optimal asynchronous thread pool parameters.

2. The method according to claim 1, characterized in that, The step of obtaining the task correlation between each task in the transaction request includes: Obtain the start and end markers for each task in the transaction request; The task dependencies between each task are determined based on the start and end tags of each task; The task relationships between each task are determined based on the dependencies.

3. The method according to claim 1, characterized in that, The step of determining the critical and non-critical paths in each transaction request based on the task correlation and task response time between each task includes: Based on the task correlation and task response time between each task, the path with the longest total response time in a transaction request is determined and used as the critical path in the corresponding transaction request. Other paths in the transaction request besides the critical path are considered as non-critical paths in the corresponding transaction request.

4. The method according to claim 3, characterized in that, The method further includes: Each task in the non-critical path is added to an asynchronous thread pool for management and invoked using the Future pattern; wherein, the non-critical path corresponds one-to-one with the asynchronous thread.

5. The method according to claim 1, characterized in that, The step of determining the optimal asynchronous thread pool parameters based on the number of concurrent requests for the transaction and the usage of hardware resources includes: The actual usage of hardware resources is determined based on the number of concurrent requests for the transaction requests. If the actual usage of the hardware resources does not reach the hardware resource usage threshold, the optimal asynchronous thread pool parameters are determined based on the number of concurrent requests. If the actual usage of the hardware resources reaches the hardware resource usage threshold, the optimal asynchronous thread pool parameters are determined based on the hardware resource usage threshold.

6. The method according to claim 5, characterized in that, The asynchronous thread pool parameters include at least one of the following: maximum number of threads in the thread pool; initial number of threads; The step of determining the asynchronous thread pool parameters based on the hardware resource usage threshold includes: The maximum number of threads in the thread pool under the optimal path is determined based on the aforementioned hardware resource usage threshold. The initial number of threads under the optimal path is determined based on the maximum number of threads in the thread pool and the preset ratio.

7. The method according to claim 5, characterized in that, The asynchronous thread pool parameters include at least one of the following: maximum number of threads in the thread pool; initial number of threads; The step of determining the asynchronous thread pool parameters based on the number of concurrent requests includes: The maximum number of threads in the thread pool under the optimal path is determined based on the number of concurrent requests. The initial number of threads under the optimal path is determined based on the maximum number of threads in the thread pool and the preset ratio.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the task scheduling method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the task scheduling method according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the task scheduling method according to any one of claims 1-7.

Images