Request processing method and device, computer system, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a request processing method and device, a computer system, electronic equipment and a storage medium, and the method is applied to a sending end in a batch request mode, and comprises the steps: obtaining a to-be-sent batch request, and determining a corresponding application scene, which is a scene for generating each request in the batch request; when the requests generated in the determined application scene are mutually independent and the sending end request processing task of the determined application scene supports stage division, grouping the requests to obtain each group of request combinations; the sending end request processing task is used for processing a request generated by the determined application scene; processing each request in each group of request combinations in an assembly line mode by utilizing an execution unit for executing each sending end stage task; and sending the processed processing result. According to the technical scheme provided by the embodiment of the invention, the request processing efficiency and performance of the sending end in the batch request mode can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a request processing method, apparatus, computer system, electronic device, and storage medium. Background Technology

[0002] Burst mode (batch request mode) is an optimized processing flow that allows the user layer to encapsulate multiple requests using the same algorithm into an array, forming a batch request. The batch request is then sent to the sending driver for processing. The driver executes the request processing task, processing each request in the batch sequentially and finally returning the processing result, thereby improving overall processing efficiency.

[0003] When the number of requests in a batch request is large, the sending end suffers from low request processing efficiency and performance. Therefore, how to provide a technical solution to improve the request processing efficiency and performance of the sending end in batch request mode has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a request processing method, apparatus, computer system, electronic device, and storage medium to improve the request processing efficiency and performance of the sending end in batch request mode.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions.

[0006] In a first aspect, embodiments of the present invention provide a request processing method, applied to a sending end in a batch request mode, comprising: Get the batch requests to be sent; The corresponding application scenario is determined based on the batch requests to be sent, and the application scenario is the scenario in which each request in the batch requests is generated. When the requests generated by the determined application scenario are independent of each other, and the sending end request processing task of the determined application scenario supports stage division, the requests in the batch requests to be sent are grouped to obtain the request combinations; the sending end request processing task is used to process the requests generated by the determined application scenario. By utilizing the execution units of each sending end stage task after the sending end request processing task is divided, each request in each group of request combinations is processed in a pipeline manner. Send the processed results.

[0007] Secondly, embodiments of the present invention provide a request processing method, applied to a receiving end in a batch request mode, comprising: Receive batch requests to be processed, the batch requests to be processed including: the processed results sent by the request processing method as described in the first aspect; The application scenario corresponding to the batch requests to be processed is determined, and the processing result is processed using the receiving end request processing task of the determined application scenario; the receiving end request processing task is used to process the requests generated by the determined application scenario.

[0008] Thirdly, embodiments of the present invention provide a request processing apparatus, applied to a sending end in a batch request mode, comprising: The batch request acquisition module is used to acquire batch requests to be sent. The application scenario determination module is used to determine the corresponding application scenario based on the batch requests to be sent, wherein the application scenario is the scenario in which each request in the batch requests is generated. The request segmentation module is used to group the requests in the batch requests to be sent into groups when the requests generated in the determined application scenario are independent of each other and the sending end request processing task of the determined application scenario supports stage segmentation. The sending end request processing task is used to process the requests generated in the determined application scenario. The pipeline processing module is used to process each request in each group of requests in a pipeline manner by utilizing the execution units of each sending stage task after the sending end request processing task is divided. The sending module is used to send the processed results.

[0009] Fourthly, embodiments of the present invention provide a request processing apparatus, applied to a receiving end in a batch request mode, comprising: A batch request receiving module is used to receive batch requests to be processed, the batch requests to be processed including: the processed results sent by the request processing device as described in the third aspect; The processing module is used to determine the application scenario corresponding to the batch requests to be processed, and to process the processing results using the receiving end request processing task of the determined application scenario; the receiving end request processing task is used to process the requests generated by the determined application scenario.

[0010] Fifthly, embodiments of the present invention provide a computer system, comprising: The request processing apparatus for the sending end in the batch request mode as described in the third aspect; The request processing apparatus for the receiving end in batch request mode as described in the fourth aspect.

[0011] In a sixth aspect, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a program, and the processor calls the program stored in the memory to execute the request processing method as described in the first aspect, or to execute the request processing method as described in the second aspect.

[0012] In a seventh aspect, embodiments of the present invention provide a storage medium storing a program that, when executed, implements the request processing method as described in the first aspect, or implements the request processing method as described in the second aspect.

[0013] Eighthly, embodiments of the present invention provide a computer program product, including a computer program that, when executed by a processor, implements the request processing method as described in the first aspect, or implements the request processing method as described in the second aspect.

[0014] This invention provides a request processing method applied to a sending end in a batch request mode, comprising: acquiring a batch of requests to be sent; determining a corresponding application scenario based on the batch of requests to be sent, wherein the application scenario is the scenario that generates each request in the batch of requests; when the requests generated by the determined application scenario are independent of each other, and the sending end request processing task of the determined application scenario supports stage division, grouping each request in the batch of requests to be sent to obtain each group of request combinations; the sending end request processing task is used to process the requests generated by the determined application scenario; using the execution units of each sending end stage task after the sending end request processing task is divided, processing each request in each group of request combinations in a pipeline manner; and sending the processed result.

[0015] The technical solution provided in this embodiment of the invention addresses the issue that, in the Burst mode, the sending end acquires batch requests formed by various requests generated under different application scenarios using Burst mode. The sending end can then send these batch requests to its driver, enabling the driver to execute the sending end's request processing task and process each request in the batch sequentially. Therefore, when the number of requests in a batch is large, the execution time of the sending end's request processing task is long, impacting the sending end's request processing performance and efficiency. To address this, the technical solution provided in this embodiment of the invention improves the processing method for each request in a batch by determining the application scenario corresponding to the batch request before executing the sending end's request processing task to process each request in the batch sequentially. By determining whether the requests generated by the application scenario are independent of each other, it can be ensured that during the subsequent pipelined processing of each request, the requests in each request group will not result in errors due to dependencies between requests. Simultaneously, it is determined whether the sending-end request processing task (which can process the various requests generated by the application scenario) supports stage division, so that the pipelined approach can be implemented to process each request in each request group in a pipelined manner. When it is determined that the sending-end request processing task supports stage division and that the requests are independent of each other, the execution units of each sending-end stage task after the sending-end request processing task division can be used to process each request in each request group in a pipelined manner. This ensures that each execution unit is active throughout the overall process of processing batch requests, thereby achieving the effect of parallel processing of a large number of requests and improving the performance and efficiency of sending-end request processing. Attached Figure Description

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

[0017] Figure 1 This is a flowchart illustrating a request processing method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the process of executing an instruction without using CPU pipelining. Figure 3 This is a schematic diagram illustrating the process of executing a single instruction using a CPU pipeline. Figure 4This is another flowchart illustrating the request processing method provided in this embodiment of the invention; Figure 5 This is a schematic diagram illustrating the implementation process of data encryption under SM4-CBC mode; Figure 6 This is a schematic diagram illustrating the implementation process of data encryption in SM4-CBC mode using a pipeline approach; Figure 7 This is another flowchart illustrating the request processing method provided in this embodiment of the invention; Figure 8 This is a schematic diagram illustrating the implementation process of data decryption in SM4-CBC mode; Figure 9 This is a diagram illustrating the data decryption process for processing a request using a pipeline approach. Figure 10 This is a schematic diagram of a process in which the sending end processes batch requests in a pipeline manner, as provided in an embodiment of the present invention. Figure 11 This is a schematic diagram of the structure of a request processing device provided in an embodiment of the present invention; Figure 12 This is another structural schematic diagram of the request processing device provided in the embodiments of the present invention; Figure 13 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0019] As mentioned in the background, the Burst pattern is an optimization process that can be used to optimize data transmission or processing methods. Its core is to improve efficiency and reduce system overhead by batch processing multiple requests or data units.

[0020] The Burst pattern is widely used in many applications, including network communication, audio and video processing, hardware acceleration, and power management. In this way, the Burst pattern can significantly improve the overall performance and efficiency of the system.

[0021] In Burst mode, requests from different application scenarios are encapsulated into batch requests, which are then sent to the sending end's driver. When executing batch requests, the sending end's driver typically executes each request sequentially; however, some application scenarios do not support parallel processing of individual requests.

[0022] Therefore, even if the request processing task itself supports stage division, the different processing characteristics of requests generated in different application scenarios will cause the execution unit used to execute each sending stage task in the sending driver to be underworked when executing each request. This will prevent the advantages of the pipelined approach from being realized, resulting in low efficiency of the sending end in processing batch requests.

[0023] To address the aforementioned issues, embodiments of the present invention provide a request processing method that enables the sending end to quickly process individual requests in a batch of requests in Burst mode, fully leveraging the advantages of the pipeline approach to improve the performance and efficiency of the sending end in processing requests.

[0024] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a request processing method provided in an embodiment of the present invention. The method is applied to the sending end in a batch request mode.

[0025] like Figure 1 As shown, the method includes the following steps: Step S101: Obtain the batch requests to be sent.

[0026] The batch requests to be sent are a set of requests formed by encapsulating various requests generated in a certain application scenario under the Burst mode.

[0027] The process of forming batch requests can be described as follows: In Burst mode, an application scenario generates multiple requests, each containing specific data and operation instructions. These requests are then encapsulated into a batch, and the encapsulation process may include: Data packaging: Organizing the requested data into a contiguous block of data.

[0028] Add metadata: Add necessary metadata to each request, such as request length, priority, timestamp, etc.

[0029] Batch formation: Combining multiple requests into a logical set to form a batch of requests.

[0030] The encapsulated set of requests is called a batch request, which is sent and processed in Burst mode.

[0031] Step S102: Determine the corresponding application scenario based on the batch requests to be sent. The application scenario is the scenario in which each request in the batch requests is generated.

[0032] Based on the above introduction, it can be seen that there are various application scenarios for using the Burst pattern, and each application scenario will generate multiple requests that meet the specific requirements of that scenario. Therefore, when using the Burst pattern in this application scenario, each request can be encapsulated into a batch request based on the above encapsulation process and sent to the sending end. This allows the sending end to send the batch requests to its driver, and the driver can then execute the sending end's request processing task to process the batch requests.

[0033] For example, when determining the corresponding application scenario based on the batch requests to be sent, the application scenario can be determined according to the attribute characteristics of each request in the batch requests. The attribute characteristics are related to the application scenario and may include data volume, data type, request frequency, processing time window, resource requirements, etc.

[0034] Let's take the data volume of each request in a batch request as an example for illustration.

[0035] If the data volume of each request in a batch is small (e.g., a few hundred KB to a few MB), then each request may be generated in some lightweight application scenarios, such as: log upload: batch uploading locally generated log files to the server for analysis; configuration update: batch downloading or uploading configuration files.

[0036] If each request contains a large amount of data (e.g., tens of MB to several GB or even more), then the requests are likely generated in data-intensive application scenarios, such as: Big data processing: batch processing of massive amounts of log data, user behavior data, etc. File transfer: batch uploading or downloading large files, such as software installation packages, high-definition videos, etc. Backup and recovery: performing batch backup or recovery operations on databases or file systems.

[0037] Of course, the application scenario can also be determined based on other attribute characteristics of each request in the batch request, as long as the specific application scenario can be accurately identified.

[0038] Step S103: When the requests generated by the determined application scenario are independent of each other, and the sending end request processing task of the determined application scenario supports stage division, the requests in the batch requests to be sent are grouped to obtain the request combinations.

[0039] The sending end request processing task is used to process requests generated by the determined application scenario.

[0040] Different application scenarios generate requests with different attributes and characteristics, therefore, the request processing tasks used to handle requests with different attributes and characteristics are also different. Since request processing tasks are used to process individual requests within a batch of requests, and these individual requests are generated based on the application scenario, the appropriate sending-end request processing task for handling the requests generated by that application scenario can be determined.

[0041] The support for phase division in the sending end request processing task means that the overall implementation process of the sending end request processing task can be divided into multiple different and independent phases, so as to complete the complete execution of the sending end request processing task through phased processing.

[0042] After dividing the request processing task at the sending end into stages, we can obtain the task for each stage. Each stage task can be executed using the corresponding execution unit in the hardware structure, thereby realizing the pipelined execution of the request processing task at the sending end.

[0043] To better understand the phased execution of the above-mentioned request processing task at the sending end, you can refer to the implementation of the CPU (Central Processing Unit) pipeline method.

[0044] CPU pipelining is a method (or technique) that improves instruction execution efficiency by breaking down the complex instruction execution process into multiple stages (or "pipelines").

[0045] The internal circuitry of a CPU is divided into different functional units: instruction fetch unit, decode unit, execution unit, etc., and the complete execution of an instruction generally involves three steps in sequence: instruction fetch, decode, and execution.

[0046] Because instruction fetching, decoding, and execution occur sequentially during instruction execution—meaning the decoding unit must wait for the fetch unit to fetch the instruction before it can work, and the execution unit must wait for the decoding unit to complete decoding before it can begin working based on the decoding result—if a pipelined approach is not used for instruction execution, only one functional unit will be working per clock cycle, while the other two functional units will be waiting. Please refer to [reference needed]. Figure 2 , Figure 2 This is a schematic diagram illustrating the process of executing an instruction without using CPU pipeline.

[0047] like Figure 2 As shown, when instruction execution is not processed in a pipelined manner, only one functional unit works in one clock cycle, while other functional units are idle, resulting in low resource utilization and low efficiency.

[0048] When using a pipelined approach to instruction execution, multiple functional units can simultaneously operate on different instructions. In other words, the pipelined approach decomposes the instruction execution process (the sending end requests a processing task) into multiple stages, and schedules different instructions for each stage, thereby achieving efficient utilization of functional units.

[0049] Please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating the process of executing a single instruction using a CPU pipeline.

[0050] like Figure 3 As shown, multiple functional units are working simultaneously on different instructions, ensuring that each functional unit is fully utilized with virtually no idle state, thereby improving resource utilization and overall instruction execution efficiency.

[0051] Figure 3 In the CPU pipelined approach shown, the overall process of instruction execution can be viewed as the sending end request processing task. The instruction execution process is divided into several stages: fetch, decode, and execute, which can be viewed as the various sending end stage tasks after the sending end request processing task is divided.

[0052] Therefore, in principle, the pipelined parallel processing method can be supported for request processing tasks that support phase division. However, in application scenarios using the Burst pattern, there are dependencies between the generated requests, and they are not independent of each other. Furthermore, the driver processes each request serially, which prevents the full utilization of the pipelined approach and results in low efficiency for the sender in processing batch requests.

[0053] In this embodiment of the invention, for situations where the sending end request processing task supports stage division and the various requests generated in this application scenario are independent of each other, the method of executing batch requests is improved. The advantages of pipelined processing are fully utilized; that is, instead of executing each request in the batch request sequentially, the pipelined approach achieves the effect of parallel processing of each request. This ensures that the execution unit (functional unit) executing each sending end stage task is essentially never idle, improving the performance and efficiency of the sending end in processing batch requests.

[0054] Step S104: Using the execution units of each sending end stage task after the sending end request processing task is divided, each request in each group of request combinations is processed in a pipeline manner.

[0055] Since it has been determined that the sending end request processing task supports stage division, that is, the sending end request processing task can be divided into independent stages as described above in the CPU pipeline method. Each stage processes one task (the sending end stage task), and the sending end stage tasks are sequential. This ensures that the execution unit executing each sending end stage task is basically in a working state within different clock cycles, giving full play to the advantages of the pipeline method and improving the performance and efficiency of the sending end in processing batch requests.

[0056] Step S105: Send the processed result.

[0057] As can be seen, the technical solution provided in this embodiment of the invention, because the sending end in the batch request mode (Burst mode) obtains batch requests formed by various requests generated in different application scenarios using Burst mode, can send the batch requests to the sending end's driver, allowing the driver to execute the sending end's request processing task and process each request in the batch request sequentially. Therefore, when the number of individual requests included in the batch request is large, the execution time of the sending end's request processing task is long, affecting the sending end's request processing performance and efficiency. Based on this, the technical solution provided in this embodiment of the invention improves the processing method of each request included in the batch request, that is, before executing the sending end's request processing task to process each request in the batch request sequentially, the application scenario corresponding to the batch request is determined. By determining whether the requests generated by the application scenario are independent of each other, it can be ensured that during the subsequent pipelined processing of each request, the requests in each request group will not result in errors due to dependencies between requests. Simultaneously, it is determined whether the sending-end request processing task (which can process the various requests generated by the application scenario) supports stage division, so that the pipelined approach can be implemented to process each request in each request group in a pipelined manner. When it is determined that the sending-end request processing task supports stage division and that the requests are independent of each other, the execution units of each sending-end stage task after the sending-end request processing task division can be used to process each request in each request group in a pipelined manner. This ensures that each execution unit is active throughout the overall process of processing batch requests, thereby achieving the effect of parallel processing of a large number of requests and improving the performance and efficiency of sending-end request processing.

[0058] Since the request processing tasks on the sending end differ across different application scenarios, the number of stages supported by these tasks also varies. Therefore, in order to ensure that each request in each request combination can be processed correctly, the number of requests in each request combination can be determined based on the number of stages supported by the different sending end request processing tasks.

[0059] Please refer to Figure 4 , Figure 4 This is another flowchart illustrating the request processing method provided in this embodiment of the invention.

[0060] like Figure 4 As shown, the method includes the following steps: Step S201: Obtain the batch requests to be sent.

[0061] Step S202: Determine the corresponding application scenario based on the batch requests to be sent. The application scenario is the scenario in which each request in the batch requests is generated.

[0062] Step S203: In the case where the requests generated in the determined application scenario are independent of each other, and the sending end request processing task of the determined application scenario supports stage division, the batch requests to be sent are grouped according to the number of stages supported by the sending end request processing task to obtain the request combination of each group.

[0063] By dividing the request into groups based on the number of stages supported by the sending end's request processing task, the normal execution of requests within the request group can be ensured.

[0064] Step S204: Using the execution units of each sending end stage task after the sending end request processing task is divided, each request in each group of request combinations is processed in a pipeline manner.

[0065] Step S205: Send the processed result.

[0066] In one implementation, step S203 may include: The number of stages that the sending end request processing task supports is taken as the number of requests that can be processed at one time; based on the number of requests that can be processed, each request is divided and combined to obtain a group of requests; the number of requests in each group of requests is equal to or less than the number of requests that can be processed.

[0067] Based on the application scenario's requirements for hardware resources, the number of requests that can be processed at one time (request processing quantity) can be reasonably determined.

[0068] Once the supported request processing capacity is determined, the batch requests can be divided into individual requests based on this capacity. Since the total number of requests in the batch may not be an integer multiple of the processing capacity, some of the resulting request combinations will contain fewer requests than the processing capacity. For example, if the batch contains 50 requests, and the processing capacity is determined to be 4 based on hardware resource requirements, dividing the 50 requests into 13 request combinations will result in 12 combinations, each containing 4 requests, and one combination containing only 2 requests.

[0069] If the number of requests in a batch request is an integer multiple of the number of requests to be processed, then the number of requests in each group of requests after the batch is divided is equal to the number of requests to be processed.

[0070] To further optimize the performance and efficiency of the sending end in processing each group of requests, in one embodiment, before the step of dividing and combining each request based on the number of requests processed to obtain each group of requests, the method further includes: Sort the requests in ascending order based on their request length; The process of dividing and combining requests based on the number of requests processed to obtain various request combinations includes: In the ascending order of requests, each request is divided and combined based on the number of requests to be processed, resulting in various request combinations.

[0071] The length of a request directly affects processing time and resource requirements. By sorting and grouping requests, resource utilization can be optimized, waiting time can be reduced, and throughput can be increased.

[0072] In one implementation, the generated requests are independent of each other, and the application scenarios that support the phase division of the sending end request processing task include at least one of the following: vector packet processing scenario, high-performance audio processing scenario, and symmetric encryption scenario using random number generation to optimize instructions; each request in the batch requests to be sent includes at least one of the following: network data packet requests generated in the vector packet processing scenario, acoustic echo cancellation requests generated in the high-performance audio processing scenario, and data encryption requests generated in the symmetric encryption scenario.

[0073] In Vector Packet Processing (VPP) scenarios, each packet (or request) is typically independent; that is, the processing of one packet does not directly affect the processing of another. This is because network packet processing is generally stateless, meaning that the processing of each packet does not depend on the state of other packets. For example, the forwarding decision of a packet usually depends only on the packet's header information (such as IP address, port number, etc.) and is unrelated to other packets.

[0074] In packet processing scenarios, the generated requests can be requests that include the aforementioned network data packets (network data packet requests). In Burst mode, the batch requests received by the sender are formed from multiple network data packet requests. The sender then sends the batch requests to the driver, which executes the sender's request processing task. According to the scheme provided in this embodiment, the driver processes each network data packet request in the grouped request combinations, thereby accelerating the processing speed of network data packet requests.

[0075] In vector packet processing scenarios, the sender request processing task can be divided into stages. For example, the processing flow for each network data packet request (sender request processing task) can be divided into stages such as receiving, parsing, classification, forwarding decision, modification, queue management, sending, error handling, and statistics and monitoring. These stages are usually handled by different nodes. Each node can be regarded as an independent execution unit responsible for completing a specific sender stage task.

[0076] By dividing the sender request processing task into multiple stages, VPP can efficiently process large numbers of data packets, while leveraging pipelined and parallel processing capabilities to improve sender throughput and response speed.

[0077] Therefore, based on the above analysis of the vector packet processing scenario, when using the Burst mode to send various network data packet requests in batches, the technical solution provided in this embodiment of the invention can be adopted. First, the various network data packet requests are grouped, and then for each network data packet request in each group of requests, the execution unit (Node) is used to process them in a pipeline manner, thereby improving the request processing efficiency and performance of the sending end.

[0078] In high-performance audio processing scenarios, the individual acoustic echo cancellation requests are independent. Furthermore, considering requirements for real-time performance, resource management, and system optimization, the request processing tasks for each request are typically divided into stages. This improves the performance and efficiency of audio processing.

[0079] Take the AEC (Acoustic Echo Cancellation) algorithm optimized instruction set as an example in a high-performance audio processing scenario.

[0080] The AEC algorithm optimization instruction set is specifically designed for echo cancellation tasks in audio processing, significantly improving processing efficiency and performance. For example, some audio DSPs (Digital Signal Processors) provide dedicated instruction sets for common audio processing operations (such as FFT, filtering, etc.), which can further optimize performance.

[0081] In Burst mode, requests generated by the AEC algorithm in the instruction set optimization scenario are AEC requests (Acoustic Echo Cancellation Requests).

[0082] An AEC request may include the following: Input signals: typically the near-end signal (including echo) picked up by the microphone and the far-end reference signal (i.e., the audio signal sent from the far end).

[0083] Processing objective: To remove the echo component of the far-end signal from the near-end signal using an echo cancellation algorithm, while preserving clear near-end speech.

[0084] In Burst mode, when the driver processes each AEC request sequentially, the sending request processing task executed by the driver is usually divided into multiple stages, and each stage can be executed by different hardware units.

[0085] For example, in the scenario where the AEC algorithm optimizes the instruction set, the sending end request processing task supports stage division. This can mean that, assuming the AEC optimized instruction corresponds to three execution units on the hardware: value retrieval unit, decoding unit, and execution unit, there are multiple engines supporting staged processing to achieve parallel processing.

[0086] In other implementations, the sender request processing task in the AEC algorithm optimized instruction set scenario can also be divided as follows: Phase 1: Delay Estimation The task at this stage is to estimate the time delay that the far-end signal takes before reaching the microphone. Frequency domain autocorrelation is typically used to estimate this delay.

[0087] The hardware execution unit that performs this stage of the task is typically an audio DSP (Digital Signal Processor) or a dedicated audio processing unit.

[0088] Phase Two: Linear Echo Cancellation The task at this stage is to eliminate linear echoes using adaptive filters (such as PBFDAF, i.e., block frequency domain adaptive filters). For example, the filter coefficients can be updated using adaptive algorithms (such as NLMS, Normalized Least Mean Squares Algorithm) to minimize echoes.

[0089] The hardware execution unit that performs this stage of the task is typically an audio DSP or a dedicated audio processing unit, which usually supports an optimized audio processing instruction set.

[0090] Phase 3: Nonlinear Processing The next step is to process residual nonlinear echoes to further improve echo cancellation. For example, this can be achieved by using nonlinear filters to suppress residual echoes.

[0091] The hardware execution unit that performs this stage of the task is also executed by an audio DSP or a dedicated audio processing unit.

[0092] The use of random number generation optimization instructions in symmetric encryption scenarios refers to the use of random number generation optimization instructions (SM4 RND optimization instructions) in symmetric encryption scenarios (such as the SM4 block cipher algorithm).

[0093] In symmetric encryption scenarios that utilize optimized random number generation instructions, the data encryption process (sender request processing task) can be divided into independent stages, and each stage task can be executed using an independent hardware execution unit.

[0094] For example, the encryption / decryption function of the SM4 algorithm is an iterative operation of 32 rounds of round functions. The SM4 RND optimization instruction can implement the execution operation of each round of round functions. The SM4 RND optimization instruction can read a 128-bit (16-byte) data block at a time using the XMM register (eXtended MediaRegisters).

[0095] Executing one SM4 RND optimization instruction can complete one round of function flow, so executing 32 SM4 RND optimization instructions can complete the function operation of encrypting / decrypting 128 bits (16 bytes) of data.

[0096] The 32-round iterative operation of the SM4 algorithm is a relatively complex process, with each round involving linear transformations, nonlinear transformations, and table lookups. The SM4 RND optimization instruction divides this process into three steps, referred to as Operation 1, Operation 2, and Operation 3, which are physically implemented as three independent execution units. Each execution unit requires one clock cycle, meaning the SM4 RND optimization instruction requires three clock cycles. Therefore, the 32-round iterative operation requires 96 clock cycles.

[0097] In Burst mode, in symmetric encryption scenarios using random number generation to optimize instructions, during the data encryption process, when the sender's driver executes the sender request processing task (data encryption process) and processes each request sequentially, although the sender request processing task supports stage division, due to the limitation of the encryption processing of each request itself in the data encryption process: when encrypting two adjacent data blocks of a request, the encryption of the N+1th data block requires the encryption result of the Nth data block. Therefore, it is necessary to wait for the Nth data block to be encrypted before subsequent encryption processing can be performed, resulting in the independent execution unit having an idle state, which cannot fully utilize the performance and advantages of the pipeline approach.

[0098] Meanwhile, since each data encryption request is independent in the data encryption process, the method provided in this embodiment of the invention can be used to divide the requests in the batch request and process each request in each group of requests in a pipeline manner, so that each execution unit is in a working state, improving the working efficiency of each execution unit and improving the efficiency and performance of the sending end in processing each request.

[0099] In one implementation, the symmetric encryption scenario using random number generation optimization instructions includes at least one of the following: an encryption scenario in ciphertext feedback mode of a block cipher algorithm, an encryption scenario in output feedback mode of a block cipher algorithm, and an encryption scenario in cipher block chain mode of a block cipher algorithm.

[0100] For encryption scenarios in the ciphertext block chaining mode (SM4-CBC mode), the data encryption process for each data encryption request (sender request processing task) can be found in [reference needed]. Figure 5 , Figure 5 This is a schematic diagram illustrating the implementation process of data encryption under the SM4-CBC mode.

[0101] like Figure 5 As shown, the data encryption process includes the following: 1. Use a block of plaintext that has been split ( Figure 5The initialization vector (IV) of the same size as plaintext block 1, plaintext block 2, ..., plaintext block N is used to initialize the shift register.

[0102] 2. Perform an XOR operation between plaintext block 1 and the initialization vector to generate the XOR result.

[0103] 3. Encrypt the XOR result using the SM4 algorithm.

[0104] 4. Move the generated ciphertext into the shift register and repeat step 2 above (the XOR of subsequent plaintext blocks uses the encryption result of the previous plaintext block, i.e., the ciphertext block) to process the next plaintext block.

[0105] The encryption operation in step 3 refers to the iterative operation of the 32 rounds of round functions, which is the main processing part of the encryption process and occupies most of the overall processing time.

[0106] exist Figure 5 As shown in the encryption process, each plaintext block (plaintext block 2, ..., plaintext block N) must wait for the encryption of the previous plaintext block to finish before it can be processed. For example, the processing of plaintext block 2 requires waiting for the XOR and encryption processing of plaintext block 1 to obtain the ciphertext block 1' of plaintext block 1 before the encryption process for plaintext block 2 can begin. That is, the processing of plaintext block 1, plaintext block 2, ..., plaintext block N is performed serially. In other words, the sender request processing task executed in SM4-CBC mode does not support parallel processing of multiple plaintext blocks for a single data encryption request.

[0107] Therefore, even if the encryption scenario of SM4-CBC mode is optimized using random number optimization instructions, in Burst mode, when the driver executes each data encryption request serially, it cannot fully realize the advantages of the pipeline approach.

[0108] To better understand the data encryption request processing in an SM4-CBC mode encryption scenario using optimized instructions for random number generation in Burst mode, please refer to [reference needed]. Figure 6 , Figure 6 This is a schematic diagram illustrating the implementation process of data encryption in the SM4-CBC mode using a pipeline approach.

[0109] In the data encryption process of SM4-CBC mode, the driver processes each data encryption request serially. Figure 6 The following example illustrates the splitting of a data encryption request into three 128-bit data blocks: the Nth data block (Block N), the (N+1)th data block (Block N+1), and the (N+2)th data block (Block N+2).

[0110] like Figure 6 As shown, in clock cycle 1, operation 1 (XOR operation) processes Block N; in clock cycle 2, operation 2 (encryption operation) encrypts the XOR result of Block N; and in clock cycle 3, the encrypted result of Block N is output.

[0111] For Block N+1, operation 1 (XOR) will only begin after the XOR result of Block N is encrypted at the end of clock cycle 2. Similarly, Block N+2 needs to perform the XOR operation of operation 1 using the encrypted result of Block N+1 (the result obtained after operation 2 ends) in clock cycle 3.

[0112] As can be seen, in Burst mode, when the sending end (driver) encrypts each data encryption request, the data blocks of each data encryption request, which are executed serially, cannot be processed in parallel. However, the data encryption requests are independent of each other. Therefore, in Burst mode, the driver can group the batch requests it processes and then process each request in the group in parallel (that is, put multiple requests into different stages of the pipeline according to different processing stages, so as to realize that multiple requests are processed simultaneously).

[0113] The encryption scenarios under the SM4 Cipher Feedback Mode (SM4-CFB mode) and the SM4 Output Feedback Mode (SM4-OFB mode) of the block cipher algorithm have the same characteristics as the encryption scenarios under the SM4 Cipher Feedback Mode. Therefore, by adopting the technical solution provided in the embodiments of the present invention, the batch processing of requests in the Burst mode and the pipelined processing of each request in the combined grouped requests can be performed to improve the request processing efficiency and performance of the sending end.

[0114] When the application scenario is an encryption scenario in the cipher block chain mode of the block cipher algorithm, the step of taking the number of stages supported by the sending end request processing task as the number of requests that can be processed at one time includes: In the cipher block chain mode of the block cipher algorithm, the number of stages that the sending end requests to process is divided into is used as the number of requests that can be processed at one time, with the value being the second value. The process involves dividing and combining the requests in ascending order based on the number of requests processed, resulting in various request combinations, including: In the requests sorted in ascending order, each request is divided and combined based on the second value to obtain various request combinations.

[0115] The second value can be 3, meaning that 3 requests can be processed at once (in this scenario, data encryption requests). Since most current processors support a 20-stage pipeline, it is possible to prefetch all instructions corresponding to a 128-bit data block for each of the three requests. At the same time, since there is no data coupling between these three requests, they can be executed in parallel at the three stages of the pipeline.

[0116] Furthermore, the requests in the batch, after being sorted in ascending order (by request length), can be grouped into groups of 3 requests each, so that each request in each group can be processed in parallel at each sending stage.

[0117] To further optimize the processing efficiency of each request in the request combination at the sending end, in one implementation, processing rules can be defined for request combinations with different numbers of requests.

[0118] For example, in the case where the batch requests generated by the determined application scenario are independent of each other, and the sending end request processing task of the determined application scenario supports stage division, before the step of using the execution unit of each sending end stage task after executing the sending end request processing task division to process each request in each group of requests in a pipeline manner, the method further includes: Based on the number of requests in each request group, the processing rules for each request group are determined; the processing rules indicate the processing order of each request and the processing length range of the requests in the processing order. Step S104 includes: By utilizing the execution units of each sending end stage task after the sending end request processing task is divided, each request in each group of request combinations is processed in a pipeline manner according to the determined processing rules.

[0119] The processing rules indicate the processing order of each request in each request group and the specific processing length range of each request in the determined order, thereby avoiding unreasonable request processing planning that would affect the efficiency and performance of the sending end (driver) in processing each request.

[0120] Once the processing rules for each group of requests are determined, each request can be processed rationally according to the request rules to ensure that the sending end can have optimal processing performance.

[0121] In one implementation, the processing rules can be defined based on the request length to rationalize the processing of each request. In this case, determining the processing rules for each request combination based on the number of requests in each combination can include: For the first request combination where the number of requests is greater than the first value and equal to the number of requests to be processed, the first processing rule for each request is determined as follows: Among the request lengths of each request in the first request combination, the minimum request length is determined; each request is initially processed according to the minimum request length; and for requests whose request length is not the minimum request length, the remaining request length other than the minimum request length is processed. For a second request combination with a request quantity equal to the first value, the second processing rule for the requests in the second request combination is: process the requests directly.

[0122] The first value can be 1, and the first value is less than the second value (number of requests processed).

[0123] In the resulting request combinations, if the number of requests in a combination is greater than one and less than or equal to the second value, the first processing rule applies. Since each request combination contains multiple requests, there may be cases where the request lengths differ. While pipelining can process a portion of a new request each clock cycle, in some cases, shorter requests may still be delayed due to the presence of longer requests. This is due to pipeline fill and drain times. Therefore, prioritizing shorter requests reduces the system's average response time and increases throughput, preventing shorter requests from waiting for extended periods.

[0124] When the number of requests in the request combination is 1 (the first value), this single request can be executed directly, i.e., the second processing rule is used.

[0125] This invention also provides a request processing method, please refer to... Figure 7 , Figure 7 This is another flowchart illustrating the request processing method provided in this embodiment of the invention. The method is applied to the receiving end in batch request mode.

[0126] like Figure 7 As shown, the method includes the following steps: Step S300: Receive batch requests to be processed.

[0127] The batch requests to be processed include: the processed results sent by the request processing method as described in any of the foregoing embodiments.

[0128] After the sending driver processes the grouped batch requests, it can send the processed results to the receiving end. The receiving end also sends the received batch requests to its driver for processing.

[0129] Step S302: Determine the application scenario corresponding to the batch requests to be processed, and process the processing results using the receiving end request processing task of the determined application scenario.

[0130] The receiving end request processing task is used to process requests generated by the determined application scenario.

[0131] When the receiving end driver processes batch requests, it first determines the corresponding application scenario based on the batch requests, and then executes the receiving end request processing task applicable to that application scenario to process each batch request, so as to ensure the correct processing of the received batch requests.

[0132] When processing batch requests at the receiving end, the processing of each request itself is usually done in a pipeline manner.

[0133] For example, if the application scenario for batch requests processed at the sending end is a symmetric encryption scenario using random number generation to optimize instructions, then the corresponding application scenario at the receiving end is a decryption scenario using random number generation to optimize instructions, thus enabling the decryption operation of the encryption processing results sent by the sending end.

[0134] Taking the SM4-CBC symmetric decryption scenario, which uses random number generation to optimize instructions, as an example, the data decryption process at the receiving end can be referenced. Figure 8 , Figure 8 This is a schematic diagram illustrating the implementation process of data decryption under SM4-CBC mode.

[0135] like Figure 8 As shown, the "decryption" process in the data decryption flow is also an iterative operation of 32 rounds of round functions, which is the main processing part and occupies most of the processing time in the entire data decryption flow.

[0136] For the data decryption process in SM4-CBC mode using optimized random number generation instructions, 8 or 16 ciphertext blocks can be selected at once and decrypted simultaneously to obtain the decryption results of these 8 or 16 ciphertext blocks. Then, these 8 or 16 decryption results are sequentially XORed to obtain the corresponding plaintext blocks. This is compared to the data encryption process in SM4-CBC mode using optimized random number generation instructions (such as...). Figure 5 As shown, the algorithm for data decryption in SM4-CBC mode, which uses random number generation optimization instructions, supports parallel processing of each ciphertext block.

[0137] Therefore, when the receiving end driver executes the receiving end request processing task and processes the results of batch requests, a pipelined approach can be used. Please refer to [reference needed]. Figure 9 , Figure 9This is a diagram illustrating the data decryption process for a request, using a pipelined approach.

[0138] In the data decryption process of SM4-CBC mode using optimized random number generation instructions, when processing the Nth, N+1th, and N+2th 128-bit data blocks, such as... Figure 9 As shown, by using the SM4 RND optimization instruction, the iteration operation of the 32 rounds of the round function is optimized to only 96 clock cycles. The processor can prefetch all instructions corresponding to three adjacent 128-bit data blocks and execute them in parallel on three independent execution units with the help of pipeline technology, so that all three execution units of the SM4 RND instruction are in working state.

[0139] Compared to the data decryption process in SM4-CBC mode that uses optimized instructions for random number generation, such as Figure 6 As shown, the data encryption process in SM4-CBC mode, which uses random number generation to optimize instructions, can prefetch all instructions corresponding to three adjacent 128-bit data blocks and distribute them to three pipelines. However, due to the dependency between data blocks, only one request can be executed normally, while the other two will terminate due to reasons such as cache miss.

[0140] The data encryption process in SM4-CBC mode using optimized instructions with random number generation, as shown by performance data collected using perf (a performance analysis tool), exhibits a 3x improvement in cache miss rate and performance that is 1 / 3 that of the data decryption process in SM4-CBC mode using optimized instructions with random number generation. This results in lower efficiency and performance for the sending end in handling batch requests compared to the receiving end in Burst mode.

[0141] Therefore, the present invention adjusts the request processing method of the sending end in the batch request mode. By applying the pipeline method of data blocks to the processing of multiple requests in a group of requests, the sending end no longer processes each request in the batch request serially, but can process each request in the grouped batch request combination in a pipeline manner, thereby improving the efficiency and performance of the sending end in processing batch requests.

[0142] Please refer to Figure 10 , Figure 10 This is a schematic diagram of a process where the sending end processes batch requests in a pipeline manner, as provided in an embodiment of the present invention. Figure 10 We will continue to demonstrate the data encryption process in SM4-CBC mode using the SM4-RND optimized instructions.

[0143] like Figure 10As shown, in the sending driver, instead of reading one request from a batch request at a time using a loop, it reads each (e.g., 3) request from a group of requests at a time, thus allowing the three requests to be processed in a pipeline manner.

[0144] Suppose we read the Nth request (Req N), the N+1th request (Req N+1), and the N+2th request (Req N+2). Since most current processors support a 20-stage pipeline, we can prefetch all the instructions corresponding to a 128-bit data block for each of these three requests. Furthermore, since there is no data coupling between the data blocks of these three requests, they can be executed in parallel on the three execution units that perform encryption.

[0145] Therefore, for the data encryption process in SM4-CBC mode using the SM4-RND optimized instructions, all three execution units of the SM4-RND optimized instructions can be active simultaneously, resulting in a three-fold performance improvement. However, for the data decryption process in SM4-CBC mode using the SM4-RND optimized instructions, since no processing is performed, its performance remains unchanged. This allows for a performance balance between the data encryption and decryption processes in SM4-CBC mode using the SM4-RND optimized instructions.

[0146] As can be seen, the technical solution provided by the embodiments of the present invention improves the request processing efficiency and performance of the sending end by processing each request in the request combination in a pipeline manner. At the same time, the performance of the receiving end remains unchanged, so that the request processing efficiency and performance of the sending end can be balanced with that of the receiving end, avoiding a state where the sending end is busy and the receiving end is idle.

[0147] This invention also provides a request processing device, please refer to... Figure 11 , Figure 11 This is a schematic diagram of a request processing device provided in an embodiment of the present invention. The device is applied to the sending end in batch request mode.

[0148] like Figure 11 As shown, the request processing device 4 applied to the sending end in batch request mode may include: Batch request acquisition module 40 is used to acquire batch requests to be sent; Application scenario determination module 41 is used to determine the corresponding application scenario based on the batch requests to be sent, wherein the application scenario is the scenario in which each request in the batch requests is generated. The request segmentation module 42 is used to group each request in the batch of requests to be sent when the requests generated in the determined application scenario are independent of each other and the sending end request processing task of the determined application scenario supports stage segmentation, so as to obtain each group of request combinations; the sending end request processing task is used to process the requests generated in the determined application scenario. Pipeline processing module 43 is used to process each request in each group of requests in a pipeline manner by utilizing the execution units of each sending stage task after the sending end request processing task is divided. The sending module 44 is used to send the processed results.

[0149] As can be seen, the technical solution provided in this embodiment of the invention, because the sending end in the batch request mode (Burst mode) obtains batch requests formed by various requests generated in different application scenarios using Burst mode, can send the batch requests to the sending end's driver, allowing the driver to execute the sending end's request processing task and process each request in the batch request sequentially. Therefore, when the number of individual requests included in the batch request is large, the execution time of the sending end's request processing task is long, affecting the sending end's request processing performance and efficiency. Based on this, the technical solution provided in this embodiment of the invention improves the processing method of each request included in the batch request, that is, before executing the sending end's request processing task to process each request in the batch request sequentially, the application scenario corresponding to the batch request is determined. By determining whether the requests generated by the application scenario are independent of each other, it can be ensured that during the subsequent pipelined processing of each request, the requests in each request group will not result in errors due to dependencies between requests. Simultaneously, it is determined whether the sending-end request processing task (which can process the various requests generated by the application scenario) supports stage division, so that the pipelined approach can be implemented to process each request in each request group in a pipelined manner. When it is determined that the sending-end request processing task supports stage division and that the requests are independent of each other, the execution units of each sending-end stage task after the sending-end request processing task division can be used to process each request in each request group in a pipelined manner. This ensures that each execution unit is active throughout the overall process of processing batch requests, thereby achieving the effect of parallel processing of a large number of requests and improving the performance and efficiency of sending-end request processing.

[0150] This invention also provides a request processing device, please refer to... Figure 12 , Figure 12This is another structural schematic diagram of the request processing device provided in an embodiment of the present invention. The device is applied to the receiving end in batch request mode.

[0151] like Figure 12 As shown, the request processing device 5 applied to the receiving end in batch request mode may include: The batch request receiving module 50 is used to receive batch requests to be processed, the batch requests to be processed including: the processed results sent by the request processing device as described in the foregoing embodiments; The processing module 51 is used to determine the application scenario corresponding to the batch requests to be processed, and to process the processing result using the receiving end request processing task of the determined application scenario; the receiving end request processing task is used to process the requests generated by the determined application scenario.

[0152] As can be seen, the technical solution provided by the embodiments of the present invention improves the request processing efficiency and performance of the sending end by processing each request in the request combination in a pipeline manner. At the same time, the performance of the receiving end remains unchanged, so that the request processing efficiency and performance of the sending end can be balanced with that of the receiving end, avoiding a state where the sending end is busy and the receiving end is idle.

[0153] This invention also provides a computer system, please refer to... Figure 13 , Figure 13 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present invention.

[0154] like Figure 13 As shown, the computer system includes: The request processing device 4 applied to the sending end in the batch request mode as described in the foregoing embodiments; The request processing device 5 applied to the receiving end in the batch request mode as described in the foregoing embodiments.

[0155] As can be seen, the technical solution provided by the embodiments of the present invention improves the request processing efficiency and performance of the sending end by processing each request in the request combination in a pipeline manner. At the same time, the performance of the receiving end remains unchanged, so that the request processing efficiency and performance of the sending end can be balanced with that of the receiving end, avoiding a state where the sending end is busy and the receiving end is idle.

[0156] This invention provides an electronic device, such as a terminal device, a server device, or other computer device, including a memory and a processor. The memory stores a program, and the processor calls the program stored in the memory to execute a request processing method for a sending end in a batch request mode as described in any of the foregoing embodiments, or to execute a request processing method for a receiving end in a batch request mode as described in the foregoing embodiments.

[0157] This invention provides a storage medium storing a program that, when executed, implements a request processing method for a sending end in a batch request mode as described in any of the foregoing embodiments, or implements a request processing method for a receiving end in a batch request mode as described in the foregoing embodiments.

[0158] This invention provides a computer program product, including a computer program that, when executed by a processor, implements a request processing method for a sending end in a batch request mode as described in any of the foregoing embodiments, or implements a request processing method for a receiving end in a batch request mode as described in the foregoing embodiments.

[0159] The foregoing describes multiple embodiments of the present invention. The optional methods described in each embodiment can be combined and cross-referenced without conflict, thereby extending to a variety of possible embodiments. These can all be considered as embodiments disclosed or made public by the present invention.

[0160] While the embodiments of the present invention have been disclosed above, the present invention is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of the present invention; therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A request processing method, characterized in that, The sending end used in batch request mode includes: Get the batch requests to be sent; The corresponding application scenario is determined based on the batch requests to be sent, and the application scenario is the scenario in which each request in the batch requests is generated. When the requests generated by the determined application scenario are independent of each other, and the sending end request processing task of the determined application scenario supports stage division, the requests in the batch requests to be sent are grouped to obtain the request combinations; the sending end request processing task is used to process the requests generated by the determined application scenario. By utilizing the execution units of each sending end stage task after the sending end request processing task is divided, each request in each group of request combinations is processed in a pipeline manner. Send the processed results.

2. The request processing method as described in claim 1, characterized in that, When the requests generated in the defined application scenario are independent of each other, and the sending end request processing task of the defined application scenario supports stage division, the grouping of each request in the batch requests to be sent to obtain each group of request combinations includes: Based on the number of stages supported by the sending end's request processing task, the batch requests to be sent are grouped to obtain the request combinations of each group.

3. The request processing method as described in claim 2, characterized in that, The process involves grouping the batch requests to be sent according to the number of stages supported by the sending end's request processing task, resulting in various request combinations, including: The number of stages that the sending end request processing task supports is taken as the number of requests that can be processed at one time. Based on the number of requests processed, each request is divided and combined to obtain a group of requests; the number of requests in each group is equal to or less than the number of requests processed.

4. The request processing method as described in claim 3, characterized in that, Before the step of dividing and combining the requests based on the number of requests processed to obtain the request combinations, the method further includes: Sort the requests in ascending order based on their request length; The process of dividing and combining requests based on the number of requests processed to obtain various request combinations includes: In the ascending order of requests, each request is divided and combined based on the number of requests to be processed, resulting in various request combinations.

5. The request processing method as described in claim 4, characterized in that, The generated requests are independent of each other, and the application scenarios that support the phase division of the sending end request processing task include at least one of the following: vector packet processing scenario, high-performance audio processing scenario, and symmetric encryption scenario using random number generation to optimize instructions; each request in the batch requests to be sent includes at least one of the following: network data packet request generated by vector packet processing scenario, acoustic echo cancellation request generated by high-performance audio processing scenario, and data encryption request generated by symmetric encryption scenario.

6. The request processing method as described in claim 5, characterized in that, The symmetric encryption scenarios using random number generation optimization instructions include at least one of the following: encryption scenarios in the encryption feedback mode of block cipher algorithms, encryption scenarios in the output feedback mode of block cipher algorithms, and encryption scenarios in the cryptographic block chain mode of block cipher algorithms.

7. The request processing method as described in claim 6, characterized in that, When the application scenario is an encryption scenario in the cipher block chain mode of the block cipher algorithm, the step of taking the number of stages supported by the sending end request processing task as the number of requests that can be processed at one time includes: In the cipher block chain mode of the block cipher algorithm, the number of stages that the sending end requests to process is divided into is used as the number of requests that can be processed at one time, with the value being the second value. The process involves dividing and combining the requests in ascending order based on the number of requests processed, resulting in various request combinations, including: In the requests sorted in ascending order, each request is divided and combined based on the second value to obtain various request combinations.

8. The request processing method according to any one of claims 3-7, characterized in that, In cases where the batch requests generated by the defined application scenario are independent of each other, and the sending end request processing task of the defined application scenario supports stage division, before the step of using the execution unit of each sending end stage task after the execution of the sending end request processing task division to process each request in each group of requests in a pipeline manner, the method further includes: Based on the number of requests in each request group, the processing rules for each request group are determined; the processing rules indicate the processing order of each request and the processing length range of the requests in the processing order. The step of using the execution units of each sending-end stage task after the sending-end request processing task is divided to process each request in each group of request combinations in a pipeline manner includes: By utilizing the execution units of each sending end stage task after the sending end request processing task is divided, each request in each group of request combinations is processed in a pipeline manner according to the determined processing rules.

9. The request processing method as described in claim 8, characterized in that, The process of determining the processing rules for each request combination based on the number of requests in each request combination includes: For the first request combination where the number of requests is greater than the first value and equal to the number of requests to be processed, the first processing rule for each request is determined as follows: Among the request lengths of each request in the first request combination, the minimum request length is determined; each request is initially processed according to the minimum request length; and for requests whose request length is not the minimum request length, the remaining request length other than the minimum request length is processed. For a second request combination with a request quantity equal to the first value, the second processing rule for the requests in the second request combination is: process the requests directly.

10. A request processing method, characterized in that, The receiving end used in batch request mode includes: Receive batch requests to be processed, wherein the batch requests to be processed include: the processed results sent by the request processing method as described in any one of claims 1-9; The application scenario corresponding to the batch requests to be processed is determined, and the processing result is processed using the receiving end request processing task of the determined application scenario; the receiving end request processing task is used to process the requests generated by the determined application scenario.

11. A request processing apparatus, characterized in that, The sending end used in batch request mode includes: The batch request acquisition module is used to acquire batch requests to be sent. The application scenario determination module is used to determine the corresponding application scenario based on the batch requests to be sent, wherein the application scenario is the scenario in which each request in the batch requests is generated. The request segmentation module is used to group the requests in the batch requests to be sent into groups when the requests generated in the determined application scenario are independent of each other and the sending end request processing task of the determined application scenario supports stage segmentation. The sending end request processing task is used to process the requests generated in the determined application scenario. The pipeline processing module is used to process each request in each group of requests in a pipeline manner by utilizing the execution units of each sending stage task after the sending end request processing task is divided. The sending module is used to send the processed results.

12. A request processing apparatus, characterized in that, The receiving end used in batch request mode includes: A batch request receiving module is used to receive batch requests to be processed, wherein the batch requests to be processed include: the processed results sent by the request processing device as described in claim 11; The processing module is used to determine the application scenario corresponding to the batch requests to be processed, and to process the processing results using the receiving end request processing task of the determined application scenario; the receiving end request processing task is used to process the requests generated by the determined application scenario.

13. A computer system, characterized in that, include: The request processing apparatus for the sending end in batch request mode as described in claim 11; The request processing apparatus for a receiver in batch request mode as described in claim 12.

14. An electronic device, characterized in that, The device includes a memory and a processor, wherein the memory stores a program, and the processor calls the program stored in the memory to execute the request processing method as described in any one of claims 1-9, or to execute the request processing method as described in claim 10.

15. A storage medium, characterized in that, The storage medium stores a program that, when executed, implements the request processing method as described in any one of claims 1-9, or implements the request processing method as described in claim 10.

16. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the request processing method as described in any one of claims 1-9, or implements the request processing method as described in claim 10.

Images