A Concurrent Processing Method for HTTP Request Task Queues Based on the UE Engine

Abstract

The present application provides a method for concurrent processing of an HTTP request task queue based on the UE engine, which relates to the technical field of network communication methods. The method includes steps such as request reception, data collection, model construction, load prediction, request enqueueing, task scheduling, task distribution, and request response. The present application uses a deep learning algorithm to construct a load prediction model, which can accurately predict changes in system load, enabling the processing of requests to be dynamically adjusted according to the actual state of the system load, thereby reducing the instability caused by static scheduling in traditional methods.

Description

Technical Field

[0001] This application relates to the technical field of network communication methods, and in particular, to an HTTP request task queue concurrent processing method based on the UE engine. Background Art

[0002] Unreal Engine (UE) is a highly optimized game engine widely used in game development, virtual reality, augmented reality, and other fields. The UE engine is characterized by extremely high requirements for real-time performance and high concurrency. In the UE engine, HTTP requests are usually used for communication between the client and the server to process in-game data, user requests, real-time updates, etc. The concurrent processing mechanism of the request task queue in the UE engine faces challenges of a large number of concurrent requests, especially in real-time applications such as multiplayer online games.

[0003] The Chinese invention patent with the publication date of October 12, 2020, and the publication number of CN112346834A provides a request processing method and device for a database, an electronic device, and a medium. This patent receives an operation request from a client, determines the priority of the operation request according to a preset rule based on the operation request and the submission mode of the transaction to which the operation request belongs; adds the operation request to the task queue with the corresponding priority in the thread pool according to the priority of the operation request; and processes the task by obtaining the task from the task queue according to the priority of the task queue.

[0004] In view of the above technical solution, it is proposed to set the request priority according to a preset rule to cope with the situation of threads that may occur in a high-concurrency scenario. However, the high-concurrency requests in the UE engine are dynamic and complex, different from the fixed mode of database requests. In scenarios such as multiplayer online games and real-time applications, HTTP requests have very strong real-time requirements, and the frequency and distribution of requests are very uneven. With the sharp increase in the number of requests, it may cause the system to be overloaded instantly, affecting the performance and response time of the system. Summary of the Invention

[0005] In order to cope with the dynamic and complex nature of high-concurrency requests in the UE engine and improve the performance and response time of the system, this application provides an HTTP request task queue concurrent processing method based on the UE engine.

[0006] In a first aspect, this application provides an HTTP request task queue concurrent processing method based on the UE engine, adopting the following technical solution:

[0007] An HTTP request task queue concurrent processing method based on the UE engine includes the following steps:

[0008] Request reception: Receive the request sent by the user request side of the UE engine, and set the request priority according to the request time; the request includes request content, request payload, request source, and request time;

[0009] Data collection: Include collecting real-time operation data and historical operation data;

[0010] Collect real-time operation data: Collect real-time operation data, and the real-time operation data includes user behavior data and game event data corresponding to the request;

[0011] Collect historical operation data: Collect historical operation data, and the historical operation data includes historical requests, historical system resource data, historical user behavior data, and historical game event data;

[0012] Model construction: Based on deep learning algorithms, construct a load prediction model;

[0013] Load prediction: Use the real-time operation data and the request sent by the user request side as the input of the load prediction model, and output load prediction data;

[0014] Request enqueueing: Classify the received requests according to their priorities, and send the classified requests to the corresponding request priority task queues;

[0015] Task scheduling: Based on the load prediction data, sort the requests in each task queue;

[0016] Task distribution: According to the sorting results, sequentially distribute tasks, and allocate corresponding processing nodes for the requests to be processed according to the load of each request and the load of the processing nodes;

[0017] Request response: After the request is processed, send a request response to the user request side.

[0018] By adopting the above technical solution, a load prediction model is constructed using a deep learning algorithm, which can accurately predict the load changes at different times and request types, enabling the processing of requests to be dynamically adjusted according to the actual state of system resources, thereby reducing the instability caused by static scheduling in traditional methods. In addition, by classifying and processing the priorities of requests, reasonable scheduling can be carried out according to the urgency and importance of requests, enabling high-priority requests to be processed in a timely manner, improving the service quality and user experience of the system. At the same time, based on the load prediction results and the priorities of requests, the task distribution and scheduling link can intelligently allocate requests to appropriate processing nodes and thread pools, reducing the overload of some resources in the system, while ensuring load balancing, improving the stability and resource utilization rate of the system. Moreover, by dynamically adjusting the allocation of task queues and processing nodes, the system can better adapt to user request volumes and load fluctuations, reducing the risks of system crashes and overloads, and enhancing the fault tolerance and stability of the system.

[0019] Optionally, after performing the step of constructing the model and before performing the step of load prediction, it further includes:

[0020] First data processing: Align the historical user behavior data, historical requests, historical system resource data, and historical game event data in time, obtain the generation time of each historical game event data, record the historical user behavior data and historical requests before the generation time of each historical game event data as the first data, and record the historical user behavior data and historical requests after the generation time of each historical game event data as the second data;

[0021] Second data processing: Compare the first data with the second data in each time period in chronological order, denoted as the first difference, obtain the time corresponding to the second data where the first difference is less than the preset difference threshold, denoted as the end time of this historical game event data, and calculate the duration from the generation time to the end time of each historical game event data, denoted as the activity duration of this historical game event data;

[0022] Third data processing: Use a clustering algorithm to cluster the activity durations of historical game event data, take the clustering result as the classification result of historical game event data, and take the activity duration of each category of historical game event data as the lag time window of this category of historical game event data;

[0023] Fourth data processing: According to the lag time window of each historical game event data, mark the historical user behavior data, historical requests, and historical system resource data corresponding to the lag time window of this historical game event data with the lag time mark of this historical game event, and use the marked historical user behavior data, historical requests, and historical system resource data as the new historical user behavior data, new historical requests, and new historical system resource data;

[0024] Construct a sample training set: construct a load sample training set based on historical user behavior data, historical requests, historical system resource data, and historical game events;

[0025] Iterative optimization: Define the mean square error loss function, use the load sample training set as the input of the load prediction model for model inference, iteratively optimize the load prediction model by minimizing the mean square error loss function, and use the optimized load prediction model as the new load prediction model.

[0026] By adopting the above technical solution, calculating the active duration of historical game events and analyzing the lag time window of historical game events through a clustering algorithm can better identify the dynamic change characteristics of game events. The lag time window can capture the dynamic changes in the number of requests, helping the load prediction model understand the lag effect of each game event on the system load. Therefore, when predicting the load, the real-time nature and dynamic fluctuations of the system load are taken into account, improving the prediction accuracy of the load prediction model in a dynamic high-concurrency environment.

[0027] Optionally, after performing the step of iterative optimization and before performing the step of load prediction, it further includes:

[0028] Fifth data processing: Determine whether there is game event data in the real-time operation data:

[0029] If so, classify the game event data according to the classification result of the historical game event data, obtain the lag time window of the game event data according to the classification result of the game event data, label the lag time mark of the game event data for the user behavior data and requests sent by the user request party in the real-time operation data according to the lag time window of the game event data, and use the marked user behavior data and requests as the new user behavior data and new requests to perform the step of load prediction;

[0030] If not, do not process and perform the step of load prediction.

[0031] By adopting the above technical solution, determining whether there is game event data in the real-time operation data, classifying and processing the current real-time data according to the classification result of the historical game event data, and labeling the lag time mark for the real-time data according to the classification result, which helps the load prediction model dynamically adjust the response time to real-time requests and load prediction according to the historical characteristics of the current game event, reducing the error generated by the load prediction model due to not considering the lag effect. When facing the actual application scenario, the load prediction model can not only utilize the regularity of historical data but also track and adapt to the load change in real time, further improving the prediction accuracy and reliability of the load prediction model.

[0032] Optionally, after the step of performing load prediction and before the step of enqueuing requests, the following steps are further included:

[0033] Feature extraction: Extract features from the request, and denote the extracted features as the first features, where the first features include the request source, request content, and request time;

[0034] Obtain historical data: Obtain historical requests and their corresponding priority labels;

[0035] Model construction: Based on a deep learning algorithm, construct a request classification model;

[0036] Second training: Based on the historical requests and their corresponding priority labels, construct a priority sample training set, input the priority samples into the request classification model for model inference, define a priority loss function, and iteratively optimize the request classification model by minimizing the priority loss function. Take the optimized request classification model as the new request classification model;

[0037] Request classification: Use the first features as the input of the request classification model, output the priority label of the request, and take the obtained priority label as the new priority of the request.

[0038] By adopting the above technical solution, extracting features for each request and constructing a request classification model based on a deep learning algorithm helps to more accurately judge the priority of each request. At the same time, the urgency and importance of the request are reflected by the request priority label, enabling high-priority requests to be processed first and reducing the situation where important requests are delayed. In addition, annotating the priority of the request can ensure that different types of requests are reasonably assigned to appropriate task queues according to their priorities, further optimizing the load scheduling of the system and reducing bottlenecks caused by overloading or excessive request queuing time in the system.

[0039] Optionally, after the step of performing load prediction and before the step of enqueuing requests, the following steps are further included:

[0040] Request quantity judgment: Within a preset waiting time, judge whether the request quantity is 1:

[0041] If so, execute the step of enqueuing requests;

[0042] If not, execute the step of parameter feature extraction;

[0043] Parameter feature extraction: Based on the user behavior data and request content corresponding to the request, extract request parameter features, where the request parameter features include user behavior data, request source, and request content;

[0044] Request similarity judgment: Use a fuzzy matching algorithm to calculate the similarity between the request parameter features of each request, denoted as the first similarity, and determine whether the first similarity is greater than a preset similarity threshold:

[0045] If so, merge the two requests with the first similarity and send the merged request to the temporary queue, and execute the steps of task scheduling;

[0046] If not, execute the step of enqueueing the request.

[0047] By adopting the above technical solution, the similarity between requests is calculated using a fuzzy matching algorithm, and requests with high similarity are merged and processed, reducing redundant calculations and resource occupancy when the system processes multiple similar requests, improving the throughput and response speed of the system, and helping to optimize the system performance. In addition, by merging similar requests, it helps to reduce the length of the request queue and reduce the problem of excessive load caused by repeated requests.

[0048] Optionally, after executing the step of request similarity judgment and before executing the step of task scheduling, it further includes:

[0049] Waiting for merging: After sending the merged request to the temporary queue, within a preset waiting time, determine whether there is a request whose first similarity to the above two requests is greater than the preset similarity threshold:

[0050] If so, send the request to the temporary queue and merge it with the above merged request, and then execute the steps of task scheduling;

[0051] If not, execute the steps of task scheduling.

[0052] By adopting the above technical solution, continue to monitor within the specified time whether there are new requests similar to the merged requests, and process the monitored similar requests together with the merged requests, which helps to reduce the processing of repeated requests, while reducing redundant calculations, optimizing the use of system resources, and improving the task processing efficiency. If there are no more similar requests within the specified time, directly enter the task scheduling stage, avoiding unnecessary waiting and delays. In addition, flexibly adjust the request merging strategy according to the time setting, which can not only maximize the benefits brought by request merging, but also enter the task scheduling stage as early as possible when the high-priority task queue needs a quick response.

[0053] Optionally, after executing the step of load prediction and before executing the step of enqueueing the request, it further includes:

[0054] First load judgment: Determine whether the load prediction data is lower than the preset load threshold;

[0055] If so, the token bucket algorithm is adopted to generate tokens at the first preset rate, and the traffic for processing requests by the task queue is set;

[0056] If not, the leaky bucket algorithm is adopted to set the traffic for processing requests by the task queue at the second preset rate.

[0057] By adopting the above technical solution, the current system load is judged based on the load prediction data, so that the system can select an appropriate traffic control strategy according to the high or low load. In the case of low load, the token bucket algorithm is adopted to make the request processing more flexible and efficient, which helps to improve the throughput capacity of the system and enables the system to process more requests when the load is low. When the system load is high, the leaky bucket algorithm is adopted to control the traffic at a constant rate, which helps to keep the system load within the preset processing capacity range, reduces the situation of system overload caused by too many requests in a short time, and improves the stability and reliability of the system.

[0058] In summary, the present application includes at least one of the following beneficial technical effects:

[0059] 1. Using the deep learning algorithm to construct a load prediction model can accurately predict the load changes at different time periods and request types, enabling the request processing to be dynamically adjusted according to the actual state of the system resources, thereby reducing the instability caused by static scheduling in the traditional method. In addition, by classifying and processing the priorities of requests, reasonable scheduling can be carried out according to the urgency and importance of requests, so that high-priority requests can be processed in a timely manner, improving the service quality and user experience of the system. At the same time, according to the load prediction results and the priorities of requests, the task distribution and scheduling link can intelligently allocate requests to appropriate processing nodes and thread pools, reducing the situation of overloading of some resources in the system, while ensuring load balancing, improving the stability and resource utilization rate of the system. Moreover, by dynamically adjusting the allocation of the task queue and processing nodes, the system can better adapt to the user request volume and load fluctuations, reducing the risk of system crashes and overloads, and enhancing the fault tolerance and stability of the system.

[0060] 2. Calculating the activity duration of historical game events and analyzing the lag time window of historical game events through the clustering algorithm can better identify the dynamic change characteristics of game events. The lag time window can capture the dynamic changes in the number of requests, helping the load prediction model understand the lag effect of each game event on the system load, so that the real-time and dynamic fluctuations of the system load are taken into account when predicting the load, and the prediction accuracy of the load prediction model in a dynamic high-concurrency environment is improved.

[0061] 3. The similarity between requests is calculated using a fuzzy matching algorithm, and requests with high similarity are merged, reducing redundant calculations and resource consumption when the system processes multiple similar requests, improving the system's throughput and response speed, and helping to optimize system performance. In addition, by merging similar requests, it helps to reduce the length of the request queue and the problem of excessive load caused by repeated requests. Brief Description of the Drawings

[0062] Figure 1 is the flowchart of Embodiment 1 of the present application;

[0063] Figure 2 is the flowchart of the first training of S4 in Embodiment 1 of the present application;

[0064] Figure 3 is the flowchart of the first classification of S53 in Embodiment 1 of the present application;

[0065] Figure 4 is the flowchart of the request merging of S54 in Embodiment 1 of the present application. Detailed Description of the Invention

[0066] The following is a further detailed description of the present application in conjunction with Figures 1 to 4 to further illustrate the present application in detail.

[0067] Embodiment 1: This embodiment discloses a method for concurrent processing of http request task queues based on the UE engine. As Figure 1 shown, the method includes: receiving requests sent by the user request side of the UE engine, setting request priorities according to the request time, collecting real-time operation data and historical operation data, constructing a load prediction model based on a deep learning algorithm, using the real-time operation data and the requests sent by the user request side as the input of the load prediction model, outputting load prediction data, classifying the received requests according to their priorities, sending the classified requests to the task queues corresponding to the request priorities, sorting the requests in each task queue based on the load prediction data, distributing tasks sequentially according to the sorting result, allocating the requests to the thread pools of the corresponding processing nodes for processing, and after the request processing is completed, sending a request response to the user request side. This embodiment includes the following steps:

[0068] S1 Request Receiving: Receiving requests sent by the user request side of the UE engine and setting request priorities according to the request time. The requests include request content, request load, request source, and request time.

[0069] Set up an HTTP server in the UE engine, receive requests sent by the user request side through the HTTP server, and set request priorities according to the chronological order of the request time.

[0070] The request includes the request content, request payload, request source, and request time. The request content is the requested resource, function, or behavior requirement by the user. For example, in a game, it may be the data resources requested by the user, operation requests (such as entering the game, loading a scene, submitting an operation, etc.). The request payload is the system resources such as computing, storage, or bandwidth required for the request. The request source includes the user's IP address, device type, and account information, etc. The request time is the actual timestamp when the request is issued.

[0071] S2 Data collection: It includes S21 collecting real-time operation data and S22 collecting historical operation data.

[0072] S21 Collecting real-time operation data: Collect real-time operation data, and the real-time operation data includes the user behavior data and game event data corresponding to the request. The user behavior data includes the user's operation data, behavior patterns, or the game scenes where the user is located, etc. The game event data includes game version update event data, game activity data, and game server update and maintenance data. The game activity data includes game special events and game promotion activities.

[0073] In this embodiment, the collection time of the real-time operation data is the same as the request time.

[0074] S12 Collecting historical operation data: Collect historical operation data, and the historical operation data includes historical requests, historical system resource data, historical user behavior data, and historical game event data.

[0075] The historical request includes the historical request content, historical request payload, historical request source, and historical request time. The historical system resource data is the historical system load. The historical user behavior data includes the user's historical operation data, historical behavior patterns, or historical game scenes where the user is located, etc. The historical game event data includes historical game version update event data, historical game activity data, and historical game server update and maintenance data. The historical game activity data includes historical game special events and historical game promotion activities. The historical user behavior data corresponds to the historical request.

[0076] In this embodiment, after collecting the real-time operation data and historical operation data, it is necessary to preprocess the data. The steps of the data preprocessing include data cleaning and data normalization.

[0077] Data cleaning: Perform operations such as denoising, handling missing values, and removing outliers on the collected real-time operation data and historical operation data.

[0078] Data normalization: Perform normalization processing on the collected real-time operation data and historical operation data.

[0079] S3 Build a model: Based on deep learning algorithms, use the long short-term memory network model as the basic model to build a load prediction model.

[0080] S4 First training: It includes S41 First data processing, S42 Second data processing, S43 Third data processing, S44 Fourth data processing, S45 Build a sample training set, and S46 Iterative optimization, as Figure 2 shown.

[0081] S41 First data processing: Align the historical user behavior data, historical requests, historical system resource data, and historical game event data in time to obtain the generation time of each historical game event data. Denote the historical user behavior data and historical requests before the generation time of each historical game event data as the first data, and denote the historical user behavior data and historical requests after the generation time of each historical game event data as the second data.

[0082] S42 Second data processing: Compare the first data with the second data in each time period in chronological order, denote it as the first difference, obtain the time corresponding to the second data whose first difference is less than the preset difference threshold, denote it as the end time of this historical game event data, and calculate the duration from the generation time to the end time of each historical game event data, denote it as the activity duration of this historical game event data.

[0083] S43 Third data processing: Use a clustering algorithm to cluster the activity durations of historical game event data, take the clustering result as the classification result of historical game event data, and take the activity duration of each category of historical game event data as the lag time window of this category of historical game event data.

[0084] In this embodiment, clustering algorithms such as the K-Means clustering algorithm can be used for clustering, or directly use the activity duration of each historical game event data as the classification criterion, group the historical game event data with the same activity duration into one group, and take the activity duration of each category of historical game event data as the lag time window of this category of historical game event data.

[0085] S44 Fourth data processing: According to the lag time window of each historical game event data, mark the historical user behavior data, historical requests, and historical system resource data corresponding to the lag time window of this historical game event with the lag time mark of this historical game event, and use the marked historical user behavior data, historical requests, and historical system resource data as the new historical user behavior data, new historical requests, and new historical system resource data.

[0086] S45 Build a sample training set: Based on the historical user behavior data, historical requests, historical system resource data, and historical game events, build a load sample training set.

[0087] S46 Iterative optimization: Use the load sample training set as the input of the load prediction model for model inference. Define the mean squared error loss function, calculate the loss value of the load prediction model, use the backpropagation algorithm to calculate the gradient of the model parameters of the load prediction model, and use the gradient descent method to update the model parameters of the load prediction model until the preset number of iterative training times is completed or the calculated loss value of the load prediction model no longer decreases. Complete the model training to obtain an optimized load prediction model, and use the optimized load prediction model as the new load prediction model.

[0088] The formula for the mean squared error loss function is as follows:

[0089] 。

[0090] Among them, represents the mean squared error loss function of the load prediction model, represents the number of samples in the load sample training set, represents the th actual system load of the sample, represents the load prediction data of the th sample predicted by the model.

[0091] S5 Load prediction: Includes S51 Fifth data processing and S52 Predicted load.

[0092] S51 Fifth data processing: Determine whether game event data exists in the real-time operation data.

[0093] If so, classify the game event data according to the classification result of the historical game event data, obtain the lag time window of the game event data according to the classification result of the game event data, label the lag time mark of the game event data for the user behavior data and the requests sent by the user request party in the real-time operation data according to the lag time window of the game event data, and use the marked user behavior data and requests as the new user behavior data and new requests to execute S52 Predicted load.

[0094] If not, do not process it and execute S52 Predicted load.

[0095] S52 Predicted load: Use the real-time operation data and the requests sent by the user request party as the input of the load prediction model, and output the load prediction data.

[0096] S6 Request enqueue: Classify according to the priority of the received requests, and send the classified requests to the task queues corresponding to the request priorities.

[0097] Classify according to the priority of the requests, group the requests with the same priority into one group, and then distribute them to the task queues corresponding to the request priorities in the order of the request times of the requests in each group.

[0098] S7 Task Scheduling: Sort the requests in each task queue based on the load prediction data.

[0099] Judge whether the load prediction data is higher than the preset load threshold. If so, re - sort the requests in each task queue in ascending order according to the request loads of each request. If not, do nothing.

[0100] S8 Task Distribution: According to the sorting result, distribute tasks sequentially, and allocate corresponding processing nodes for requests to process requests based on the load of each request and the load of the processing nodes, including S81 First Judgment, S82 Second Judgment, S83 Third Judgment, S84 First Allocation, and S85 Second Allocation.

[0101] S81 First Judgment: Judge whether the load prediction data is higher than the preset load threshold. If so, execute S82 Second Judgment; if not, execute S85 Second Allocation.

[0102] S82 Second Judgment: Obtain the load data of each processing node, and judge whether the load data of each processing node is higher than the preset node load threshold. If so, execute S83 Third Judgment; if not, execute S84 First Allocation.

[0103] S83 Third Judgment: Judge whether the number of threads in the thread pool of the current processing node has reached the maximum number of threads. If so, execute S84 First Allocation; if not, increase the number of threads in the thread pool of this processing node, and then execute S84 First Allocation.

[0104] S84 First Allocation: Sort based on the load data of each processing node in ascending order. According to the sorting result of the processing nodes, preferentially allocate requests to the high - priority task queue, and delay the processing of the medium - priority task queue and the low - priority task queue until the requests in the high - priority task queue are all allocated or the load prediction data is lower than the preset load threshold.

[0105] If the medium - priority task queue or the low - priority task queue has not been allocated a processing node within the preset delay time, adjust the requests in the medium - priority task queue or the low - priority task queue to the high - priority task queue for processing node allocation operations.

[0106] S85 Second Allocation: Use the weighted round - robin algorithm to allocate processing nodes for the requests in each task queue based on the load data of each processing node.

[0107] S9 Request Response: After the request is processed, a request response is sent to the user requester.

[0108] After the request is processed, a corresponding request response is generated. The request response includes the result of the request, the processing status (such as success or failure), or error information, etc. The request response is packaged and sent to the user requester through the HTTP protocol, and the request response status is recorded at the same time.

[0109] Example 1. In a multiplayer online game based on the UE engine, communication between the game client and the backend server is carried out through HTTP requests. The game server uses the HTTP request task queue concurrent processing method described in the above embodiment to process requests initiated by 5 players (such as entering the battlefield, loading the map, performing combat operations, etc.).

[0110] I. Receiving the player's request

[0111] Request from Player A (request to enter the battlefield):

[0112] Request content: Request to enter the battlefield and load the combat scene.

[0113] Request load: High load (computing load 5000ms, storage load 200MB, bandwidth load 1000KB / s).

[0114] Request source: The IP address of Player A is 192.168.1.101, the device is a personal computer, and the account information is userA_001.

[0115] Request time: 12:00:00.

[0116] Request from Player B (request to enter the battlefield):

[0117] Request content: Request to enter the battlefield and load the combat scene.

[0118] Request load: High load (computing load 5000ms, storage load 200MB, bandwidth load 1000KB / s).

[0119] Request source: The IP address of Player B is 192.168.1.102, the device is a personal computer, and the account information is userB_042.

[0120] Request time: 12:00:01.

[0121] Request from Player C (request to load the mall):

[0122] Request content: Request to load the mall page and view virtual items.

[0123] Request load: Medium load (computing load 500 ms, storage load 50 MB, bandwidth load 200 KB / s).

[0124] Request source: The IP address of Player C is 192.168.1.105, the device is a personal computer, and the account information is userC_302.

[0125] Request time: 12:00:02.

[0126] Request from Player D (request to view battle records):

[0127] Request content: Request to view personal battle history records.

[0128] Request load: Low load (computing load 100 ms, storage load 10 MB, bandwidth load 50 KB / s).

[0129] Request source: The IP address of Player D is 192.168.1.107, the device is a personal computer, and the account information is userD_215.

[0130] Request time: 12:00:03.

[0131] Request from Player E (request for character upgrade):

[0132] Request content: Request to perform a character upgrade and submit the operation.

[0133] Request load: Low-high load (computing load 200 ms, storage load 20 MB, bandwidth load 100 KB / s).

[0134] Request source: The IP address of Player E is 192.168.1.110, the device is a mobile phone, and the account information is userE_511.

[0135] Request time: 12:00:04.

[0136] After the system receives 5 requests, it sets priorities for each request according to the request time. The priorities from high to low are the requests of Player A, Player B, Player C, Player D, and Player E. The requests of Player A and Player B are high-priority, the requests of Player C and Player D are medium-priority, and the request of Player E is low-priority.

[0137] II. Collect players' behavior data and game event data

[0138] Behavior data of Player A: Enter the battlefield, load the scene, and execute the battle.

[0139] Behavior data of Player B: Enter the battlefield, load the battle scene, and execute the mission.

[0140] Behavior data of Player C: View the mall and purchase virtual items.

[0141] Behavior data of Player D: View battle records and query historical quests.

[0142] Behavior data of Player E: Character level up and submit operation requests.

[0143] The current in-game event is the "Double Experience" event. Players will receive double experience rewards for participating in battles during the event.

[0144] III. Predict the current system load

[0145] At this time, there is in-game event data for the "Double Experience" event. Classify the current in-game event according to the classification results of historical in-game event data. Based on the obtained classification results, label the lag time window corresponding to the current in-game event for the player behavior data and player requests. Use the labeled player behavior data and player requests as the new player behavior data and new player requests and input them into the load prediction model to obtain the system load prediction data.

[0146] IV. Classify player requests, send them to the corresponding task queues, and perform task scheduling.

[0147] Classify according to the priority of the requests. Send the requests of Player A and Player B to the high-priority task queue, send the requests of Player C and Player D to the medium-priority task queue, and send the request of Player E to the low-priority task queue.

[0148] Assume that the system load prediction data is higher than the preset load threshold. Sort the requests in each task queue in ascending order according to the request load of each request. At this time, since the request loads of Player A and Player B are the same, they are still sorted according to the request time. The order in the high-priority task queue is the request of Player A, the request of Player B. The order in the medium-priority task queue is the request of Player D, the request of Player C.

[0149] V. Allocate processing nodes for the requests. After the request processing is completed, send a request response to the player who sent the request.

[0150] Obtain the load data of each processing node and determine that the load data of each processing node is lower than the preset node load threshold.

[0151] First, allocate processing nodes for the requests of player A in the high-priority task queue, and then allocate processing nodes for the requests of player B. After the allocation of requests in the high-priority task queue is completed, and after the requests in the high-priority task queue are completed within the preset delay time, start to allocate processing nodes for the requests of player D in the medium-priority task queue, and then allocate processing nodes for the requests of player C in the medium-priority task queue. Finally, allocate processing nodes for the requests of player E in the low-priority task queue.

[0152] After the request processing is completed, generate request responses for each request and send the request responses to the players. Send "Loading successful, enter the battle" to player A and player B, send "Loading successful, browse items" to player C, send "Query successful, display historical battles" to player D, and send "Level up successful, upgrade the character level" to player E.

[0153] Embodiment 2: The differences from Embodiment 1 are as follows:

[0154] As Figure 3 shown, after performing S5 load prediction and before performing S6 request enqueueing, it also includes S53 first classification. S53 first classification includes: S531 feature extraction, S532 obtaining historical data, S533 model construction, S534 second training, and S535 request classification.

[0155] S531 feature extraction: Extract features from the request, and record the extracted features as the first features. The first features include the request source, request content, and request time.

[0156] S532 obtaining historical data: Includes S5321 obtaining historical requests and S5322 first marking.

[0157] S5321 obtaining historical requests: Obtain historical requests from the collected historical operation data.

[0158] Historical requests include historical request content, historical request load, historical request source, and historical request time.

[0159] S5322 first marking: Manually label priority tags for historical requests according to the timeliness and interactivity of historical request content.

[0160] S533 model construction: Based on the deep learning algorithm, use the support vector machine model as the basic model of the request classification model to construct the request classification model.

[0161] S534 Second Training: Construct a priority sample training set based on historical requests and corresponding priority labels, input the priority sample training set into the request classification model for model inference, define the priority loss function as the Hinge loss function, iteratively optimize the request classification model by minimizing the priority loss function, and use the optimized request classification model as the new request classification model.

[0162] S535 Request Classification: Use the first feature as the input of the request classification model, output the priority label of the request, and use the obtained priority label as the new priority of the request.

[0163] In this embodiment, feature extraction is performed on each request and a request classification model is constructed based on deep learning algorithms, which helps to more accurately determine the priority of each request. At the same time, the urgency and importance of the request are reflected by the request priority label, enabling high-priority requests to be processed first and reducing the situation where important requests are delayed. In addition, annotating the priority of the request can ensure that different types of requests are reasonably assigned to appropriate task queues according to their priorities, further optimizing the system's load scheduling and reducing bottlenecks caused by overloading or excessive request queuing time in the system.

[0164] Embodiment 3: The differences from Embodiment 1 are as follows:

[0165] As Figure 4 shown, after performing S5 load prediction and before performing S6 request enqueueing, it further includes S54 request merging. S54 request merging includes: S541 request quantity judgment, S542 parameter feature extraction, S543 request similarity judgment, and S544 waiting for merging.

[0166] S541 Request Quantity Judgment: Judge whether the number of requests is 1 within a preset waiting time.

[0167] If so, perform S6 request enqueueing.

[0168] If not, perform S542 parameter feature extraction.

[0169] S542 Parameter Feature Extraction: Based on the user behavior data and request content corresponding to the request, extract request parameter features. The request parameter features include user behavior data, request source, and request content.

[0170] S543 Request Similarity Judgment: Use a fuzzy matching algorithm to calculate the similarity between the request parameter features of each request, denoted as the first similarity, and judge whether the first similarity is greater than a preset similarity threshold.

[0171] If so, merge the two requests with the first similarity and send the merged request to the temporary queue, then execute S544 to wait for merging.

[0172] If not, execute the step of enqueuing the S6 request.

[0173] In this embodiment, algorithms such as cosine similarity or Jaccard similarity can be used to calculate the similarity between the request parameter features of each request.

[0174] S544 Wait for merging: After sending the merged request to the temporary queue, within the preset waiting time, determine whether there is a request whose first similarity to the above two requests is greater than the preset similarity threshold.

[0175] If so, send this request to the temporary queue to merge with the above merged request, and then execute S7 task scheduling.

[0176] If not, execute the step of S7 task scheduling.

[0177] After executing S7 task scheduling to S8 task distribution, when executing S9 request response, send the request response to each user requester of the merged request respectively.

[0178] In this embodiment, the priority of the temporary queue is the priority corresponding to the request with the highest priority among the merged requests.

[0179] In this embodiment, a fuzzy matching algorithm is used to calculate the similarity between requests, and requests with high similarity are merged, reducing redundant calculations and resource occupation when the system processes multiple similar requests, improving the throughput and response speed of the system, and helping to optimize the system performance. In addition, by continuously monitoring within the specified time whether there are new requests similar to the merged requests, and processing the monitored similar requests together with the merged requests, it helps to reduce the processing of duplicate requests, reduces redundant calculations, optimizes the use of system resources, and improves the task processing efficiency. If there are no more similar requests within the specified time, it directly enters the task scheduling stage, reducing unnecessary waiting and delays.

[0180] Embodiment 4: The differences from Embodiment 1 are as follows:

[0181] After executing S5 load prediction and before executing S6 request enqueueing, it also includes S55 first load judgment.

[0182] S55 First load judgment: Judge whether the load prediction data is lower than the preset load threshold.

[0183] If so, use the token bucket algorithm to generate tokens at the first preset rate and set the traffic for the task queue to process requests.

[0184] If not, the leaky bucket algorithm is adopted to set the traffic for processing requests in the task queue at a second preset rate.

[0185] In this embodiment, the current system load is judged based on the load prediction data, enabling the system to select an appropriate traffic control strategy according to the level of the load. In the case of a relatively low load, the token bucket algorithm is adopted to make the request processing more flexible and efficient, which helps to improve the throughput capacity of the system and enables the system to process more requests when the load is low. When the system load is high, the leaky bucket algorithm is adopted to control the traffic at a constant rate, which helps to keep the system load within the preset processing capacity range, reduces the situation of system overload caused by too many requests in a short period of time, and improves the stability and reliability of the system.

[0186] The above are all the preferred embodiments of this application. The protection scope of this application is not limited accordingly. Therefore, all equivalent changes made according to the structure, shape, and principle of this application shall be covered within the protection scope of this application.

Claims

1. A concurrent processing method for http request task queue based on UE engine, characterized in that: include: Request reception: Receives requests sent by the user requester of the UE engine and sets the request priority according to the request time; The request includes request content, request payload, request source and request time; Data collection: including collecting real-time operation data and collecting historical operation data; Collect real-time operation data: Collect real-time operation data, which includes user behavior data and game event data corresponding to the request; Collect historical operation data: Collect historical operation data, including historical requests, historical system resource data, historical user behavior data, and historical game event data; Model building: Build a load prediction model based on deep learning algorithms; Load prediction: Use real-time operation data and requests sent by user requesters as inputs to the load prediction model, and output load prediction data; Request queuing: Classify the received requests according to their priorities and send the classified requests to the corresponding request priority task queue; Task scheduling: Sort requests in each task queue based on load forecast data; Task distribution: Distribute tasks in order according to the sorting results, and assign corresponding processing nodes to the requests for processing according to the load of each request and the load of the processing node; Request response: After the request is processed, a request response is sent to the user requester.

2. According to the UE engine-based http request task queue concurrent processing method according to claim 1, it is characterized in that: After executing the step of building the model and before executing the step of load prediction, it also includes: First data processing: Time-aligning historical user behavior data, historical requests, historical system resource data, and historical game event data, obtaining the generation time of each historical game event data, recording the historical user behavior data and historical requests before the generation time of each historical game event data as first data, and recording the historical user behavior data and historical requests after the generation time of each historical game event data as second data; Second data processing: compare the first data with the second data of each time period in chronological order, record it as the first difference, obtain the time corresponding to the second data when the first difference is less than the preset difference threshold, record it as the end time of the historical game event data, calculate the duration from the generation time to the end time of each historical game event data, record it as the activity duration of the historical game event data; The third data processing: clustering the activity duration of the historical game event data using a clustering algorithm, taking the clustering result as the classification result of the historical game event data, and taking the activity duration of each type of historical game event data as the lag time window of the historical game event data of that type; Fourth data processing: according to the lag time window of each historical game event data, marking the historical user behavior data, historical request and historical system resource data corresponding to the lag time window of the historical game event data with the lag time mark of the historical game event, and using the marked historical user behavior data, historical request and historical system resource data as new historical user behavior data, new historical request and new historical system resource data; Build sample training sets: Build load sample training sets based on historical user behavior data, historical requests, historical system resource data, and historical game events; Iterative optimization: Define the mean square error loss function, use the load sample training set as the input of the load prediction model, perform model inference, iteratively optimize the load prediction model by minimizing the mean square error loss function, and use the optimized load prediction model as the new load prediction model.

3. The method for concurrently processing http request task queues based on UE engine according to claim 2, characterized in that: After the step of performing iterative optimization and before the step of performing load prediction, the following steps are also included: Fifth data processing: determine whether game event data exists in the real-time running data: If so, the game event data is classified according to the classification result of the historical game event data, and the lag time window of the game event data is obtained according to the classification result of the game event data. The user behavior data in the real-time operation data and the request sent by the user requester are marked with the lag time mark of the game event data according to the lag time window of the game event data, and the marked user behavior data and request are used as new user behavior data and new request to perform the load prediction step; If not, no processing is performed and the load prediction step is executed.

4. The method for concurrently processing http request task queues based on UE engine according to claim 1, characterized in that: After the load prediction step and before the request enqueue step, the following steps are also included: Feature extraction: extracting features from the request, and recording the extracted features as first features, wherein the first features include request source, request content, and request time; Get historical data: Get historical requests and corresponding priority tags; Model construction: Build a request classification model based on deep learning algorithms; Second training: Build a priority sample training set based on historical requests and corresponding priority labels, input the priority samples into the request classification model for model inference, define the priority loss function, iteratively optimize the request classification model by minimizing the priority loss function, and use the optimized request classification model as the new request classification model; Request classification: The first feature is used as the input of the request classification model, the priority label of the request is output, and the obtained priority label is used as the new priority of the request.

5. The method for concurrently processing http request task queues based on UE engine according to claim 1, characterized in that: After the load prediction step and before the request enqueue step, the following steps are also included: Request quantity judgment: within the preset waiting time, judge whether the request quantity is 1: If so, execute the step of requesting to join the queue; If not, then the step of parameter feature extraction is performed; Parameter feature extraction: Extract request parameter features based on the user behavior data and request content corresponding to the request. Request parameter features include user behavior data, request source, and request content. Request similarity judgment: Use the fuzzy matching algorithm to calculate the similarity between the request parameter features of each request, record it as the first similarity, and judge whether the first similarity is greater than the preset similarity threshold: If yes, the two requests of the first similarity are merged, the merged request is sent to the temporary queue, and the task scheduling step is performed; If not, execute the step of requesting to enqueue.

6. The method for concurrently processing http request task queues based on UE engine according to claim 5, characterized in that: After executing the step of requesting similarity determination and before executing the step of task scheduling, the method further includes: Waiting for merging: After sending the merged request to the temporary queue, within the preset waiting time, determine whether there is a request whose first similarity with the above two requests is greater than the preset similarity threshold: If yes, the request is sent to a temporary queue and merged with the above merged request, and then the task scheduling step is performed; If not, execute the task scheduling steps.

7. The method for concurrently processing http request task queues based on UE engine according to claim 1, characterized in that: After the load prediction step and before the request enqueue step, the following steps are also included: First load judgment: judging whether the load prediction data is lower than a preset load threshold; If so, a token bucket algorithm is used to generate tokens at a first preset rate, and a flow rate of the task queue processing request is set; If not, the leaky bucket algorithm is used to set the flow of the task queue processing request at a second preset rate.

Images