WO2020168933A1 - 一种网络请求的处理方法、装置、终端及存储介质 - Google Patents

一种网络请求的处理方法、装置、终端及存储介质 Download PDF

Info

Publication number
WO2020168933A1
WO2020168933A1 PCT/CN2020/074612 CN2020074612W WO2020168933A1 WO 2020168933 A1 WO2020168933 A1 WO 2020168933A1 CN 2020074612 W CN2020074612 W CN 2020074612W WO 2020168933 A1 WO2020168933 A1 WO 2020168933A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
waiting
interface
waiting time
network
Prior art date
Application number
PCT/CN2020/074612
Other languages
English (en)
French (fr)
Inventor
黎志伟
张忠伟
齐磊
Original Assignee
香港乐蜜有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 香港乐蜜有限公司 filed Critical 香港乐蜜有限公司
Publication of WO2020168933A1 publication Critical patent/WO2020168933A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62Establishing a time schedule for servicing the requests

Definitions

  • This application relates to the technical field of network request processing, and in particular to a method, device, terminal and storage medium for processing network requests.
  • an interface merging method can be adopted, that is, two or more interfaces with similar functions or even different services but with similar time requests are merged into one interface, which can greatly reduce the number of interfaces.
  • the timing of interface merging is that the number of network requests in the request queue is greater than one. Because high-frequency network requests may occur at the same time, due to factors such as time errors, the terminal will call idle threads to process the first arrival. For network requests, the request interfaces of the network requests that have not been processed are merged into one interface. Since the current idle threads are all occupied, the network request corresponding to the merged interface can only be processed when the idle thread appears again.
  • the previous consecutive network requests occupy idle threads when there is no interface merging, which causes the waiting of subsequent network requests If the time is too long, the average waiting time for network requests is longer.
  • the purpose of the embodiments of the present application is to provide a method, device, terminal, and storage medium for processing network requests, so as to shorten the average waiting time of network requests to be processed when the requests are queued for processing.
  • the specific technical solutions are as follows:
  • an embodiment of the present application provides a method for processing a network request, which is applied to a terminal, and the method includes:
  • an idle thread When a network request to be processed enters an empty request queue, an idle thread is awakened and enters a waiting state as a waiting thread, wherein the request queue is a queue formed by the current pending network request of the terminal, and the request queue When it is empty, all idle threads are in a blocked state;
  • the method further includes:
  • the method for determining the waiting time includes:
  • the waiting time is determined according to the number of currently idle threads and the average processing time.
  • the step of determining the waiting time according to the current number of idle threads and the average processing time of network requests includes:
  • t0 When the number of idle threads is the maximum, t0 is 0;
  • t0 is the waiting time
  • t* is the average processing time
  • n is the number of currently idle threads
  • N is the maximum number of currently idle threads.
  • the method further includes:
  • the average processing duration is updated according to the processing duration.
  • the step of updating the average processing duration according to the processing duration includes:
  • t0' is the updated average processing time
  • m is a positive integer
  • t* is the average processing time
  • tb is the processing time of the pending network request corresponding to the single merge interface.
  • the method before the step of merging the obtained request interfaces of the pending network request into a single merge interface, the method further includes:
  • the step of merging the obtained request interface of the pending network request into the merge interface includes:
  • the method further includes:
  • an embodiment of the present application provides a network request processing device, which is applied to a terminal, and the device includes:
  • the idle thread wake-up module is used to wake up an idle thread to enter the waiting state when the pending network request enters the empty request queue, as a waiting thread, wherein the request queue is formed by the current pending network request of the terminal When the request queue is empty, all idle threads are in a blocked state;
  • the waiting time determining module is used to determine whether the waiting time of the waiting thread reaches the waiting time predetermined by the waiting time determining module;
  • the request interface merging module is configured to, if the predetermined waiting time is reached, obtain the pending network request in the request queue, trigger the idle thread to wake up the module, and combine multiple pending networks in the request queue
  • the requested request interface is merged into a single merge interface
  • the network request sending module is configured to call the waiting thread to send the pending network request corresponding to the single merge interface to the server.
  • the device further includes:
  • the triggering module is configured to trigger the waiting time determining module if the waiting time of the waiting thread does not reach the predetermined waiting time.
  • the waiting time determining module includes:
  • the acquisition unit is used to acquire the current number of idle threads and the average processing time of network requests
  • the waiting duration determining unit is configured to determine the waiting duration according to the number of currently idle threads and the average processing duration.
  • the waiting duration determining unit includes:
  • the waiting time determines the subunit.
  • t0 is the waiting time
  • t* is the average processing time
  • n is the number of currently idle threads
  • N is the maximum number of currently idle threads.
  • the device further includes:
  • a processing duration acquisition module configured to acquire the processing duration of the pending network request corresponding to the single merge interface after the waiting thread is called to send the pending network request corresponding to the single merge interface to the server;
  • the processing duration update module is configured to update the average processing duration according to the processing duration.
  • processing time update module includes:
  • t0' is the updated average processing time
  • m is a positive integer
  • t* is the average processing time
  • tb is the processing time of the pending network request corresponding to the single merge interface.
  • the device further includes:
  • An identification acquisition module configured to acquire the identification of the request interface of each network request to be processed before the acquired request interfaces of the network request to be processed are merged into a single merge interface
  • the request interface merging module includes:
  • the parameter recording unit is configured to merge the obtained request interfaces of the network requests to be processed into a single merge interface, and record the identifiers of the request interfaces of each network request to be processed as the parameters of the single merge interface;
  • the device also includes:
  • the result analysis module is configured to, after obtaining the network request result corresponding to the single merge interface sent by the server, analyze the network request result according to the recorded parameters of the single merge interface to obtain the respective The request result corresponding to the request interface of the pending network request;
  • the result sending module is used to send the request result to the corresponding request interface.
  • an embodiment of the present application provides a terminal, including a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete mutual communication through the communication bus;
  • Memory used to store computer programs
  • the processor is used to implement the steps of any one of the aforementioned network request processing methods when executing the program stored in the memory.
  • an embodiment of the present application provides a computer-readable storage medium with a computer program stored in the computer-readable storage medium, and when the computer program is executed by a processor, it realizes the processing of any one of the aforementioned network requests. Method steps.
  • an embodiment of the present application provides a computer program, which is used to execute any of the above-mentioned network request processing method steps at runtime.
  • the terminal wakes up an idle thread and enters the waiting state as a waiting thread, where the request queue is the current pending network request of the client.
  • the formed queue when the request queue is empty, all idle threads are in a blocked state, and then the terminal determines whether the waiting time of the waiting thread reaches the predetermined waiting time, and if it reaches the predetermined waiting time, it obtains the pending processing in the request queue
  • the network request further merges the request interfaces of multiple pending network requests in the request queue into a single merged interface, and calls the waiting thread to send the pending network request corresponding to the single merged interface to the server.
  • the terminal Since the terminal determines that the waiting time of the waiting thread reaches the predetermined waiting time, it calls the waiting thread to send the pending network request corresponding to the single merge interface to the server, instead of immediately using all idle threads to process the first few pending requests.
  • Network requests shorten the waiting time for subsequent network requests to be processed, and shorten the average waiting time for requests to be processed by the network.
  • FIG. 1 is a flowchart of a method for processing a network request provided by an embodiment of the application
  • FIG. 2 is a flowchart of a determination method of waiting time based on the embodiment shown in FIG. 1;
  • FIG. 3 is a flowchart of an update method of the average processing duration based on the embodiment shown in FIG. 2;
  • FIG. 4 is a flowchart of a method for analyzing network request results provided by an embodiment of this application.
  • FIG. 5 is a schematic structural diagram of a network request processing apparatus provided by an embodiment of this application.
  • FIG. 6 is a schematic structural diagram of a terminal provided by an embodiment of the application.
  • embodiments of the present application provide a processing method, device, terminal, storage medium, and computer program for a network request.
  • the following describes a method for processing a network request provided by an embodiment of the present application.
  • the method for processing a network request provided by the embodiment of the present application can be applied to a terminal, and the terminal can be connected to a server in communication to send a network request to the server to realize the required network service.
  • a method for processing a network request includes:
  • the request queue is a queue formed by the current pending network requests of the client, and when the request queue is empty, all idle threads are in a blocked state.
  • step S103 If the predetermined waiting time is reached, obtain the network request to be processed in the request queue, and return to execute step S101, and merge the request interfaces of multiple network requests to be processed in the request queue into a single merge interface;
  • S104 Invoke the waiting thread to send the to-be-processed network request corresponding to the single merge interface to the server.
  • the terminal when a pending network request enters an empty request queue, the terminal can wake up an idle thread and enter the waiting state as a waiting thread, where the request queue is the current waiting queue of the client.
  • the queue formed by processing network requests.
  • the request queue is empty, all idle threads are in a blocked state, and then the terminal determines whether the waiting time of the waiting thread reaches the predetermined waiting time, and if it reaches the predetermined waiting time, it gets in the request queue Then, the request interfaces of multiple pending network requests in the request queue are merged into a single merge interface, and the waiting thread is called to send the pending network request corresponding to the single merge interface to the server.
  • the terminal Since the terminal determines that the waiting time of the waiting thread reaches the predetermined waiting time, it calls the waiting thread to send the pending network request corresponding to the single merge interface to the server, instead of immediately using all idle threads to process the first few pending requests.
  • Network requests shorten the waiting time for subsequent network requests to be processed, and shorten the average waiting time for requests to be processed by the network.
  • the request queue in the terminal is a queue formed by the terminal's current pending network requests, that is, a queue for placing pending network requests.
  • the request queue is empty, it means that there are no pending network requests waiting to be processed.
  • the terminal can control all idle threads to be in a blocking state.
  • the blocking state is the dormant state, which means that the idle thread is not working at this time. .
  • step S101 when the pending network request enters the empty request queue, that is, when the pending network request is generated, the terminal can wake up an idle thread to enter the waiting state, and the idle thread in the waiting state serves as the waiting thread. It should be noted that the waiting thread is only awakened, instead of processing the network request to be processed immediately.
  • the terminal When waking up the idle thread and entering the waiting state, the terminal can maintain a timer at the same time and start to count the waiting time of the waiting thread. Furthermore, in the above step S102, the terminal can determine whether the waiting time of the waiting thread reaches a predetermined waiting time.
  • the predetermined waiting time can be determined based on the current number of idle threads, the number of pending network requests and other factors. For the sake of clarity and The layout is clear, and the specific method for determining the waiting time will be introduced with examples in the follow-up.
  • the terminal can obtain the pending network request in the request queue.
  • the request queue returns to an empty state.
  • the terminal can return to the foregoing step S101, that is, when the subsequent pending network request When the request enters the empty request queue, continue to wake up an idle thread and enter the waiting state as a waiting thread.
  • the terminal may merge the request interfaces of multiple network requests to be processed in the request queue into a single merged interface.
  • the specific method of interface merging can adopt any method of interface merging in the field of network request, which is not specifically limited and explained here.
  • the terminal may call the waiting thread to send the to-be-processed network request corresponding to the single merge interface to the server. So that the server can receive the pending network requests and process these pending network requests accordingly.
  • the terminal Since the terminal determines that the waiting time of the waiting thread reaches the predetermined waiting time each time, it calls the waiting thread to send the pending network request corresponding to the single merge interface to the server, instead of immediately using all idle threads to process the first obtained data.
  • a pending network request shortens the waiting time for subsequent pending network requests and shortens the average waiting time for pending network processing requests.
  • the above method may further include:
  • the terminal can return In the above step of determining whether the waiting time of the waiting thread reaches the predetermined waiting time length, continue to wait until the waiting time of the waiting thread reaches the predetermined waiting time length.
  • the terminal when the terminal determines that the waiting time of the waiting thread has not reached the predetermined waiting time, it can return to the step of determining whether the waiting time of the waiting thread has reached the predetermined waiting time, and continue to wait until the waiting thread The waiting time reaches the predetermined waiting time, and then the interfaces of the pending network requests are merged to ensure that idle threads will not be occupied by a small number of pending network requests.
  • the foregoing determination method of the waiting time may include:
  • the terminal can obtain the current number of idle threads and the average processing time of network requests.
  • the average processing time of the network request may be calculated according to the processing time of the last processing of the network request after the last processing of the network request, and the terminal may record the calculated average processing time for subsequent use.
  • S202 Determine the waiting time according to the number of currently idle threads and the average processing time.
  • the terminal After acquiring the current number of idle threads and the average processing time of network requests, the terminal can determine the waiting time based on the acquired current number of idle threads and the average processing time of network requests.
  • the longer the average processing time of network requests the more the number of pending network requests currently processed by the terminal. Therefore, the longer the average processing time of network requests, the longer the waiting time can be.
  • the terminal can obtain the current number of idle threads and the average processing time of network requests, and then determine the waiting time according to the current number of idle threads and the average processing time. In this way, an appropriate waiting time can be determined according to the current actual situation, further reducing the average waiting time for requests to be processed by the network. And since in this solution, almost all request interfaces can be merged, the merge collision rate can be improved, where the merge collision rate is the ratio of the number of mergeable request interfaces to the number of actual merged request interfaces.
  • the above step of determining the waiting time according to the current number of idle threads and the average processing time of network requests may include:
  • the waiting time can be 0 at this time, that is, the terminal can Immediately call the waiting thread to process pending network requests.
  • the waiting time at this time can be t*/(16-2(Nn)), where t0 is the waiting time, t* is the above average processing time, n is the number of current idle threads, and N is the number of current idle threads The maximum value.
  • the waiting thread when the current number of idle threads is the maximum, the waiting thread is immediately called to process the pending network request, which can process the pending network request as soon as possible; when the number of idle threads is not the maximum, the average processing time The longer, the longer the waiting time, the more the current number of idle threads, the smaller the value of (Nn), the larger the value of (16-2(Nn)), the shorter the waiting time, based on this formula can determine the appropriate waiting duration.
  • the above method may further include:
  • the terminal Since the processing time of network requests is related to network conditions and other factors, and may change at any time, in order to make the waiting time determined by the terminal adapt to the current network conditions, the terminal calls the waiting thread to send the pending network request corresponding to a single merge interface to After the server, the processing time of the pending network request corresponding to the single merge interface can be obtained.
  • the terminal may record the time point when the network request to be processed is sent to the server, and the time point when the server feeds back the processing result corresponding to the network request to be processed, and then calculate the processing time of the network request to be processed according to the two time points.
  • the terminal can update the waiting time according to the processing time of the pending network request corresponding to a single merge interface, so that the updated waiting time is more in line with the current network conditions, and the average waiting time of the pending network request is further shortened.
  • the terminal after the terminal calls the waiting thread to send the pending network request corresponding to a single merge interface to the server, it can obtain the processing time of the pending network request corresponding to the single merge interface, and then update the waiting time.
  • the updated waiting time can be more in line with the current network conditions, and the average waiting time of pending network requests can be further shortened.
  • the foregoing step of updating the waiting time length according to the processing time length may include:
  • t0' is the updated average processing time
  • m is a positive integer
  • t* is the above average processing time
  • tb is the processing time of the pending network request corresponding to the single merge interface.
  • the terminal After updating the average processing duration, the terminal can determine the waiting duration according to the updated average processing duration.
  • the above method may further include:
  • multiple request interfaces may be request interfaces with different functions
  • combining multiple request interfaces into a single merged interface may make it difficult for the terminal to distinguish the request result corresponding to each request interface when receiving the network request result returned by the server. Therefore, in order to distinguish each request interface, the terminal can obtain the identification of the request interface of each network request to be processed.
  • the above step of merging the obtained request interface of the pending network request into a merge interface may include:
  • the obtained request interfaces of the network requests to be processed are merged into a single merge interface, and the identifier of the request interface of each network request to be processed is recorded as a parameter of the single merge interface.
  • the terminal When the terminal merges the acquired request interfaces of the network requests to be processed into a single merge interface, it may record the identifiers of the request interfaces of each network request to be processed as the parameters of the single merge interface. In this way, the terminal can determine the corresponding function and other information according to the identification of each request interface.
  • the terminal sends the to-be-processed network request corresponding to a single merge interface to the server, the parameter can be sent to the server at the same time.
  • the above method may further include:
  • S401 Analyze the network request result according to the recorded parameters of the single merge interface to obtain the request result corresponding to the request interface of each network request to be processed;
  • the above parameters can be transparently transmitted during the processing, so that the network request result corresponding to the single merge interface sent by the server also carries the above parameters.
  • the terminal When the terminal receives the network request result corresponding to the aforementioned single merge interface sent by the server, since the terminal records the parameters of the single merge interface, the terminal can analyze the network request result according to the recorded parameters of the single merge interface to obtain Request result corresponding to the request interface of each network request to be processed.
  • the specific method for the terminal to analyze the network request result corresponding to a single merge interface can adopt any network request result analysis method in the field of network request processing, which is not specifically limited and explained here.
  • S402 Send the request result to a corresponding request interface.
  • the terminal After determining the request result corresponding to the request interface of each network request to be processed, the terminal can send each request result to the corresponding request interface to complete the distribution of the result of the network request.
  • the identifiers of the request interfaces of each pending network request can be obtained, and then the request interfaces are merged into a single merge interface.
  • the identifier of the request interface of each network request to be processed can be recorded as a parameter of the single merge interface.
  • the network request result can be parsed according to the recorded parameters of the single merge interface to obtain the request result corresponding to the request interface of each pending network request.
  • an embodiment of the present application also provides a network request processing device.
  • the following describes a network request processing device provided by an embodiment of the present application.
  • a network request processing device is applied to a terminal, and the device includes:
  • the idle thread wake-up module 510 is used to wake up an idle thread to enter the waiting state when the network request to be processed enters the empty request queue, as a waiting thread;
  • the request queue is a queue formed by current pending network requests of the terminal, and when the request queue is in an empty state, all idle threads are in a blocked state.
  • the waiting time determining module 520 is configured to determine whether the waiting time of the waiting thread reaches the waiting time predetermined by the waiting time determining module (not shown in FIG. 5);
  • the request interface merging module 530 is configured to, if the predetermined waiting time is reached, obtain the pending network request in the request queue, trigger the idle thread to wake up the module 510, and combine multiple pending requests in the request queue.
  • the request interface for processing network requests is merged into a single merged interface;
  • the network request sending module 540 is configured to call the waiting thread to send the pending network request corresponding to the single merge interface to the server.
  • the terminal when a pending network request enters an empty request queue, the terminal can wake up an idle thread and enter the waiting state as a waiting thread, where the request queue is the current waiting queue of the client.
  • the queue formed by processing network requests.
  • the request queue is empty, all idle threads are in a blocked state, and then the terminal determines whether the waiting time of the waiting thread reaches the predetermined waiting time, and if it reaches the predetermined waiting time, it gets in the request queue Then, the request interfaces of multiple pending network requests in the request queue are merged into a single merge interface, and the waiting thread is called to send the pending network request corresponding to the single merge interface to the server.
  • the terminal Since the terminal determines that the waiting time of the waiting thread reaches the predetermined waiting time, it calls the waiting thread to send the pending network request corresponding to the single merge interface to the server, instead of immediately using all idle threads to process the first few pending requests.
  • Network requests shorten the waiting time for subsequent network requests to be processed, and shorten the average waiting time for requests to be processed by the network.
  • the foregoing device may further include:
  • a triggering module (not shown in FIG. 5) is configured to trigger the waiting time determining module 520 if the waiting time of the waiting thread does not reach the predetermined waiting time.
  • the aforementioned waiting time determination module 520 may include:
  • the obtaining unit (not shown in FIG. 5) is used to obtain the current number of idle threads and the average processing time of network requests;
  • the waiting duration determining unit (not shown in FIG. 5) is configured to determine the waiting duration according to the number of currently idle threads and the average processing duration.
  • the foregoing waiting period determining unit may include:
  • t0 is the waiting time
  • t* is the average processing time
  • n is the number of currently idle threads
  • N is the maximum number of currently idle threads.
  • the foregoing device may further include:
  • the processing time acquisition module (not shown in FIG. 5) is used to acquire the to-be-processed network corresponding to the single merged interface after the invoking the waiting thread sends the pending network request corresponding to the single merged interface to the server The processing time of the request;
  • the processing duration update module (not shown in FIG. 5) is configured to update the average processing duration according to the processing duration.
  • the aforementioned processing duration update module may include:
  • t0' is the updated average processing time
  • m is a positive integer
  • t* is the average processing time
  • tb is the processing time of the pending network request corresponding to the single merge interface.
  • the foregoing device may further include:
  • An identification acquisition module (not shown in FIG. 5), configured to acquire the identification of the request interface of each network request to be processed before the acquired request interface of the network request to be processed is merged into a single merge interface;
  • the request interface merging module 540 may include:
  • the parameter recording unit (not shown in Figure 5) is used to merge the obtained request interfaces of the pending network requests into a single merge interface, and use the identifier of the request interface of each pending network request as the single merge interface Parameters are recorded;
  • the device may also include:
  • the result analysis module (not shown in FIG. 5) is used to request the network according to the recorded parameters of the single merge interface after obtaining the network request result corresponding to the single merge interface sent by the server Analyze the result to obtain the request result corresponding to the request interface of each network request to be processed;
  • the result sending module (not shown in FIG. 5) is used to send the request result to the corresponding request interface.
  • the embodiment of the present application also provides a terminal.
  • the terminal may include a processor 601, a communication interface 602, a memory 603, and a communication bus 604.
  • the processor 601, the communication interface 602, and the memory 603 pass through the communication bus. 604 completes mutual communication,
  • the memory 603 is used to store computer programs
  • the processor 601 is configured to implement the following steps when executing the program stored in the memory 603:
  • the request queue is a queue formed by current pending network requests of the terminal, and when the request queue is in an empty state, all idle threads are in a blocked state.
  • the terminal wakes up an idle thread and enters the waiting state as a waiting thread, where the request queue is the current pending processing of the client A queue formed by network requests.
  • the request queue is empty, all idle threads are in a blocked state.
  • the terminal determines whether the waiting time of the waiting thread reaches the predetermined waiting time. If the waiting time reaches the predetermined waiting time, it gets the information in the request queue.
  • the request interfaces of multiple pending network requests in the request queue are then merged into a single merged interface, and the waiting thread is called to send the pending network request corresponding to the single merged interface to the server.
  • the terminal Since the terminal determines that the waiting time of the waiting thread reaches the predetermined waiting time, it calls the waiting thread to send the pending network request corresponding to the single merge interface to the server, instead of immediately using all idle threads to process the first few pending requests.
  • Network requests shorten the waiting time for subsequent network requests to be processed, and shorten the average waiting time for requests to be processed by the network.
  • the communication bus mentioned by the above terminal may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus.
  • PCI Peripheral Component Interconnect
  • EISA Extended Industry Standard Architecture
  • the communication bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.
  • the communication interface is used for communication between the aforementioned terminal and other devices.
  • the memory may include random access memory (Random Access Memory, RAM), and may also include non-volatile memory (Non-Volatile Memory, NVM), such as at least one disk storage.
  • NVM non-Volatile Memory
  • the memory may also be at least one storage device located far away from the foregoing processor.
  • the aforementioned processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (Network Processor, NP), etc.; it may also be a digital signal processor (Digital Signal Processing, DSP), a dedicated integrated Circuit (Application Specific Integrated Circuit, ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.
  • CPU central processing unit
  • NP Network Processor
  • DSP Digital Signal Processing
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • the above method may further include:
  • the above determination method of waiting time may include:
  • the waiting time is determined according to the number of currently idle threads and the average processing time.
  • the step of determining the waiting time according to the current number of idle threads and the average processing time of network requests may include:
  • t0 When the number of idle threads is the maximum, t0 is 0;
  • t0 is the waiting time
  • t* is the average processing time
  • n is the number of currently idle threads
  • N is the maximum number of currently idle threads.
  • the above method may further include:
  • the average processing duration is updated according to the processing duration.
  • the step of updating the average processing duration according to the processing duration may include:
  • t0' is the updated average processing time
  • m is a positive integer
  • t* is the average processing time
  • tb is the processing time of the pending network request corresponding to the single merge interface.
  • the above method may further include:
  • the foregoing step of merging the obtained request interface of the pending network request into a merge interface may include:
  • the above method may further include:
  • the embodiment of the present application also provides a computer-readable storage medium in which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:
  • the request queue is a queue formed by current pending network requests of the terminal, and when the request queue is in an empty state, all idle threads are in a blocked state.
  • the terminal determines whether the waiting time of the waiting thread reaches the predetermined waiting time, and if it reaches the predetermined waiting time , The pending network requests in the request queue are obtained, and the request interfaces of multiple pending network requests in the request queue are merged into a single merge interface, and the waiting thread is called to send the pending network request corresponding to the single merge interface to the server. Since the terminal determines that the waiting time of the waiting thread reaches the predetermined waiting time, it calls the waiting thread to send the pending network request corresponding to the single merge interface to the server, instead of immediately using all idle threads to process the first few pending requests. Network requests shorten the waiting time for subsequent network requests to be processed, and shorten the average waiting time for requests to be processed by the network.
  • the above method may further include:
  • the above determination method of waiting time may include:
  • the waiting time is determined according to the number of currently idle threads and the average processing time.
  • the step of determining the waiting time according to the current number of idle threads and the average processing time of network requests may include:
  • t0 When the number of idle threads is the maximum, t0 is 0;
  • t0 is the waiting time
  • t* is the average processing time
  • n is the current number of idle threads
  • N is the maximum value of the current idle threads.
  • the above method may further include:
  • the average processing duration is updated according to the processing duration.
  • the step of updating the average processing duration according to the processing duration may include:
  • t0' is the updated average processing time
  • m is a positive integer
  • t* is the average processing time
  • tb is the processing time of the pending network request corresponding to the single merge interface.
  • the above method may further include:
  • the foregoing step of merging the obtained request interface of the pending network request into a merge interface may include:
  • the above method may further include:
  • the embodiments of the present application also provide a computer program, which is used to execute the steps of the network request processing method described in any of the foregoing embodiments during runtime.
  • the terminal Since the terminal determines that the waiting time of the waiting thread reaches the predetermined waiting time, it calls the waiting thread to send the pending network request corresponding to the single merge interface to the server, instead of immediately using all idle threads to process the first few pending requests.
  • Network requests shorten the waiting time for subsequent network requests to be processed, and shorten the average waiting time for requests to be processed by the network.

Abstract

本申请实施例提供了一种网络请求的处理方法、装置、终端及存储介质,所述方法包括:当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程;确定等待线程的等待时间是否达到预先确定的等待时长;如果达到预先确定的等待时长,获取请求队列中的待处理网络请求,并返回当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程的步骤,并将请求队列中多个待处理网络请求的请求接口合并为单个合并接口;调用等待线程发送单个合并接口对应的待处理网络请求至服务器。由于终端不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得待网络处理请求的平均等待时间缩短。

Description

一种网络请求的处理方法、装置、终端及存储介质
本申请要求于2019年2月22日交中国专利局、申请号为201910135297.5发明名称为“一种网络请求的处理方法、装置、终端及存储介质”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及网络请求处理技术领域,特别是涉及一种网络请求的处理方法、装置、终端及存储介质。
背景技术
终端中的应用程序在实现与服务器交互时,需要通过网络请求的接口进行数据交互。随着应用程序增多,不同的应用程序需求导致网络请求接口增多。在一些应用场景下,高频的网络请求导致网络请求在请求队列中的等待时间增长,而请求线程的数量不能无限制地增加,同时增加请求线程会增加性能开销,不能很好地解决网络请求的等待时间增长的问题。
为了解决这个问题,可以采用接口合并方式,即将两个或者多个功能相近甚至业务不同但相近时间请求的接口合并为一个接口,这样可以极大地减少接口的数量。目前,在大量网络请求进入请求队列时,接口合并时机为请求队列中网络请求的数量大于一个,由于高频的网络请求可能同时发生,由于时间误差等因素终端会调用空闲线程处理最先达到的网络请求,没有得到处理的网络请求的请求接口被合并为一个接口,由于当前空闲线程均被占用,只能等待再次出现空闲线程时处理合并接口对应的网络请求。
由于终端的工作线程是固定的,空闲线程也是有限的,采用上述方式将会出现处理网络请求时,前面连续几个网络请求在没有发生接口合并时占用空闲线程的情况,造成后续网络请求的等待时间过长,网络请求的平均等待时间较长。
发明内容
本申请实施例的目的在于提供一种网络请求的处理方法、装置、终端及存储介质,以缩短待处理请求排队等待处理时待处理网络请求的平均等待时间。具体技术方案如下:
第一方面,本申请实施例提供了一种网络请求的处理方法,应用于终端,所述方法包括:
当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程,其中,所述请求队列为所述终端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有空闲线程处于阻塞状态;
确定所述等待线程的等待时间是否达到预先确定的等待时长;
如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并返回所述当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程的步骤,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
可选的,如果所述等待线程的等待时长未达到所述预先确定的等待时长,所述方法还包括:
返回所述确定所述等待线程的等待时间是否达到预先确定的等待时长的步骤。
可选的,所述等待时长的确定方式,包括:
获取当前空闲线程的数量及网络请求的平均处理时长;
根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
可选的,所述根据当前空闲线程的数量及网络请求的平均处理时长,确定所述等待时长的步骤,包括:
当前空闲线程的数量为最大值时,t0为0;
当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n));
其中,t0为所述等待时长,t*为所述平均处理时长,n为当前空闲线程的数量,N为当前空闲线程的数量的最大值。
可选的,在所述调用所述等待线程发送所述单个合并接口对应的待处理 网络请求至服务器的步骤之后,所述方法还包括:
获取所述单个合并接口对应的待处理网络请求的处理时长;
根据所述处理时长更新所述平均处理时长。
可选的,所述根据所述处理时长更新所述平均处理时长的步骤,包括:
根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长;
其中,t0’为所述更新后的平均处理时长,m为正整数,t*为所述平均处理时长,tb为所述单个合并接口对应的待处理网络请求的处理时长。
可选的,在所述将所获取的待处理网络请求的请求接口合并为单个合并接口的步骤之前,所述方法还包括:
获取各待处理网络请求的请求接口的标识;
所述将所获取的待处理网络请求的请求接口合并为合并接口的步骤,包括:
将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录;
在获取所述服务器发送的所述单个合并接口对应的网络请求结果之后,所述方法还包括:
根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
将所述请求结果发送至对应的请求接口。
第二方面,本申请实施例提供了一种网络请求的处理装置,应用于终端,所述装置包括:
空闲线程唤醒模块,用于当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程,其中,所述请求队列为所述终端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有空闲线程处于阻塞状态;
等待时间确定模块,用于确定所述等待线程的等待时间是否达到通过等待时长确定模块预先确定的等待时长;
请求接口合并模块,用于如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并触发所述空闲线程唤醒模块,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
网络请求发送模块,用于调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
可选的,所述装置还包括:
触发模块,用于如果所述等待线程的等待时长未达到所述预先确定的等待时长,触发所述等待时间确定模块。
可选的,所述等待时间确定模块包括:
获取单元,用于获取当前空闲线程的数量及网络请求的平均处理时长;
等待时长确定单元,用于根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
可选的,所述等待时长确定单元包括:
等待时长确定子单元,用于当前空闲线程的数量为最大值时,t0为0;当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n));
其中,t0为所述等待时长,t*为所述平均处理时长,n为当前空闲线程的数量,N为当前空闲线程的数量的最大值。
可选的,所述装置还包括:
处理时长获取模块,用于在所述调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器之后,获取所述单个合并接口对应的待处理网络请求的处理时长;
处理时长更新模块,用于根据所述处理时长更新所述平均处理时长。
可选的,所述处理时长更新模块包括:
处理时长更新单元,用于根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长;
其中,t0’为所述更新后的平均处理时长,m为正整数,t*为所述平均处理时长,tb为所述单个合并接口对应的待处理网络请求的处理时长。
可选的,所述装置还包括:
标识获取模块,用于在所述将所获取的待处理网络请求的请求接口合并为单个合并接口之前,获取各待处理网络请求的请求接口的标识;
所述请求接口合并模块包括:
参数记录单元,用于将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录;
所述装置还包括:
结果解析模块,用于在获取所述服务器发送的所述单个合并接口对应的网络请求结果之后,根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
结果发送模块,用于将所述请求结果发送至对应的请求接口。
第三方面,本申请实施例提供了一种终端,包括处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
存储器,用于存放计算机程序;
处理器,用于执行存储器上所存放的程序时,实现上述任一所述网络请求的处理方法步骤。
第四方面,本申请实施例提供了一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现上述任一所述网络请求的处理方法步骤。
第五方面,本申请实施例提供了一种计算机程序,所述计算机程序用于 在运行时执行上述任一所述网络请求的处理方法步骤。
本申请实施例所提供的方案中,当待处理网络请求进入为空状态的请求队列时,终端唤醒一个空闲线程进入等待状态,作为等待线程,其中,请求队列为客户端当前的待处理网络请求形成的队列,请求队列为空状态时,所有空闲线程处于阻塞状态,然后终端确定等待线程的等待时间是否达到预先确定的等待时长,如果达到预先确定的等待时长,则获取请求队列中的待处理网络请求,进而将请求队列中多个待处理网络请求的请求接口合并为单个合并接口,调用等待线程发送单个合并接口对应的待处理网络请求至服务器。由于终端在确定等待线程的等待时间达到预先确定的等待时长时,调用等待线程发送上述单个合并接口对应的待处理网络请求至服务器,而不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得后续待处理网络请求的等待时间缩短,待网络处理请求的平均等待时间缩短。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例所提供的一种网络请求的处理方法的流程图;
图2为基于图1所示实施例的等待时长的一种确定方式的流程图;
图3为基于图2所示实施例的平均处理时长的一种更新方式的流程图;
图4为本申请实施例所提供的网络请求结果的一种解析方式的流程图;
图5为本申请实施例所提供的一种网络请求的处理装置的结构示意图;
图6为本申请实施例所提供的一种终端的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做 出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
为了缩短待处理请求排队等待处理时待处理网络请求的平均等待时间,本申请实施例提供了一种网络请求的处理方法、装置、终端、存储介质以及计算机程序。
下面对本申请实施例所提供的一种网络请求的处理方法进行介绍。
本申请实施例所提供的一种网络请求的处理方法可以应用于终端,该终端可以与服务器通信连接,以向服务器发送网络请求,实现所需要的网络服务。
如图1所示,一种网络请求的处理方法,所述方法包括:
S101,当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程;
其中,所述请求队列为所述客户端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有空闲线程处于阻塞状态。
S102,确定所述等待线程的等待时间是否达到预先确定的等待时长;
S103,如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并返回执行步骤S101,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
S104,调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
可见,本申请实施例所提供的方案中,当待处理网络请求进入为空状态的请求队列时,终端可以唤醒一个空闲线程进入等待状态,作为等待线程,其中,请求队列为客户端当前的待处理网络请求形成的队列,请求队列为空状态时,所有空闲线程处于阻塞状态,然后终端确定等待线程的等待时间是否达到预先确定的等待时长,如果达到预先确定的等待时长,则获取请求队列中的待处理网络请求,进而将请求队列中多个待处理网络请求的请求接口合并为单个合并接口,调用等待线程发送单个合并接口对应的待处理网络请求至服务器。由于终端在确定等待线程的等待时间达到预先确定的等待时长时,调用等待线程发送上述单个合并接口对应的待处理网络请求至服务器,而不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得后 续待处理网络请求的等待时间缩短,待网络处理请求的平均等待时间缩短。
终端中的请求队列是终端当前的待处理网络请求形成的队列,也就是用于放置待处理网络请求的队列。该请求队列为空状态时,说明当时没有待处理网络请求等待处理,此时终端可以控制所有空闲线程处于阻塞状态,其中,阻塞状态即为休眠状态,也就说此时空闲线程为非工作状态。
在上述步骤S101中,当待处理网络请求进入为空状态的请求队列时,也就是待处理网络请求生成时,终端可以唤醒一个空闲线程进入等待状态,该处于等待状态的空闲线程作为等待线程。需要说明的是,该等待线程只是被唤醒,而不是马上对待处理网络请求进行处理。
在唤醒空闲线程进入等待状态时,终端同时可以维护一个计时器并开始对该等待线程的等待时间进行计时。进而,在上述步骤S102中,终端可以确定等待线程的等待时间是否达到预先确定的等待时长,该预先确定的等待时长可以根据当前空闲线程数量,待处理网络请求数量等因素确定,为了方案清楚及布局清晰,后续将会对确定的等待时长的具体方式进行举例介绍。
如果等待线程的等待时间达到预先确定的等待时长,说明此时已有一段时间未对待处理网络请求进行处理,为了尽快处理待处理网络请求,终端可以获取上述请求队列中的待处理网络请求。
此时,由于上述请求队列中的待处理网络请求被取出,所以请求队列回到空状态,为了继续对后续的待处理网络请求进行处理,终端可以返回上述步骤S101,即当后续的待处理网络请求进入为空状态的请求队列时,继续唤醒一个空闲线程进入等待状态,作为等待线程。
终端获取上述请求队列中的待处理网络请求后,可以将请求队列中多个待处理网络请求的请求接口合并为单个合并接口。其中,接口合并的具体方式可以采用网络请求领域中接口合并的任意方式,在此不做具体限定及说明。
进而,在上述步骤S104中,终端可以调用上述等待线程发送该单个合并接口对应的待处理网络请求至服务器。以使服务器可以接收到待处理网络请求,并对这些待处理网络请求进行相应处理。
由于终端每次均在确定等待线程的等待时间达到预先确定的等待时长时, 调用等待线程发送上述单个合并接口对应的待处理网络请求至服务器,而不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得后续待处理网络请求的等待时间缩短,待网络处理请求的平均等待时间缩短。
作为本申请实施例的一种实施方式,如果上述等待线程的等待时长未达到所述预先确定的等待时长,上述方法还可以包括:
返回所述确定所述等待线程的等待时间是否达到预先确定的等待时长的步骤。
如果上述等待线程的等待时长未达到预先确定的等待时长,说明此时等待时长还比较短,为了避免出现空闲线程都被占用,后续大量待处理网络请求等待时间过长的问题出现,终端可以返回上述确定等待线程的等待时间是否达到预先确定的等待时长的步骤,继续等待直到等待线程的等待时间达到预先确定的等待时长。
可见,在本实施例中,终端在确定上述等待线程的等待时长未达到预先确定的等待时长时,可以返回上述确定等待线程的等待时间是否达到预先确定的等待时长的步骤,继续等待直到等待线程的等待时间达到预先确定的等待时长,再将待处理网络请求的接口进行合并,保证空闲线程不会被少量的几个待处理网络请求占用。
作为本申请实施例的一种实施方式,如图2所示,上述等待时长的确定方式,可以包括:
S201,获取当前空闲线程的数量及网络请求的平均处理时长;
由于空闲线程的数量以及网络请求的处理时长均会影响待处理网络请求的处理,所以为了确定合适的等待时长,终端可以获取当前空闲线程的数量及网络请求的平均处理时长。
其中,网络请求的平均处理时长可以为上一次处理网络请求后,根据该上一次处理网络请求的处理时长计算得到的,终端可以将计算得到的平均处理时长记录下来,便于后续使用。
S202,根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
获取了当前空闲线程的数量及网络请求的平均处理时长后,终端则可以 基于获取的当前空闲线程的数量及网络请求的平均处理时长,确定等待时长。
由于空闲线程的数量越多,说明终端当前可处理的待处理网络请求的数量越多,所以当前空闲线程的数量越多,等待时长可以越短。由于网络请求的平均处理时长越长,说明终端当前处理的待处理网络请求的数量越多,所以网络请求的平均处理时长越长,等待时长可以越长。
可见,在本实施中,终端可以获取当前空闲线程的数量及网络请求的平均处理时长,进而根据当前空闲线程的数量及平均处理时长,确定等待时长。这样,可以根据当前实际情况确定合适的等待时长,进一步缩短待网络处理请求的平均等待时间。并且由于在本方案中,几乎所有请求接口都可以被合并,所以可以提高合并碰撞率,其中,合并碰撞率即为可合并的请求接口的数量与实际合并的请求接口的数量的比率。
作为本申请实施例的一种实施方式,上述根据当前空闲线程的数量及网络请求的平均处理时长,确定所述等待时长的步骤,可以包括:
当前空闲线程的数量为最大值时,t0为0;当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n))。
如果空闲线程的数量为最大值,说明此时线程均为空闲状态,那么说明当前网络请求较少,那么为了能够尽快处理待处理网络请求,此时等待时长可以为0,也就是说,终端可以立刻调用等待线程处理待处理网络请求。
如果空闲线程的数量不为最大值,说明此时线程不是都为空闲状态,那么说明当前网络请求不是很少,那么为了缩短待处理网络请求的平均等待时间,不能立刻调用等待线程处理待处理网络请求,此时等待时长可以为t*/(16-2(N-n)),其中,t0为等待时长,t*为上述平均处理时长,n为当前空闲线程的数量,N为当前空闲线程的数量的最大值。
例如,假设空闲线程的数量的最大值为4,平均处理时长为0.05秒,那么当空闲线程的数量为3时,等待时长0.05/(16-2(4-3))=0.0036秒;那么当空闲线程的数量为2时,等待时长0.05/(16-2(4-2))=0.0042秒;那么当空闲线程的数量为1时,等待时长0.05/(16-2(4-1))=0.0050秒。
可见,在本实施例中,当前空闲线程的数量为最大值时,立刻调用等待线程处理待处理网络请求,能够尽快处理待处理网络请求;在空闲线程的数 量不为最大值时,平均处理时长越长,等待时长越长,当前空闲线程的数量越多,(N-n)的值越小,(16-2(N-n))的值越大,等待时长越短,基于该公式可以确定合适的等待时长。
作为本申请实施例的一种实施方式,如图3所示,在上述调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器的步骤之后,上述方法还可以包括:
S301,获取所述单个合并接口对应的待处理网络请求的处理时长;
由于网络请求的处理时长与网络状况等因素均有关,可能随时发生改变,所以为了使终端确定的等待时长能够适应当前网络状况,终端在调用上述等待线程发送单个合并接口对应的待处理网络请求至服务器之后,可以获取该单个合并接口对应的待处理网络请求的处理时长。
终端可以记录将待处理网络请求发送至服务器的时间点,以及服务器反馈待处理网络请求对应的处理结果的时间点,进而根据两个时间点计算得到待处理网络请求的处理时长。
S302,根据所述处理时长更新所述等待时长。
进而,终端可以根据单个合并接口对应的待处理网络请求的处理时长更新上述等待时长,以使更新后的等待时长更加符合当前网络状况,进一步缩短待处理网络请求的平均等待时长。
可见,在本实施例中,终端在调用上述等待线程发送单个合并接口对应的待处理网络请求至服务器之后,可以获取该单个合并接口对应的待处理网络请求的处理时长,进而更新上述等待时长,可以使更新后的等待时长更加符合当前网络状况,进一步缩短待处理网络请求的平均等待时长。
作为本申请实施例的一种实施方式,上述根据所述处理时长更新所述等待时长的步骤,可以包括:
根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长。
其中,t0’为更新后的平均处理时长,m为正整数,t*为上述平均处理时长,tb为上述单个合并接口对应的待处理网络请求的处理时长。
终端可以将m个平均处理时长与上述单个合并接口对应的待处理网络请求的处理时长的平均值确定为更新后的平均处理时长。例如,m为3,上述平 均处理时长为0.05秒,单个合并接口对应的待处理网络请求的处理时长为0.03秒,那么更新后的平均处理时长即为(3·0.05+0.03)/(3+1)=0.045秒。
在更新上述平均处理时长后,终端便可以根据更新后的平均处理时长确定上述等待时长。
可见,在本实施例中,终端可以根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长,能够根据上述单个合并接口对应的待处理网络请求的处理时长调整上述平均处理时长,使得更新后的平均处理时长更加符合当前网络状况,进一步缩短待处理网络请求的平均等待时长。
作为本申请实施例的一种实施方式,在上述将所获取的待处理网络请求的请求接口合并为单个合并接口的步骤之前,上述方法还可以包括:
获取各待处理网络请求的请求接口的标识。
由于多个请求接口可能为功能不同的请求接口,将多个请求接口合并为单个合并接口后,可能会造成终端接收到服务器返回的网络请求结果时很难分辨每个请求接口对应的请求结果。所以为了区分各请求接口,终端可以获取各待处理网络请求的请求接口的标识。
相应的,上述将所获取的待处理网络请求的请求接口合并为合并接口的步骤,可以包括:
将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录。
终端将所获取的待处理网络请求的请求接口合并为单个合并接口的同时,可以将各待处理网络请求的请求接口的标识作为该单个合并接口的参数进行记录。这样,终端便可以根据各请求接口的标识确定其对应的功能等信息。终端在向服务器发送单个合并接口对应的待处理网络请求时,可以将该参数同时发送给服务器。
进而,在终端获取服务器发送的该单个合并接口对应的网络请求结果之后,如图4所示,上述方法还可以包括:
S401,根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
服务器在对该单个合并接口对应的待处理网络请求进行处理时,上述参 数可以在处理过程中透传,这样服务器发送的单个合并接口对应的网络请求结果中便也携带有上述参数。
终端接收到服务器发送的上述单个合并接口对应的网络请求结果时,由于终端记录有单个合并接口的参数,所以终端可以根据所记录的单个合并接口的参数,对该网络请求结果进行解析,进而得到各待处理网络请求的请求接口对应的请求结果。
终端对单个合并接口对应的网络请求结果进行解析的具体方式可以采用网络请求处理领域的任意网络请求结果解析方式,在此不做具体限定及说明。
S402,将所述请求结果发送至对应的请求接口。
确定了每个待处理网络请求的请求接口对应的请求结果后,终端便可以将各请求结果发送至对应的请求接口,完成网络请求的结果的派发。
可见,在本实施例中,在将所获取的待处理网络请求的请求接口合并为单个合并接口之前,可以获取各待处理网络请求的请求接口的标识,进而将请求接口合并为单个合并接口时,可以将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录。当获取服务器发送的单个合并接口对应的网络请求结果时,可以根据所记录的所述单个合并接口的参数,对网络请求结果进行解析,得到各待处理网络请求的请求接口对应的请求结果,避免将逻辑不相关的请求接口合并导致的接口耦合,不同业务耦合问题,降低后续结果解析及维护成本。
相应于上述网络请求的处理方法,本申请实施例还提供了一种网络请求的处理装置。
下面对本申请实施例所提供的一种网络请求的处理装置进行介绍。
如图5所示,一种网络请求的处理装置,应用于终端,所述装置包括:
空闲线程唤醒模块510,用于当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程;
其中,所述请求队列为所述终端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有空闲线程处于阻塞状态。
等待时间确定模块520,用于确定所述等待线程的等待时间是否达到通过 等待时长确定模块(图5中未示出)预先确定的等待时长;
请求接口合并模块530,用于如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并触发所述空闲线程唤醒模块510,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
网络请求发送模块540,用于调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
可见,本申请实施例所提供的方案中,当待处理网络请求进入为空状态的请求队列时,终端可以唤醒一个空闲线程进入等待状态,作为等待线程,其中,请求队列为客户端当前的待处理网络请求形成的队列,请求队列为空状态时,所有空闲线程处于阻塞状态,然后终端确定等待线程的等待时间是否达到预先确定的等待时长,如果达到预先确定的等待时长,则获取请求队列中的待处理网络请求,进而将请求队列中多个待处理网络请求的请求接口合并为单个合并接口,调用等待线程发送单个合并接口对应的待处理网络请求至服务器。由于终端在确定等待线程的等待时间达到预先确定的等待时长时,调用等待线程发送上述单个合并接口对应的待处理网络请求至服务器,而不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得后续待处理网络请求的等待时间缩短,待网络处理请求的平均等待时间缩短。
作为本申请实施例的一种实施方式,上述装置还可以包括:
触发模块(图5中未示出),用于如果所述等待线程的等待时长未达到所述预先确定的等待时长,触发所述等待时间确定模块520。
作为本申请实施例的一种实施方式,上述等待时间确定模块520可以包括:
获取单元(图5中未示出),用于获取当前空闲线程的数量及网络请求的平均处理时长;
等待时长确定单元(图5中未示出),用于根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
作为本申请实施例的一种实施方式,上述等待时长确定单元可以包括:
等待时长确定子单元(图5中未示出),用于当前空闲线程的数量为最大 值时,t0为0;当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n));
其中,t0为所述等待时长,t*为所述平均处理时长,n为当前空闲线程的数量,N为当前空闲线程的数量的最大值。
作为本申请实施例的一种实施方式,上述装置还可以包括:
处理时长获取模块(图5中未示出),用于在所述调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器之后,获取所述单个合并接口对应的待处理网络请求的处理时长;
处理时长更新模块(图5中未示出),用于根据所述处理时长更新所述平均处理时长。
作为本申请实施例的一种实施方式,上述处理时长更新模块可以包括:
处理时长更新单元(图5中未示出),用于根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长;
其中,t0’为所述更新后的平均处理时长,m为正整数,t*为所述平均处理时长,tb为所述单个合并接口对应的待处理网络请求的处理时长。
作为本申请实施例的一种实施方式,上述装置还可以包括:
标识获取模块(图5中未示出),用于在所述将所获取的待处理网络请求的请求接口合并为单个合并接口之前,获取各待处理网络请求的请求接口的标识;
所述请求接口合并模块540可以包括:
参数记录单元(图5中未示出),用于将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录;
所述装置还可以包括:
结果解析模块(图5中未示出),用于在获取所述服务器发送的所述单个合并接口对应的网络请求结果之后,根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
结果发送模块(图5中未示出),用于将所述请求结果发送至对应的请求接口。
本申请实施例还提供了一种终端,如图6所示,终端可以包括处理器601、通信接口602、存储器603和通信总线604,其中,处理器601,通信接口602,存储器603通过通信总线604完成相互间的通信,
存储器603,用于存放计算机程序;
处理器601,用于执行存储器603上所存放的程序时,实现如下步骤:
当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程;
其中,所述请求队列为所述终端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有空闲线程处于阻塞状态。
确定所述等待线程的等待时间是否达到预先确定的等待时长;
如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并返回所述当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程的步骤,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
可见,本申请实施例所提供的方案中,当待处理网络请求进入为空状态的请求队列时,终端唤醒一个空闲线程进入等待状态,作为等待线程,其中,请求队列为客户端当前的待处理网络请求形成的队列,请求队列为空状态时,所有空闲线程处于阻塞状态,然后终端确定等待线程的等待时间是否达到预先确定的等待时长,如果达到预先确定的等待时长,则获取请求队列中的待处理网络请求,进而将请求队列中多个待处理网络请求的请求接口合并为单个合并接口,调用等待线程发送单个合并接口对应的待处理网络请求至服务器。由于终端在确定等待线程的等待时间达到预先确定的等待时长时,调用等待线程发送上述单个合并接口对应的待处理网络请求至服务器,而不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得后续待处理网络请求的等待时间缩短,待网络处理请求的平均等待时间缩短。
上述终端提到的通信总线可以是外设部件互连标准(Peripheral Component Interconnect,PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture,EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述终端与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital Signal Processing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
其中,如果所述等待线程的等待时长未达到所述预先确定的等待时长,上述方法还可以包括:
返回所述确定所述等待线程的等待时间是否达到预先确定的等待时长的步骤。
其中,上述等待时长的确定方式,可以包括:
获取当前空闲线程的数量及网络请求的平均处理时长;
根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
其中,上述根据当前空闲线程的数量及网络请求的平均处理时长,确定所述等待时长的步骤,可以包括:
当前空闲线程的数量为最大值时,t0为0;
当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n));
其中,t0为所述等待时长,t*为所述平均处理时长,n为当前空闲线程的数量,N为当前空闲线程的数量的最大值。
其中,在上述调用所述等待线程发送所述单个合并接口对应的待处理网 络请求至服务器的步骤之后,上述方法还可以包括:
获取所述单个合并接口对应的待处理网络请求的处理时长;
根据所述处理时长更新所述平均处理时长。
其中,上述根据所述处理时长更新所述平均处理时长的步骤,可以包括:
根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长;
其中,t0’为所述更新后的平均处理时长,m为正整数,t*为所述平均处理时长,tb为所述单个合并接口对应的待处理网络请求的处理时长。
其中,在上述将所获取的待处理网络请求的请求接口合并为单个合并接口的步骤之前,上述方法还可以包括:
获取各待处理网络请求的请求接口的标识;
上述将所获取的待处理网络请求的请求接口合并为合并接口的步骤,可以包括:
将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录;
在获取所述服务器发送的所述单个合并接口对应的网络请求结果之后,上述方法还可以包括:
根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
将所述请求结果发送至对应的请求接口。
本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现以下步骤:
当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程;
其中,所述请求队列为所述终端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有空闲线程处于阻塞状态。
确定所述等待线程的等待时间是否达到预先确定的等待时长;
如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并返回所述当待处理网络请求进入为空状态的请求队列时,唤醒一个 空闲线程进入等待状态,作为等待线程的步骤,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
可见,本申请实施例所提供的方案中,计算机程序被处理器执行时,当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程,其中,请求队列为客户端当前的待处理网络请求形成的队列,请求队列为空状态时,所有空闲线程处于阻塞状态,然后终端确定等待线程的等待时间是否达到预先确定的等待时长,如果达到预先确定的等待时长,则获取请求队列中的待处理网络请求,进而将请求队列中多个待处理网络请求的请求接口合并为单个合并接口,调用等待线程发送单个合并接口对应的待处理网络请求至服务器。由于终端在确定等待线程的等待时间达到预先确定的等待时长时,调用等待线程发送上述单个合并接口对应的待处理网络请求至服务器,而不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得后续待处理网络请求的等待时间缩短,待网络处理请求的平均等待时间缩短。
其中,如果所述等待线程的等待时长未达到所述预先确定的等待时长,上述方法还可以包括:
返回所述确定所述等待线程的等待时间是否达到预先确定的等待时长的步骤。
其中,上述等待时长的确定方式,可以包括:
获取当前空闲线程的数量及网络请求的平均处理时长;
根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
其中,上述根据当前空闲线程的数量及网络请求的平均处理时长,确定所述等待时长的步骤,可以包括:
当前空闲线程的数量为最大值时,t0为0;
当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n));
其中,t0为所述等待时长,t*为所述平均处理时长,n为当前空闲线程的 数量,N为当前空闲线程的数量的最大值。
其中,在上述调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器的步骤之后,上述方法还可以包括:
获取所述单个合并接口对应的待处理网络请求的处理时长;
根据所述处理时长更新所述平均处理时长。
其中,上述根据所述处理时长更新所述平均处理时长的步骤,可以包括:
根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长;
其中,t0’为所述更新后的平均处理时长,m为正整数,t*为所述平均处理时长,tb为所述单个合并接口对应的待处理网络请求的处理时长。
其中,在上述将所获取的待处理网络请求的请求接口合并为单个合并接口的步骤之前,上述方法还可以包括:
获取各待处理网络请求的请求接口的标识;
上述将所获取的待处理网络请求的请求接口合并为合并接口的步骤,可以包括:
将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录;
在获取所述服务器发送的所述单个合并接口对应的网络请求结果之后,上述方法还可以包括:
根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
将所述请求结果发送至对应的请求接口。
本申请实施例还提供了一种计算机程序,该计算机程序用于在运行时执行上述任一实施例所述的网络请求的处理方法步骤。
可见,本申请实施例所提供的方案中,计算机程序被执行时,当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程,其中,请求队列为客户端当前的待处理网络请求形成的队列,请求队列为空状态时,所有空闲线程处于阻塞状态,然后终端确定等待线程的等待时间是否达到预先确定的等待时长,如果达到预先确定的等待时长, 则获取请求队列中的待处理网络请求,进而将请求队列中多个待处理网络请求的请求接口合并为单个合并接口,调用等待线程发送单个合并接口对应的待处理网络请求至服务器。由于终端在确定等待线程的等待时间达到预先确定的等待时长时,调用等待线程发送上述单个合并接口对应的待处理网络请求至服务器,而不是立刻利用所有空闲线程处理最先获取的几个待处理网络请求,使得后续待处理网络请求的等待时间缩短,待网络处理请求的平均等待时间缩短。
需要说明的是,对于上述装置、终端、计算机可读存储介质及计算机程序实施例而言,由于其基本相似于相应方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
进一步需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。
以上所述仅为本申请的较佳实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本申请的保护范围内。

Claims (17)

  1. 一种网络请求的处理方法,其特征在于,应用于终端,所述方法包括:
    当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程,其中,所述请求队列为所述终端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有空闲线程处于阻塞状态;
    确定所述等待线程的等待时间是否达到预先确定的等待时长;
    如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并返回所述当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程的步骤,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
    调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
  2. 如权利要求1所述的方法,其特征在于,如果所述等待线程的等待时长未达到所述预先确定的等待时长,所述方法还包括:
    返回所述确定所述等待线程的等待时间是否达到预先确定的等待时长的步骤。
  3. 如权利要求1或2所述的方法,其特征在于,所述等待时长的确定方式,包括:
    获取当前空闲线程的数量及网络请求的平均处理时长;
    根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
  4. 如权利要求3所述的方法,其特征在于,所述根据当前空闲线程的数量及网络请求的平均处理时长,确定所述等待时长的步骤,包括:
    当前空闲线程的数量为最大值时,t0为0;
    当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n));
    其中,t0为所述等待时长,t*为所述平均处理时长,n为当前空闲线程的数量,N为当前空闲线程的数量的最大值。
  5. 如权利要求3所述的方法,其特征在于,在所述调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器的步骤之后,所述方法还包括:
    获取所述单个合并接口对应的待处理网络请求的处理时长;
    根据所述处理时长更新所述平均处理时长。
  6. 如权利要求5所述的方法,其特征在于,所述根据所述处理时长更新所述平均处理时长的步骤,包括:
    根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长;
    其中,t0’为所述更新后的平均处理时长,m为正整数,t*为所述平均处理时长,tb为所述单个合并接口对应的待处理网络请求的处理时长。
  7. 如权利要求1或2所述的方法,其特征在于,在所述将所获取的待处理网络请求的请求接口合并为单个合并接口的步骤之前,所述方法还包括:
    获取各待处理网络请求的请求接口的标识;
    所述将所获取的待处理网络请求的请求接口合并为合并接口的步骤,包括:
    将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录;
    在获取所述服务器发送的所述单个合并接口对应的网络请求结果之后,所述方法还包括:
    根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
    将所述请求结果发送至对应的请求接口。
  8. 一种网络请求的处理装置,其特征在于,应用于终端,所述装置包括:
    空闲线程唤醒模块,用于当待处理网络请求进入为空状态的请求队列时,唤醒一个空闲线程进入等待状态,作为等待线程,其中,所述请求队列为所述终端当前的待处理网络请求形成的队列,所述请求队列为空状态时,所有 空闲线程处于阻塞状态;
    等待时间确定模块,用于确定所述等待线程的等待时间是否达到通过等待时长确定模块预先确定的等待时长;
    请求接口合并模块,用于如果达到所述预先确定的等待时长,获取所述请求队列中的待处理网络请求,并触发所述空闲线程唤醒模块,并将所述请求队列中多个待处理网络请求的请求接口合并为单个合并接口;
    网络请求发送模块,用于调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器。
  9. 如权利要求8所述的装置,其特征在于,所述装置还包括:
    触发模块,用于如果所述等待线程的等待时长未达到所述预先确定的等待时长,触发所述等待时间确定模块。
  10. 如权利要求8或9所述的装置,其特征在于,所述等待时长确定模块包括:
    获取单元,用于获取当前空闲线程的数量及网络请求的平均处理时长;
    等待时长确定单元,用于根据所述当前空闲线程的数量及所述平均处理时长,确定所述等待时长。
  11. 如权利要求10所述的装置,其特征在于,所述等待时长确定单元包括:
    等待时长确定子单元,用于当前空闲线程的数量为最大值时,t0为0;当前空闲线程的数量不为最大值时,t0=t*/(16-2(N-n));
    其中,t0为所述等待时长,t*为所述平均处理时长,n为当前空闲线程的数量,N为当前空闲线程的数量的最大值。
  12. 如权利要求10所述的装置,其特征在于,所述装置还包括:
    处理时长获取模块,用于在所述调用所述等待线程发送所述单个合并接口对应的待处理网络请求至服务器之后,获取所述单个合并接口对应的待处理网络请求的处理时长;
    处理时长更新模块,用于根据所述处理时长更新所述平均处理时长。
  13. 如权利要求12所述的装置,其特征在于,所述处理时长更新模块包括:
    处理时长更新单元,用于根据公式t0’=(m·t*+tb)/(m+1)计算得到更新后的平均处理时长;
    其中,t0’为所述更新后的平均处理时长,m为正整数,t*为所述平均处理时长,tb为所述单个合并接口对应的待处理网络请求的处理时长。
  14. 如权利要求8或9所述的装置,其特征在于,所述装置还包括:
    标识获取模块,用于在所述将所获取的待处理网络请求的请求接口合并为单个合并接口之前,获取各待处理网络请求的请求接口的标识;
    所述请求接口合并模块包括:
    参数记录单元,用于将所获取的待处理网络请求的请求接口合并为单个合并接口,并将各待处理网络请求的请求接口的标识作为所述单个合并接口的参数进行记录;
    所述装置还包括:
    结果解析模块,用于在获取所述服务器发送的所述单个合并接口对应的网络请求结果之后,根据所记录的所述单个合并接口的参数,对所述网络请求结果进行解析,得到所述各待处理网络请求的请求接口对应的请求结果;
    结果发送模块,用于将所述请求结果发送至对应的请求接口。
  15. 一种终端,其特征在于,包括处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
    存储器,用于存放计算机程序;
    处理器,用于执行存储器上所存放的程序时,实现权利要求1-7任一所述的方法步骤。
  16. 一种计算机可读存储介质,其特征在于,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现权利要求1-7任一 所述的方法步骤。
  17. 一种计算机程序,其特征在于,所述计算机程序用于在运行时执行权利要求1-7任一项所述的方法步骤。
PCT/CN2020/074612 2019-02-22 2020-02-10 一种网络请求的处理方法、装置、终端及存储介质 WO2020168933A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910135297.5A CN109981737B (zh) 2019-02-22 2019-02-22 一种网络请求的处理方法、装置、终端及存储介质
CN201910135297.5 2019-02-22

Publications (1)

Publication Number Publication Date
WO2020168933A1 true WO2020168933A1 (zh) 2020-08-27

Family

ID=67077274

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/074612 WO2020168933A1 (zh) 2019-02-22 2020-02-10 一种网络请求的处理方法、装置、终端及存储介质

Country Status (2)

Country Link
CN (1) CN109981737B (zh)
WO (1) WO2020168933A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112231114A (zh) * 2020-09-22 2021-01-15 深圳云天励飞技术股份有限公司 一种事件处理方法及相关设备
CN112446697A (zh) * 2020-11-12 2021-03-05 深圳海付移通科技有限公司 对账方法、装置、计算机设备和存储介质
CN114221861A (zh) * 2021-03-26 2022-03-22 无锡江南计算技术研究所 一种大规模互连网络的管理包收发方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109981737B (zh) * 2019-02-22 2021-11-26 卓米私人有限公司 一种网络请求的处理方法、装置、终端及存储介质
CN111127706B (zh) * 2019-11-28 2022-04-22 深圳指芯物联技术有限公司 智能锁控制方法、智能锁、云服务器及计算设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102291324A (zh) * 2011-06-28 2011-12-21 北京神州泰岳软件股份有限公司 高并发业务请求处理方法
US20170289313A1 (en) * 2016-03-31 2017-10-05 Dell Products L.P. Combining redirected usb interfaces into a single composite device
CN108306856A (zh) * 2017-12-26 2018-07-20 努比亚技术有限公司 一种接口合并方法、客户端、服务器及计算机可读存储介质
US20180227351A1 (en) * 2011-02-01 2018-08-09 Ebay Inc. Commerce applications between an on-line service and a third-party
CN109981737A (zh) * 2019-02-22 2019-07-05 香港乐蜜有限公司 一种网络请求的处理方法、装置、终端及存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7146481B2 (en) * 2003-03-24 2006-12-05 Lsi Logic Corporation Methods and systems for pre-merge read of configuration data from a foreign volume group inserted in storage array
US9223578B2 (en) * 2009-09-25 2015-12-29 Nvidia Corporation Coalescing memory barrier operations across multiple parallel threads
CN101719929A (zh) * 2009-11-20 2010-06-02 山东中创软件商用中间件股份有限公司 一种实现Web Service下实时数据传输的方法
US9886317B2 (en) * 2015-02-02 2018-02-06 Oracle International Corporation Fine-grained scheduling of work in runtime systems
CN104636957B (zh) * 2015-02-04 2018-07-24 上海瀚之友信息技术服务有限公司 一种处理高并发数据请求的系统和方法
CN108279985B (zh) * 2017-12-22 2021-11-19 努比亚技术有限公司 一种接口请求协议改造方法、设备及计算机可读存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180227351A1 (en) * 2011-02-01 2018-08-09 Ebay Inc. Commerce applications between an on-line service and a third-party
CN102291324A (zh) * 2011-06-28 2011-12-21 北京神州泰岳软件股份有限公司 高并发业务请求处理方法
US20170289313A1 (en) * 2016-03-31 2017-10-05 Dell Products L.P. Combining redirected usb interfaces into a single composite device
CN108306856A (zh) * 2017-12-26 2018-07-20 努比亚技术有限公司 一种接口合并方法、客户端、服务器及计算机可读存储介质
CN109981737A (zh) * 2019-02-22 2019-07-05 香港乐蜜有限公司 一种网络请求的处理方法、装置、终端及存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112231114A (zh) * 2020-09-22 2021-01-15 深圳云天励飞技术股份有限公司 一种事件处理方法及相关设备
CN112446697A (zh) * 2020-11-12 2021-03-05 深圳海付移通科技有限公司 对账方法、装置、计算机设备和存储介质
CN114221861A (zh) * 2021-03-26 2022-03-22 无锡江南计算技术研究所 一种大规模互连网络的管理包收发方法
CN114221861B (zh) * 2021-03-26 2023-07-07 无锡江南计算技术研究所 一种大规模互连网络的管理包收发方法

Also Published As

Publication number Publication date
CN109981737A (zh) 2019-07-05
CN109981737B (zh) 2021-11-26

Similar Documents

Publication Publication Date Title
WO2020168933A1 (zh) 一种网络请求的处理方法、装置、终端及存储介质
WO2021180025A1 (zh) 一种消息处理方法、装置、电子设备及介质
CN111612468B (zh) 一种发送交易信息和共识验证的方法及装置
WO2019075980A1 (zh) 一种线程的调整方法及其终端
US20220263768A1 (en) Method and Apparatus for Node Speed Limiting, Electronic Device and Storage Medium
CN108023829B (zh) 报文处理方法及装置、存储介质、电子设备
CN113918101B (zh) 一种写数据高速缓存的方法、系统、设备和存储介质
CN107257363B (zh) 一种响应请求端请求的方法及系统
WO2020125074A1 (zh) 消息到达率确定方法、装置、数据统计服务器及存储介质
WO2020114059A1 (zh) 一种报警信息的发送方法、装置及电子设备
WO2017156676A1 (zh) 一种针对应用的处理方法、装置及智能终端
WO2023207571A1 (zh) 一种数据传输方法及装置
JP2020080059A (ja) 評価装置、評価方法および評価プログラム
WO2023160092A1 (zh) 一种区块链交易的处理方法、区块链节点及电子设备
CN111382206B (zh) 一种数据存储方法及装置
WO2017091963A1 (zh) 一种信息处理方法及装置
US9239804B2 (en) Back-off mechanism for a peripheral page request log
WO2021197128A1 (zh) 流量限速方法及装置
CN110275780B (zh) 用于限制流量的方法和装置
CN111913815A (zh) 调用请求的处理方法、装置、电子设备及可读存储介质
US20180034749A1 (en) System and method for distributing and replaying trigger packets via a variable latency bus interconnect
US11687271B1 (en) Method for diluting cache space, and device and medium
CN113316230B (zh) 一种发送数据任务调度方法、装置、电子设备及存储介质
CN110008010B (zh) 系统调用方法、装置、设备及可读存储介质
WO2017070869A1 (zh) 一种内存配置方法、装置及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20760247

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20760247

Country of ref document: EP

Kind code of ref document: A1