Access request processing methods, apparatus, devices, media and products

Abstract

This disclosure provides an access request processing method, apparatus, device, medium, and product, relating to the field of Internet technology, which can improve the bandwidth resource utilization of the server. The access request processing method includes: receiving an access request from a requesting end; processing the access request based on the server's expected QPS value and the number of access requests; the expected QPS value is determined based on the server's available bandwidth and the average bandwidth usage of the access requests.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, specifically to an access request processing method, apparatus, device, medium, and product. Background Technology

[0002] Queries Per Second (QPS) is the number of requests a server receives per unit of time, and it is commonly used to represent a server's performance processing capacity. To avoid server overload, a limit is usually set for the QPS, either a minimum limit or a maximum limit, to restrict the number of requests the server can receive per unit of time.

[0003] Currently, the aforementioned request limits are usually fixed values ​​set based on human experience, which cannot fully utilize server resources. Summary of the Invention

[0004] This disclosure provides an access request processing method, apparatus, device, medium, and product that can improve the bandwidth resource utilization of a server.

[0005] In a first aspect, this disclosure provides an access request processing method, comprising: receiving an access request from a requesting end; processing the access request based on the server's expected QPS value and the number of access requests; the expected QPS value is determined based on the server's available bandwidth and the average bandwidth usage of the access requests.

[0006] Secondly, this disclosure also provides an access request processing apparatus, comprising: a communication unit and a processing unit; the communication unit is configured to receive access requests from a requesting end; the processing unit is configured to process the access requests based on the server's expected QPS value and the number of access requests; the expected QPS value is determined based on the server's available bandwidth and the average bandwidth usage of the access requests.

[0007] Thirdly, this disclosure also provides an electronic device comprising: a processor and a memory configured to store processor-executable instructions; wherein the processor is configured to execute instructions to implement the method of the first aspect described above.

[0008] Fourthly, this disclosure also provides a non-volatile storage medium on which a computer program is stored, which, when read and executed, implements the method of the first aspect described above.

[0009] Fifthly, this disclosure also provides a computer program product, including instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect.

[0010] The access request processing method provided in this disclosure can process access requests based on the server's expected QPS value and the number of access requests after receiving them from the requesting end. The expected QPS value is determined based on the server's available bandwidth and the average bandwidth usage of access requests. Therefore, this application can flexibly adjust the electronic device's expected QPS value based on the electronic device's available bandwidth and the average bandwidth usage of access requests, ensuring that the electronic device can fully utilize the available bandwidth to process access requests after receiving them, thereby improving bandwidth resource utilization and avoiding bandwidth waste. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0012] Figure 1 This is a schematic diagram of a communication system provided in an embodiment of the present disclosure;

[0013] Figure 2 A flowchart illustrating an access request processing method provided in an embodiment of this disclosure;

[0014] Figure 3 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0015] Figure 4 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0016] Figure 5 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0017] Figure 6 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0018] Figure 7 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0019] Figure 8 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0020] Figure 9 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0021] Figure 10 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0022] Figure 11A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0023] Figure 12 A flowchart illustrating another access request processing method provided in this disclosure embodiment;

[0024] Figure 13 This is a schematic diagram of the structure of an access request processing device provided in an embodiment of the present disclosure;

[0025] Figure 14 This is a schematic block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0026] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0027] It is understood that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] It should also be understood that the term "comprising" indicates the presence of the described feature, whole, step, operation, element and / or component, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements and / or components.

[0029] The access request processing method provided in this application embodiment can be applied to on-demand scheduling scenarios.

[0030] Specifically, the server can pre-store a large amount of multimedia resources. When a user wants to obtain a specific multimedia resource, the user can perform an operation to obtain that resource on their device. In response to this operation, the user device can send a request message to the server to obtain the multimedia resource. Correspondingly, the server can respond to this request message by sending the multimedia resource to the user device, allowing the user device to display the resource for viewing.

[0031] Optionally, this on-demand scheduling scenario can be applied to a Peer-to-Peer Content Delivery Network (PCDN) scheduling system, or to on-demand scheduling systems developed by various enterprises. This application does not limit this application.

[0032] In practical applications, multiple user devices typically send request messages to the server at the same time. However, the server's request message processing capacity is limited. Therefore, to avoid server overload, a limit QPS fluctuation range, or low limit QPS and high limit QPS, is usually set for the server to limit the number of requests received per unit of time.

[0033] For example, when setting a fluctuation range for the minimum QPS of a server, the fluctuation range can be around 10%. Assuming the minimum QPS is set to process a maximum of 1000 request messages per second, the server can process a maximum of 900-1100 request messages per second depending on actual needs. If there are request messages exceeding the fluctuation range of the minimum QPS, the server can discard the excess request messages.

[0034] Another example is when the server is configured with low minimum QPS and high minimum QPS. Suppose the server is configured with low minimum QPS to process a maximum of 500 request messages per second and high minimum QPS to process a maximum of 1000 request messages per second. Then the server can process 500-1000 request messages per second.

[0035] Currently, the aforementioned request limits (i.e., minimum QPS, or low minimum QPS and high minimum QPS) are typically fixed values, which cannot meet the dynamic demands of the server. For example, request messages sent by the requesting end typically consume a certain amount of bandwidth resources, and the bandwidth usage of request messages sent by the requesting end at different times may vary (e.g., different request content results in different bandwidth usage). If the server's chip processing performance can handle a preset number of request messages, and the bandwidth usage of this preset number of request messages varies at different times, using fixed request limits may lead to wasted or insufficient bandwidth resources.

[0036] To address the aforementioned issues, this application proposes an access request processing method. After receiving an access request from the requesting end, the method processes the access request based on the server's expected QPS value and the number of access requests. The expected QPS value is determined based on the server's available bandwidth and the average bandwidth usage of the access requests. Therefore, this application can flexibly adjust the electronic device's expected QPS value based on the available bandwidth and the average bandwidth usage of the access requests, ensuring that the electronic device can fully utilize the available bandwidth to process access requests, thereby improving bandwidth resource utilization and avoiding bandwidth waste.

[0037] The access request processing method provided in this application embodiment can be applied to... Figure 1 The PCDN scheduling system shown. Figure 1 This is a schematic diagram of a communication system provided in an embodiment of the present disclosure. The communication system may include: at least one requesting end 101, at least one scheduling end 102, and so on. Figure 1 Taking one scheduling terminal 102 as an example, at least one CDN node device 103 ( Figure 1 Taking one CDN node device 103 as an example for illustration) and at least one source data storage device 104 ( Figure 1 (This explanation will be based on a single source data storage device 104.)

[0038] like Figure 1 As shown, in a PCDN scheduling scenario, the user-held request terminal 101 can respond to user operations by sending an access request to the scheduling terminal 102 to request data corresponding to the user's operation. For example, when a user wants to view a video resource, they can perform the operation of viewing the video resource on the request terminal 101. Accordingly, the request terminal 101 can respond to user operations by sending an access request to the scheduling terminal 102 to request the acquisition of the video resource.

[0039] After receiving the access request sent by the requesting end 101, the scheduling end 102 can determine the CDN node device 103 to be forwarded, i.e., the target CDN node device 103, based on the resource to be accessed in the access request and the identifier of the requesting end 101. The target CDN node device 103 stores the data requested by the requesting end 101, such as the video resource in the example above.

[0040] It should be noted that since the scheduling terminal 102 typically forwards access requests from the requesting terminal 101 and does not need to look up the data requested by the access requests, the available bandwidth of the scheduling terminal 102 is generally sufficient to meet the forwarding requirements of the access requests. However, in special circumstances (such as a large number of requesting terminals 101 sending a large number of access requests to the scheduling terminal 102 at the same time), the available bandwidth of the scheduling terminal 102 may not be able to meet the forwarding requirements of the current large number of access requests. In this case, the scheduling terminal 102 can determine whether to drop a certain number of access requests based on the expected QPS value of the scheduling terminal 102 and the number of access requests. The expected QPS value is determined based on the available bandwidth of the scheduling terminal 102 and the average bandwidth usage of the access requests.

[0041] After determining the target CDN node device 103, the scheduling terminal 102 can directly forward the access request from the requesting terminal 101 to the target CDN node device 103, or it can return the routing information of the target CDN node device 103 to the requesting terminal 101, so that the requesting terminal 101 can send an access request to the target CDN node device 103 according to the routing information of the target CDN node device 103.

[0042] After receiving an access request, the target CDN node device 103 can process the access request based on its expected QPS value and the number of access requests. The expected QPS value is determined based on the available bandwidth of the target CDN node device 103 and the average bandwidth usage of the access requests.

[0043] Specifically, if the number of access requests is less than or equal to the expected QPS, and the target CDN node device 103 stores the data requested by the access request, the target CDN node device 103 can send the data requested by the access request to the requesting end 101, such as the video resources in the example above.

[0044] If the number of access requests is less than or equal to the expected QPS, and the target CDN node device 103 does not store the data requested by the access request, the target CDN node device 103 may forward the access request to the source data storage device 104, so that the source data storage device 104 can send the data requested by the access request to the requesting end 101.

[0045] Optionally, the aforementioned requesting terminal 101 may be referred to as user equipment (UE), access terminal, subscriber unit, user station, mobile station (MS), mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device. The terminals in the embodiments of this application may be mobile phones, cellular phones, smartphones, tablets, wireless data cards, personal digital assistants (PDAs), wireless modems, handsets, laptop computers, machine-type communication (MTC) terminals, computers with wireless transceiver capabilities, virtual reality (VR) terminals, augmented reality (AR) terminals, smart home devices (e.g., refrigerators, televisions, air conditioners, electricity meters, etc.), intelligent robots, robotic arms, workshop equipment, wireless terminals in industrial control, wireless terminals in self-driving vehicles, wireless terminals in remote medical care, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, vehicle-mounted terminals, and roadside units with terminal functions. Terminals can be other devices with terminal functions, such as remote sensing units (RSUs), flight equipment (e.g., intelligent robots, hot air balloons, drones, airplanes), etc. For example, a terminal can also be a device that functions as a terminal in end-to-end (device-to-device, D2D) communication.

[0046] Optionally, since the embodiments of this application are typically applied in on-demand scheduling scenarios, the CDN node device 103 described above can be a CDN node server deployed in different regions, and the source data storage device 104 described above can be a server for different applications.

[0047] The aforementioned servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN) services, as well as big data and artificial intelligence platforms.

[0048] Optionally, the devices in the aforementioned PCDN dispatch system can be connected via a network. This network can be a wireless or wired network, such as a Wireless Local Area Network (WLAN), Local Area Network (LAN), cellular network, 4G network, or 5G network. Additionally, different terminals can connect to other terminals or to a server using their own Bluetooth network or hotspot network. For example, multiple users can connect online through different terminals via appropriate networks and synchronize with each other to support multiple users using the same application.

[0049] Understandable Figure 1 The communication system provided in this application embodiment is only one example in this application embodiment. The communication system and corresponding scenarios described in this application embodiment are for the purpose of more clearly illustrating the technical solutions provided in this application embodiment and do not constitute a limitation on the technical solutions provided in this application embodiment. As those skilled in the art will know, with the emergence of new business scenarios, the technical solutions provided in this application embodiment are also applicable to similar technical problems.

[0050] For example, the above is merely one implementation of the access request processing method provided in this application embodiment. The steps executed by the CDN node device 103 can also be executed on other devices connected to the CDN node device 103, and the steps executed by the scheduling terminal 102 can also be executed on other devices connected to the scheduling terminal 102. Since the access request processing method provided in this application can be applied to both the scheduling terminal 102 and the CDN node device 103, this application embodiment collectively refers to the scheduling terminal 102 and the CDN node device 103 as the server. The following describes the access request processing method provided in this application embodiment in detail, taking the server as the execution subject.

[0051] Figure 2 A flowchart illustrating an access request processing method provided in an embodiment of this application is shown. Figure 2 As shown, the access request processing method includes: S201-S202.

[0052] S201. The server receives the access request from the requesting client.

[0053] Optionally, the number of access requests can be one or more. In practical applications, the number of access requests is usually multiple, such as 100.

[0054] Optionally, the above access requests may be multiple access requests sent by different requesting parties at a certain moment (e.g., the current moment), or multiple access requests sent by at least one requesting party during a certain time period (e.g., the current time period).

[0055] For example, in a video-on-demand scheduling scenario, the requesting end can send a request message to the server to obtain multimedia resources.

[0056] A request message sent by a terminal constitutes an access request, which can be sent in the form of a request message. An access request can use a certain amount of bandwidth resources.

[0057] After receiving an access request from the requesting end, in order to facilitate the subsequent determination of the expected QPS and the processing of the access request based on the expected QPS, the server can obtain the average bandwidth usage of the above access request and the available bandwidth of the server.

[0058] In some embodiments, the average bandwidth usage of the above access requests can be obtained in the following ways:

[0059] Since the amount of bandwidth resources used by access requests at different times may vary, the average bandwidth usage mentioned above can be the average bandwidth usage over a preset time period, or it can be the average bandwidth usage at a certain moment (such as the current moment).

[0060] In one possible approach, in order to subsequently determine the expected QPS value related to bandwidth resources, the server can obtain the number of access requests received by the server within a preset time period, as well as the total bandwidth usage of the access requests received by the server within the preset time period, and determine the ratio of the total bandwidth usage to the number of access requests as the average bandwidth usage of the access requests received by the server within the preset time period.

[0061] In another possible implementation, the server can also obtain the number of access requests received by the server at the current moment, as well as the bandwidth usage of each access request, and determine the ratio of the total bandwidth usage of access requests to the number of access requests as the average bandwidth usage of access requests received by the server at the current moment.

[0062] In another possible implementation, the server can also obtain the average bandwidth usage of access requests received by the server in a historical time period (the time period before the preset time period), and predict the average bandwidth usage of access requests received by the server in the preset time period based on the average bandwidth usage of access requests received by the server in the historical time period.

[0063] In another possible implementation, the server can also obtain the average bandwidth usage of access requests used to access the reference device, and determine this average bandwidth usage as the average bandwidth usage of all access requests received by the server. The reference device can be a device with the same or similar application scenario as the server (e.g., another server in the same server cluster), and with the same or similar device parameters such as device model and processing performance.

[0064] In another possible implementation, the server can periodically obtain the average bandwidth usage of access requests to the reference device or server, and determine the average bandwidth usage for a certain time period in the previous period as the average bandwidth usage for that time period in the current period. For example, the server can obtain the average bandwidth usage for each hour of the 12-hour period each day, and determine the average bandwidth usage for the hour from 12:00 to 1:00 yesterday as the average bandwidth usage for the hour from 12:00 to 1:00 today.

[0065] In some embodiments, the available bandwidth of the server can be obtained in the following ways:

[0066] In one feasible approach, the server can obtain its maximum bandwidth and determine its available bandwidth based on that maximum bandwidth.

[0067] In another possible implementation, the server can also obtain the available bandwidth of the server in a historical time period (the time period before the preset time period), and predict the available bandwidth of the server in the preset time period based on the available bandwidth of the server in the historical time period.

[0068] In another possible approach, the server can also obtain the available bandwidth of the reference device and determine the available bandwidth of the reference device as the available bandwidth of the server.

[0069] In another possible implementation, the server can periodically obtain the available bandwidth of the server or reference device and determine the available bandwidth of a certain time period in the previous period as the available bandwidth of that time period in the current period. For example, the server can obtain the available bandwidth for each hour of the 12-hour period each day and determine the available bandwidth of the hour from 12:00 to 1:00 yesterday as the available bandwidth of the hour from 12:00 to 1:00 today.

[0070] S202. The server processes access requests based on the server's expected QPS and the number of access requests.

[0071] The expected QPS value is determined based on the available bandwidth on the server and the average bandwidth usage of access requests.

[0072] Specifically, after obtaining the average bandwidth usage and available bandwidth, in order to process access requests according to the expected QPS, the server can determine the server's expected QPS based on the average bandwidth usage and available bandwidth.

[0073] The QPS expectation value is used to control the server to schedule bandwidth resources based on the QPS expectation value, i.e., to process access requests.

[0074] Specifically, after obtaining the average bandwidth usage and available bandwidth of access requests, in order to accurately determine the expected QPS related to bandwidth resources, the server can determine the server's expected QPS based on the average bandwidth usage and available bandwidth, so that the server can subsequently schedule bandwidth resources according to the expected QPS.

[0075] In one feasible approach, the server can determine the expected QPS based on the ratio of available bandwidth to average bandwidth usage. This ratio ensures that the server's bandwidth resources are fully utilized, improving bandwidth efficiency and preventing waste.

[0076] In another possible approach, if the available bandwidth on the server side is sufficient (i.e., the average bandwidth usage is less than or equal to the available bandwidth), the server can determine the expected QPS based on the number of access requests to ensure that all access requests are processed when the available bandwidth on the server side is sufficient.

[0077] In another possible approach, assuming sufficient available bandwidth on the server side (i.e., when average bandwidth usage is less than or equal to available bandwidth), the server can determine the expected QPS based on the average bandwidth usage over a historical period. For example, if the average bandwidth usage over a historical period is stable (i.e., the fluctuation range of average bandwidth usage at each moment within the historical period does not exceed a preset fluctuation range), the server can continuously use the upper limit of QPS over the historical period as the expected QPS.

[0078] After determining the expected QPS value of the server, since the expected QPS value of the server is related to the amount of available bandwidth on the server, that is, when the number of access requests received by the server is equal to the expected QPS value, the bandwidth resource utilization of the server can reach the optimal level. Therefore, the server can process access requests based on the expected QPS value of the server and the number of access requests.

[0079] In one feasible approach, if the number of access requests exceeds the expected QPS, it indicates that the number of currently received access requests has exceeded the server's expectation. In this case, the server can drop a predetermined number of access requests to optimize the utilization of its bandwidth resources.

[0080] In another possible implementation, if the number of access requests is less than or equal to the expected QPS, it means that the number of access requests currently received has not exceeded the server's expected number. In this case, the server can send the data requested by the access request to the requesting client.

[0081] In some embodiments, before processing access requests, the server needs to determine its expected QPS based on the server's QPS and the number of access requests, and then combine this with... Figure 2 ,like Figure 3 As shown, prior to S203, the access request processing method provided in this application embodiment further includes:

[0082] S301. The server determines the expected QPS value based on the ratio of available bandwidth to average bandwidth usage.

[0083] In this way, by using the ratio of available bandwidth to average bandwidth usage, the server can determine the expected QPS value for bandwidth resource scheduling based on the available bandwidth, thus avoiding the problems of low data transmission efficiency caused by the server's available bandwidth not being able to meet the QPS, or the waste of bandwidth resources caused by the QPS not being able to fully utilize the available bandwidth.

[0084] In one feasible approach, the server can periodically obtain the average bandwidth usage of access requests received at multiple times and determine the expected number of access requests received at those times. Subsequently, a sliding window approach can be used to flexibly determine the expected number of access requests received at the current time (i.e., the QPS expectation) based on the expected number of access requests received at multiple times. This ensures the smoothness of the QPS expectation and avoids resource scheduling instability caused by sudden changes in the QPS expectation.

[0085] In another possible implementation, the server can obtain the average bandwidth usage of the access requests received at the current moment in real time, and determine the expected number of access requests at the current moment, i.e., the QPS expectation value, based on the ratio of the available bandwidth to the average bandwidth usage at the current moment. This ensures the real-time nature of the QPS expectation value and improves the flexibility of resource scheduling.

[0086] In some embodiments, when the average bandwidth usage is the average bandwidth usage of access requests received by the server within a preset time period, the average bandwidth usage of access requests received by the server within the preset time period includes the average bandwidth usage of access requests received by the server in each of multiple sub-time periods; the multiple sub-time periods are multiple sub-time periods within a preset duration prior to the current time. In this case, combined with Figure 3 ,like Figure 4 As shown in S301 above, the method by which the server determines the expected QPS value based on the ratio of available bandwidth to average bandwidth usage specifically includes:

[0087] S401. For any sub-time period among multiple sub-time periods, the server determines the expected number of access requests received by the server in the sub-time period as the ratio of the available bandwidth of the sub-time period to the average bandwidth usage of the access requests received by the server in the sub-time period.

[0088] As described above, the available bandwidth and average bandwidth usage of the server may change over time. Therefore, to accurately determine the expected QPS, it is first necessary to determine the expected number of access requests received by the server in each sub-time period. Next, the server can obtain the available bandwidth for that sub-time period and determine the expected number of access requests received by the server in that sub-time period as the ratio of the available bandwidth to the corresponding average bandwidth usage.

[0089] S402. The server determines the expected QPS value by averaging the expected number of access requests received by the server in multiple sub-time periods.

[0090] Of course, in order to accurately obtain the expected QPS value, the server can also perform data preprocessing on the expected number of access requests corresponding to each sub-time period (such as removing the maximum value, removing the minimum value, etc.), and determine the average of the expected number of access requests corresponding to multiple sub-time periods after data preprocessing as the expected QPS value.

[0091] For example, assuming the current time is 20:10:00 on a certain day, since the most recent historical time period is likely to be most similar to the average bandwidth usage of the current time, the server can obtain the average bandwidth usage of the time period from 20:09:00 to 20:10:00 on the current day (i.e., the preset time period).

[0092] The average bandwidth usage for the period from 20:09:00 to 20:10:00 can include the average bandwidth usage per second, namely the average bandwidth usage within the second from 20:09:00 to 20:09:01, the average bandwidth usage within the second from 20:09:01 to 20:09:02, ..., the average bandwidth usage within the second from 20:09:59 to 20:10:00, for a total of 60 sub-periods (i.e., the average bandwidth usage of multiple sub-periods).

[0093] Regarding the average bandwidth usage within the second of 20:09:00 to 20:09:01, out of the aforementioned 60 average bandwidth usages, assuming the average bandwidth usage within this second is 1M, and the available bandwidth for the time period of 20:09:00 to 20:10:00 is 100M, then the expected number of access requests in the second of 20:09:00 to 20:09:01 is 100 access requests.

[0094] Similarly, for the average bandwidth usage in other seconds, the above method can be used to determine the expected number of access requests per second during the time period from 20:09:00 to 20:10:00, so as to obtain the expected number of 60 access requests.

[0095] In order to accurately determine the expected QPS at the current time (i.e., 20:00:00), the server can use the average of the expected number of the above 60 access requests as the expected QPS.

[0096] As time changes, the server can flexibly determine the expected number of access requests at the current moment, i.e., the QPS expectation value, by using a sliding window to determine the expected number of access requests at multiple moments. This ensures the smoothness of the QPS expectation value and avoids resource scheduling instability caused by sudden changes in the QPS expectation value.

[0097] For example, at the current time of 20:10:01, the server can obtain the expected number of access requests from 20:00:00 and replace the expected number of access requests from 20:09:00 to 20:09:01 in the aforementioned expected number of 60 access requests. That is, based on the expected number of access requests from 20:09:01 to 20:10:01, the expected QPS value for 20:10:01 is determined. This process continues, ensuring that the expected number of access requests per second, i.e., the expected QPS value, is determined based on the expected number of access requests from the most recent sub-time periods, thus improving the accuracy of the expected QPS value.

[0098] In some embodiments, combined with Figure 3 ,like Figure 5 As shown in S301 above, the method by which the server determines the expected QPS value based on the ratio of available bandwidth to average bandwidth usage specifically includes:

[0099] S501. When the average bandwidth usage is less than or equal to the available bandwidth, the server determines the expected QPS value based on the number of access requests.

[0100] Specifically, if the average bandwidth usage is less than or equal to the available bandwidth, it indicates that the server has sufficient available bandwidth. In this case, the server can directly determine the expected QPS value based on the number of access requests.

[0101] In one feasible approach, the server can determine the number of access requests as the expected QPS (Queries Per Second).

[0102] In another possible approach, the server can determine the expected QPS (Queries Per Second) by multiplying the number of access requests by a preset coefficient. This preset coefficient can be flexibly set according to requirements or based on the ratio of available bandwidth to average bandwidth usage. For example, if the ratio is greater than a certain threshold, it indicates a large margin of available bandwidth on the server. In this case, the preset coefficient can be set to a larger value. Conversely, if the ratio is less than a certain threshold, it indicates a small margin of available bandwidth on the server. In this case, the preset coefficient can be set to a smaller value.

[0103] In another possible approach, the expected QPS is determined based on the number of access requests and a preset fluctuation value. The preset fluctuation value can be flexibly set according to requirements or based on the ratio of available bandwidth to average bandwidth usage. For example, if the ratio is greater than a certain threshold, it indicates a large margin of available bandwidth on the server. In this case, the preset fluctuation value can be set to a larger value. Conversely, if the ratio is less than a certain threshold, it indicates a small margin of available bandwidth on the server. In this case, the preset fluctuation value can be set to a smaller value.

[0104] In some embodiments, such as Figure 6 As shown, the average bandwidth usage of access requests received by the server within a preset time period can be obtained in the following ways, that is, the access request processing method provided in this application embodiment further includes:

[0105] S601. The server obtains the number of access requests received by the server within a preset time period.

[0106] Specifically, the number of access requests received by the server may vary at different times. For example, in a video-on-demand scheduling scenario, 8 PM to 9 PM is a period with a high volume of access requests from the client to the server, while 4 AM to 5 AM is a period with a low volume of access requests from the client to the server.

[0107] Therefore, in order to accurately determine the average bandwidth usage over a preset time period, the server can obtain the number of access requests during that time period.

[0108] S602. The server obtains the total bandwidth usage of access requests received by the server within a preset time period.

[0109] Specifically, since each access request uses a certain amount of bandwidth resources, the server can determine the total bandwidth usage of the access requests received by the server within the preset time period by summing the bandwidth usage of the access requests within the preset time period.

[0110] S603. The server determines the average bandwidth usage of the access requests received by the server within a preset time period as the ratio of the total bandwidth usage to the number of access requests.

[0111] In some embodiments, such as Figure 7 As shown, the average bandwidth usage of access requests received by the server within a preset time period can also be obtained in the following ways, that is, the access request processing method provided in this application embodiment further includes:

[0112] S701. The server obtains the average bandwidth usage of access requests received by the server during a historical time period.

[0113] The historical time period refers to the time period prior to the preset time period.

[0114] Specifically, within a certain period, the average bandwidth usage corresponding to access requests may have a certain regularity. Therefore, the server can obtain the average bandwidth usage of access requests received by the server in a historical time period in order to predict the average bandwidth usage of access requests received by the server in a preset time period.

[0115] S702. The server predicts the average bandwidth usage of access requests received in a preset time period based on the average bandwidth usage of access requests received by the server in historical time periods.

[0116] In one feasible approach, the server can predict the average bandwidth usage of access requests received within a preset time period based on the trend of average bandwidth usage changes in access requests received by the server over a historical time period.

[0117] In another possible approach, the server can input the average bandwidth usage of access requests received by the server in a historical time period into the prediction model to predict the average bandwidth usage of access requests received by the server in a preset time period.

[0118] The prediction model can be trained based on training samples. The training samples can include the average bandwidth usage of access requests received by the server over a large number of different time periods.

[0119] In some embodiments, such as Figure 8 As shown, the available bandwidth of the server can be obtained in the following ways, that is, the access request processing method provided in this application embodiment further includes:

[0120] S801, The server obtains the maximum bandwidth available from the server.

[0121] Optionally, the maximum bandwidth can be set at the factory of the server or it can be set by the server based on the current processing performance. This application embodiment does not limit this.

[0122] S802. The server determines the available bandwidth based on the maximum bandwidth.

[0123] In one feasible approach, the server can directly determine its maximum bandwidth as its available bandwidth.

[0124] In another possible approach, directly determining the server's maximum bandwidth as its available bandwidth might reduce server stability if the maximum bandwidth is fully utilized. Therefore, the server can also obtain its maximum bandwidth and multiply it by a preset scaling factor to determine the available bandwidth.

[0125] The preset scaling factor is related to the server's processing performance. The preset scaling factor has a value range of (0,1).

[0126] For example, if the server has superior processing performance, such as a multi-core processor, the preset scaling factor can be set to a larger value, such as 0.9.

[0127] Another example is that when the server-side processing performance is poor, such as when the server-side processor is a single-core processor, the preset scaling factor can be set to a small value, such as 0.7.

[0128] Optionally, the available bandwidth on the server can be a fixed value, or it may change with the server's processing performance or other factors (such as network fluctuations). Therefore, the server can periodically adjust the preset scaling factor so that the server can obtain an accurate amount of available bandwidth.

[0129] In some embodiments, as described above, the available bandwidth of the server may vary at different times. Therefore, when the available bandwidth is the same as the available bandwidth of the server during a preset time period, such as... Figure 9 As shown, the available bandwidth of the server can also be obtained in the following ways, that is, the access request processing method provided in this application embodiment further includes:

[0130] S901. The server obtains the available bandwidth of the server during a historical time period.

[0131] The historical time period refers to the time period prior to the preset time period.

[0132] Specifically, within a certain period, the available bandwidth of the server may exhibit certain regularities. Therefore, the server can obtain the available bandwidth of the server in historical time periods in order to predict the available bandwidth of the server in a preset time period.

[0133] S902. The server predicts the available bandwidth of the server in a preset time period based on the available bandwidth of the server in a historical time period.

[0134] In one feasible approach, the server can predict the available bandwidth for a preset time period based on the trend of changes in the available bandwidth over a historical period.

[0135] In another possible approach, the server can input the available bandwidth of the server in a historical time period into the prediction model to predict the available bandwidth of the server in a preset time period.

[0136] The prediction model can be trained using training samples. These training samples can include a large amount of available bandwidth over different time periods.

[0137] In some embodiments, combined with Figure 2 ,like Figure 10 As shown in S202 above, the method by which the server processes access requests based on the server's expected QPS and the number of access requests specifically includes:

[0138] S1001. If the number of access requests exceeds the expected QPS, the server discards a preset number of access requests and sends the data requested by the undiscarded access requests to the requesting end.

[0139] The preset quantity is the difference between the number of access requests and the expected QPS.

[0140] Specifically, when processing access requests, the server can process the current access request based on the current QPS expectation value, or it can process the access request at a certain time (e.g., the first time) after the QPS expectation value is determined, or it can process the access request at the corresponding time based on the QPS expectation value for the first N time moments after the QPS expectation value is determined. This application embodiment does not limit this.

[0141] If the number of access requests exceeds the expected QPS, it means that the number of access requests received has exceeded the server's expectation. In this case, the server can drop a preset number of access requests to optimize the utilization of its bandwidth resources.

[0142] Optionally, when the server discards a preset number of access requests, it can discard them according to the order in which they were received or according to their priority. This application embodiment does not limit this.

[0143] Of course, the server may also process all access requests in a queue instead of discarding the preset number of access requests, and this application embodiment does not limit this.

[0144] or,

[0145] S1002. If the number of access requests is less than or equal to the expected QPS, the server sends the data requested by the access request to the requesting client.

[0146] If the number of access requests is less than or equal to the expected QPS, it means that the number of access requests received so far has not exceeded the server's expectation. In this case, the server can send the requested data to the requesting client.

[0147] The above mainly describes in detail the various steps of implementing the access request processing method provided in the embodiments of this application. For ease of understanding, the overall flow of implementing the access request processing method provided in the embodiments of this application is described below. Figure 11 As shown, the access request processing method provided in this application embodiment specifically includes:

[0148] S1101. The server obtains the current QPS and the total bandwidth usage of at least one access request.

[0149] The total bandwidth usage satisfies the following formula:

[0150] sum bandwidth=sum(current bandwidth).

[0151] Wherein, sum bandwidth is used to represent the total bandwidth usage of at least one access request, and currentbandwidth is used to represent the current bandwidth usage of each access request.

[0152] S1102. The server determines the current average bandwidth usage as the ratio of the current total bandwidth usage to the current QPS.

[0153] Average bandwidth usage satisfies the following formula:

[0154] average bandwidth=sum bandwidth / current qps.

[0155] Here, average bandwidth represents the average bandwidth usage, and current qps represents the current QPS.

[0156] S1103. The server obtains the current available bandwidth.

[0157] The available bandwidth satisfies the following formula:

[0158] avable bandwith=max bandwidth*avable ratio.

[0159] Here, available bandwidth is used to represent the amount of available bandwidth, maximum bandwidth is used to represent the current maximum bandwidth, and available ratio is used to represent the preset ratio factor.

[0160] S1104. The server determines the current QPS limit as the ratio of the current available bandwidth to the current average bandwidth usage.

[0161] The current QPS cap satisfies the following formula:

[0162] bandwidth qps=avable bandwith / average bandwidth.

[0163] Among them, bandwidth qps is used to represent the current QPS upper limit.

[0164] S1105. The server periodically obtains multiple QPS upper limit values ​​and determines the expected QPS value based on these multiple QPS upper limit values.

[0165] The expected QPS value represents the expected number of access requests at the target time, while multiple QPS upper limits represent the expected number of access requests at multiple times. The target time is located after the multiple times, and the multiple times are the times closest to the target time. The aforementioned period can be the period corresponding to the unit interval, such as one second as one period (also called a schedule unit). The expected QPS value is the upper limit of the number of requests per second (schedule qps) that can be scheduled at the target time.

[0166] S1106. The server processes access requests based on the expected QPS value at the target time.

[0167] The above mainly describes the entire process of implementing the access request processing method provided in the embodiments of this application on the server side. The server-side implementation of the access request processing method provided in the embodiments of this application is typically used in PCDN scheduling systems. Therefore, the following describes the timing flow of implementing the access request processing method provided in the embodiments of this application. Figure 12 As shown, the access request processing method provided in this application embodiment specifically includes:

[0168] S1201, The requesting end sends an access request to the scheduling end.

[0169] Specifically, in a PCDN scheduling scenario, the user-held request client can respond to user actions by sending an access request to the scheduler to retrieve data corresponding to the user's action. For example, when a user wants to view a video resource, they can perform the operation of viewing that video resource on the request client. Correspondingly, the request client can respond to the user action by sending an access request to the scheduler to retrieve that video resource.

[0170] The access request includes the identifier of the requesting party and the identifier of the data requested by the access request.

[0171] Optionally, the number of access requests can be one or more. In practical applications, the number of access requests is usually multiple, such as 100.

[0172] Optionally, the above access requests may be multiple access requests sent by different requesting parties at a certain moment (e.g., the current moment), or multiple access requests sent by at least one requesting party during a certain time period (e.g., the current time period).

[0173] S1202, The scheduling end determines the target CDN node device corresponding to the access request.

[0174] Specifically, after receiving an access request from the requesting end, the scheduling end can determine the CDN node device to be forwarded to, i.e., the target CDN node device, based on the identifier of the data requested in the access request and the identifier of the requesting end. The target CDN node device stores the data requested by the requesting end.

[0175] When multiple CDN node devices store the data requested by the requesting party, the target CDN node device can be the CDN node device closest to the requesting party.

[0176] It should be noted that since the scheduler typically forwards access requests from requesting clients and does not need to look up the data requested by the access requests, its available bandwidth is generally sufficient to meet the forwarding requirements. However, in special circumstances (such as a large number of requesting clients sending a large number of access requests to the scheduler simultaneously), the scheduler's available bandwidth may not be able to meet the forwarding needs of the large number of access requests. In this case, the scheduler can determine whether to drop a certain number of access requests based on its expected QPS and the number of access requests. The expected QPS is determined based on the scheduler's available bandwidth and the average bandwidth usage of the access requests.

[0177] After the target CDN node device is determined, the scheduling terminal can execute S1203A or S1203B1-S1203B2.

[0178] S1203A: The scheduling end forwards the access request to the target CDN node device.

[0179] S1203B1: The scheduling end returns the routing information of the target CDN node device to the requesting end.

[0180] S1203B2, The requesting end sends an access request to the target CDN node device based on the routing information of the target CDN node device.

[0181] S1204. The target CDN node device obtains the available bandwidth and average bandwidth usage of access requests, and determines the expected QPS value of the server based on the available bandwidth and average bandwidth usage of access requests.

[0182] Optionally, the specific implementation method for the target CDN node device to obtain the available bandwidth of the target CDN node device can be referred to the above. Figure 6 or Figure 7 The implementation method provided will not be elaborated here.

[0183] Optionally, the specific implementation method for the target CDN node device to obtain the average bandwidth usage of access requests can be found above. Figure 8 or Figure 9 The implementation method provided will not be elaborated here.

[0184] Optionally, the specific implementation method for the target CDN node device to determine the expected QPS value of the server can be found above. Figure 3 , Figure 4 or Figure 5 The implementation method provided will not be elaborated here.

[0185] S1205A: When the number of access requests is less than or equal to the expected QPS value, and the target CDN node device stores the data requested by the access request, the target CDN node device sends the data requested by the access request to the requesting end.

[0186] S1205B1. If the number of access requests is less than or equal to the expected QPS value, and the target CDN node device does not store the data requested by the access request, the target CDN node device forwards the access request to the source data storage device.

[0187] S1205B2: The target CDN node device receives the data requested by the access request sent by the source data storage device, and sends the data requested by the access request to the requesting end.

[0188] S1205C1. When the number of access requests exceeds the expected QPS, the target CDN node device discards a preset number of access requests. The preset number is the difference between the number of access requests and the expected QPS.

[0189] S1205C2, If the target CDN node device stores the data requested by the non-discarded access request, the target CDN node device sends the data requested by the non-discarded access request to the requesting end.

[0190] S1205C3: If the target CDN node device does not store the data requested by the undropped access request, the target CDN node device forwards the undropped access request to the source data storage device.

[0191] S1205C4: The target CDN node device receives the data requested by the non-discarded access request sent by the source data storage device, and sends the data requested by the non-discarded access request to the requesting end.

[0192] The foregoing mainly describes the solutions of the embodiments of this application from a methodological perspective. It is understood that, in order to implement the above functions, the server includes the corresponding hardware structure and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0193] This application embodiment can divide the server into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0194] like Figure 13 As shown, this application embodiment provides an access request processing device, including: a communication unit 1301 and a processing unit 1302;

[0195] Communication unit 1301 is used to receive access requests from the requesting end;

[0196] Processing unit 1302 is used to process access requests based on the server's expected query rate per second (QPS) and the number of access requests; the expected QPS is determined based on the server's available bandwidth and the average bandwidth usage of access requests.

[0197] Optionally, the processing unit 1302 is also configured to determine the expected QPS value based on the ratio of available bandwidth to average bandwidth usage.

[0198] Optionally, when the average bandwidth usage is the average bandwidth usage of access requests over a preset time period, the average bandwidth usage of access requests over the preset time period includes the average bandwidth usage of access requests in each of the multiple sub-time periods; the multiple sub-time periods are multiple sub-time periods within a preset duration prior to the current time.

[0199] Processing unit 1302 is specifically used for:

[0200] For any sub-time period among multiple sub-time periods, the ratio of the available bandwidth of the sub-time period to the average bandwidth usage of the sub-time period is determined as the expected number of access requests for the sub-time period.

[0201] The average of the expected number of access requests across multiple sub-time periods is determined as the expected QPS.

[0202] Optionally, the processing unit 1302 is also configured to determine the expected QPS value based on the number of access requests when the average bandwidth usage is less than or equal to the available bandwidth.

[0203] Optionally, the processing unit 1302 is specifically used for:

[0204] The number of access requests is determined as the expected QPS.

[0205] Alternatively, the expected QPS value can be determined by multiplying the number of access requests by a preset coefficient.

[0206] Alternatively, the expected QPS can be determined based on the number of access requests and a preset fluctuation value.

[0207] Optionally, the communication unit 1301 is also used to obtain the number of access requests within a preset time period;

[0208] The communication unit 1301 is also used to obtain the total bandwidth usage of the access request within a preset time period;

[0209] The processing unit 1302 is also used to determine the average bandwidth usage of access requests during the preset time period by comparing the total bandwidth usage during the preset time period with the number of access requests during the preset time period.

[0210] Optionally, the communication unit 1301 is also used to obtain the average bandwidth usage of access requests over a historical time period; the historical time period is the time period prior to a preset time period.

[0211] The processing unit 1302 is also used to predict the average bandwidth usage of access requests in a preset time period based on the average bandwidth usage of access requests in historical time periods.

[0212] Optionally, the communication unit 1301 is also used to obtain the maximum bandwidth of the electronic device;

[0213] The processing unit 1302 is also used to determine the available bandwidth based on the maximum bandwidth.

[0214] Optionally, the processing unit 1302 is specifically used for:

[0215] The available bandwidth is determined by multiplying the maximum bandwidth by a preset scaling factor; the preset scaling factor is related to the processing performance of the electronic device.

[0216] Alternatively, the maximum bandwidth can be determined as the available bandwidth.

[0217] Optionally, when the available bandwidth is the available bandwidth of the electronic device in a preset time period, the communication unit 1301 is also used to obtain the available bandwidth of the electronic device in a historical time period; the historical time period is the time period before the preset time period.

[0218] The processing unit 1302 is also configured to predict the available bandwidth of the electronic device in a preset time period based on the available bandwidth of the electronic device in a historical time period.

[0219] Optionally, the processing unit 1302 is specifically used for:

[0220] If the number of access requests exceeds the expected QPS, a preset number of access requests are discarded, and the data requested by the undiscarded access requests is sent to the requesting end; the preset number is the difference between the number of access requests and the expected QPS.

[0221] Alternatively, if the number of access requests is less than or equal to the expected QPS, send the data requested in the access request to the requesting end.

[0222] According to embodiments of the present disclosure, the present disclosure also provides an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the access request processing method provided in the present disclosure.

[0223] According to embodiments of this disclosure, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause an electronic device to execute the access request processing method provided in this disclosure.

[0224] According to embodiments of this disclosure, this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the access request processing method provided in this disclosure.

[0225] Figure 14A schematic block diagram of an example electronic device 1400 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0226] like Figure 14 As shown, the electronic device 1400 includes a computing unit 1401, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory 1402 or a computer program loaded from a storage unit 1408 into a random access memory 1403. The random access memory (RAM) 1403 may also store various programs and data required for the operation of the electronic device 1400. The computing unit 1401, the read-only memory (ROM) 1402, and the RAM 1403 are interconnected via a bus 1404. An input / output (I / O) interface 1405 is also connected to the bus 1404.

[0227] Multiple components in electronic device 1400 are connected to input / output interface 1405, including: input unit 1406, such as keyboard, mouse, etc.; output unit 1407, such as various types of monitors, speakers, etc.; storage unit 1408, such as disk, optical disk, etc.; and communication unit 1409, such as network card, modem, wireless transceiver, etc. Communication unit 1409 allows electronic device 1400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0228] The computing unit 1401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1401 include, but are not limited to, a central processing unit, a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. The computing unit 1401 performs the various methods and processes described above, such as the data matching method. For example, in one embodiment, the data matching method may be implemented as a computer software program tangibly included in a machine-readable medium, such as storage unit 1408. In one embodiment, part or all of the computer program may be loaded and / or installed on the electronic device 1400 via ROM 1402 and / or communication unit 1409. When the computer program is loaded into RAM 1403 and executed by the computing unit 1401, one or more steps of the data matching method described above may be performed. Alternatively, in other embodiments, the computing unit 1401 may be configured to perform a data matching method by any other suitable means (e.g., by means of firmware).

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

[0230] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0231] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

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

[0233] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0234] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0235] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

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

Claims

1. An access request processing method, characterized in that, include: The server obtains the number of access requests and the total bandwidth usage received within a preset time period, and determines the ratio of the total bandwidth usage to the number of access requests as the average bandwidth usage of the access requests received by the server within the preset time period. Obtain the maximum bandwidth of the server and determine the available bandwidth by multiplying the maximum bandwidth by a preset scaling factor. The preset scaling factor is related to the processing performance of the server. The expected query rate (QPS) of the server is determined based on the ratio of the available bandwidth to the average bandwidth usage. Receive access requests from the requesting end; If the number of access requests exceeds the expected QPS value, a preset number of access requests are discarded, and the data requested by the undiscarded access requests is sent to the requesting end; the preset number is the difference between the number of access requests and the expected QPS value. Alternatively, if the number of access requests is less than or equal to the expected QPS value, the data requested by the access request is sent to the requesting end.

2. The method according to claim 1, characterized in that, When the average bandwidth usage is the average bandwidth usage of access requests received by the server within a preset time period, the average bandwidth usage of access requests received by the server within the preset time period includes: the average bandwidth usage of access requests received by the server in each of the multiple sub-time periods; the multiple sub-time periods are multiple sub-time periods within a preset duration prior to the current time. Determining the expected QPS value based on the ratio of available bandwidth to average bandwidth usage includes: For any one of the plurality of sub-time periods, the ratio of the available bandwidth of the sub-time period to the average bandwidth usage of the access requests received by the server in the sub-time period is determined as the expected number of access requests received by the server in the sub-time period. The expected QPS value is determined by averaging the expected number of access requests received by the server in the multiple sub-time periods.

3. The method according to claim 1, characterized in that, The method further includes: If the average bandwidth usage is less than or equal to the available bandwidth, the expected QPS value is determined based on the number of access requests.

4. The method according to claim 3, characterized in that, Determining the expected QPS based on the number of access requests includes: The number of access requests is determined as the expected QPS value; Alternatively, the expected QPS value can be determined by multiplying the number of access requests by a preset coefficient. Alternatively, the expected QPS value can be determined based on the number of access requests and a preset fluctuation value.

5. The method according to claim 1, characterized in that, The method further includes: Obtain the average bandwidth usage of access requests received by the server during a historical time period; the historical time period is the period prior to the preset time period. Based on the average bandwidth usage of access requests received by the server during the historical time period, predict the average bandwidth usage of access requests received by the server during the preset time period.

6. The method according to claim 1, characterized in that, When the available bandwidth is the same as the available bandwidth of the server within a preset time period, the method further includes: Obtain the available bandwidth of the server during a historical time period; the historical time period is the period prior to the preset time period. Based on the available bandwidth of the server in historical time periods, predict the available bandwidth of the server in the preset time period.

7. An access request processing apparatus, characterized in that, include: Communication unit and processing unit; The communication unit is used to obtain the number of access requests and the total bandwidth usage received by the server within a preset time period. The processing unit is used to determine the ratio of the total bandwidth usage to the number of access requests as the average bandwidth usage of the access requests received by the server during the preset time period. The communication unit is also used to obtain the maximum bandwidth of the server. The processing unit is further configured to determine the available bandwidth based on the product of the maximum bandwidth and a preset scaling factor; the preset scaling factor is related to the processing performance of the server. The processing unit is further configured to determine the expected query rate per second (QPS) of the server based on the ratio of the available bandwidth to the average bandwidth usage. The communication unit is also used to receive access requests from the requesting end; The processing unit is further configured to: discard a preset number of access requests when the number of access requests exceeds the expected QPS value, and send the data requested by the undiscarded access requests to the requesting end; the preset number is the difference between the number of access requests and the expected QPS value; Alternatively, if the number of access requests is less than or equal to the expected QPS value, the data requested by the access request is sent to the requesting end.

8. An electronic device, characterized in that, The electronic device includes: processor; A memory configured to store processor-executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1-6.

9. A non-volatile storage medium, characterized in that, The storage medium stores a computer program, which, when read and executed, implements the method as described in any one of claims 1-6.

10. A computer program product, comprising instructions, characterized in that, When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-6.

Images