A processing method, apparatus, device, medium, product

Abstract

The application discloses a processing method, device, equipment, medium and product. The method comprises the following steps: providing state information by a server to a client, so that the state information is used to indicate the request processing performance of the server, so that the state information can represent the request processing speed of the server to a certain extent, so that when the playing progress of a first content sequence on the client reaches a progress threshold determined according to the state information, the client sends a first request to the server, so that the server with the request processing performance can feed back a second content sequence for playing and displaying after the first content sequence to the client according to the first request. In this way, the user experience can be improved while reducing resource waste as little as possible.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a processing method, apparatus, device, medium, or product. Background Technology

[0002] In some scenarios, such as information feeds, the following requirement exists: the content displayed on the client is obtained by requesting the server. For ease of understanding, the following example illustrates this.

[0003] As an example, in a short video recommendation scenario, the client first sends a request to the server so that the server can provide a short video to the client based on the request; then the client plays the short video it received. Summary of the Invention

[0004] This application provides a processing method, apparatus, device, medium, and product that can better improve the user experience.

[0005] To achieve the above objectives, the technical solution provided in this application is as follows:

[0006] This application provides a processing method applied to a client, the method comprising: receiving status information provided by a server, the status information being used to indicate the request processing performance of the server; in response to a first content sequence on the client reaching a progress threshold determined based on the status information, sending a first request to the server, the progress threshold being positively correlated with the request processing performance, the first request being used to request a second content sequence, wherein the playback time of the first content in the second content sequence on the client is later than the playback time of the last content in the first content sequence on the client.

[0007] In one possible implementation, the status information is provided by the server in response to a second request sent by the client, the second request being sent earlier than the first request.

[0008] In one possible implementation, the status information is determined based on the ratio between the number of requests actually carried by the server at the time of receiving the second request and the maximum number of requests carried by the server at each time in the historical time period, obtained by statistical analysis of the number of requests carried by the server at each time in the historical time period. The progress threshold is negatively correlated with the ratio, and each time in the historical time period is earlier than the time of receiving the second request.

[0009] In one possible implementation, the process of determining the status information includes: dividing the requests carried by the server at various times within a historical time period according to at least one parameter to obtain at least one set, wherein two requests belonging to the same set have no difference in parameter values ​​under the at least one parameter, and two requests belonging to different sets have different parameter values ​​under the at least one parameter, wherein the at least one parameter includes physical location and / or request type, and each time within the historical time period is earlier than the reception time of the second request; for any set, performing a statistical analysis on the number of requests in the set to obtain the maximum number of requests carried corresponding to the parameter value of the set, wherein the parameter value of the set is used to indicate the parameter value of each request in the set under the at least one dimension; in response to the second request sent by the client, searching for the maximum number of requests carried corresponding to the specified parameter value from the maximum number of requests carried corresponding to the parameter value of the at least one set according to the parameter value specified by the second request under the at least one parameter, and determining the status information based on the ratio between the number of requests actually carried by the server at the reception time of the second request and the maximum number of requests carried corresponding to the specified parameter value, wherein the specified parameter value is used to indicate the parameter value of the first request under the at least one dimension.

[0010] In one possible implementation, the second request is used only to request the status information, and the second request is triggered by polling.

[0011] In one possible implementation, the second request is the preceding request corresponding to the first request, and the preceding request is used to request the first content sequence and the status information.

[0012] In one possible implementation, the sending time of the subsequent request corresponding to the first request is determined based on the status information fed back by the server in response to the first request. The sending time of the subsequent request is later than the sending time of the first request. The subsequent request is at least used to request a third content sequence from the server. The playback time of the first content in the third content sequence on the client is later than the playback time of the last content in the second content sequence on the client.

[0013] In one possible implementation, the method further includes: receiving timeliness information provided by the server for the status information, the timeliness information being used to indicate the effective time period of a progress threshold determined based on the status information; the step of sending a first request to the server in response to the playback progress of the first content sequence on the client reaching the progress threshold determined based on the status information includes: in response to detecting that the playback progress of the first content sequence on the client reaches the progress threshold within the effective time period, sending a first request to the server.

[0014] In one possible implementation, the method further includes: in response to the fact that the playback progress of the first content sequence on the client has not reached the progress threshold by the termination time indicated by the effective time period, sending a third request to the server in a polling manner, wherein the sending time of the third request is later than the termination time; and in response to the fact that the playback progress of the first content sequence on the client reaches the progress threshold determined based on the status information fed back by the server in response to the third request, sending a first request to the server.

[0015] In one possible implementation, the timeliness information provided by the server for the status information is determined based on the status information, the receiving time of the second request, and the changing pattern of the number of received requests obtained by statistically analyzing the number of requests received by the server at various times in a historical time period.

[0016] In one possible implementation, before sending the first request to the server, the method further includes: updating at least one timeout threshold based on the status information, wherein the updated timeout threshold is used to constrain some or all stages in the sending process of the first request, and each updated timeout threshold is negatively correlated with the request processing performance, and the updated timeout threshold includes a connection establishment timeout threshold, wherein the connection establishment timeout threshold is used to indicate the maximum value of the time consumed when establishing a data transmission connection between the client and the server for the first request.

[0017] This application provides a processing apparatus, comprising: a receiving unit for receiving status information provided by a server, the status information being used to indicate the request processing performance of the server; and a sending unit for sending a first request to the server in response to a first content sequence on the client reaching a progress threshold determined based on the status information, the progress threshold being positively correlated with the request processing performance, the first request being used to request a second content sequence, wherein the playback time of the first content in the second content sequence on the client is later than the playback time of the last content in the first content sequence on the client.

[0018] This application provides an electronic device, the device comprising: a processor and a memory; the memory for storing instructions or computer programs; the processor for executing the instructions or computer programs in the memory, so that the electronic device performs the processing method provided in this application.

[0019] This application provides a computer-readable medium storing instructions or computer programs that, when executed on a device, cause the device to perform the processing method provided in this application.

[0020] This application provides a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the processing method provided in this application.

[0021] Compared with related technologies, this application has at least the following advantages:

[0022] In the technical solution provided in this application, the server provides status information to the client so that the status information can be used to indicate the request processing performance of the server. This allows the status information to characterize the request processing speed of the server to a certain extent. When the playback progress of the first content sequence on the client reaches the progress threshold determined according to the status information, the client sends a first request to the server so that the server with the request processing performance can respond to the first request and provide the client with a second content sequence to be arranged after the first content sequence for playback and display.

[0023] The progress threshold used to indicate the triggering timing (e.g., sending time) of the first request is determined based on the status information provided by the server. This allows the triggering timing of the first request to be dynamically adjusted as the server's request processing performance changes, rather than remaining fixed. This effectively overcomes the shortcomings of a fixed request triggering timing. Furthermore, the progress threshold is positively correlated with the request processing performance indicated by the status information. This means that the progress threshold is larger when the server has good request processing performance (e.g., a fast response time to requests) and smaller when the server has poor request processing performance (e.g., a slow response time to requests). Consequently, when the server has good request processing performance, the first request needs to be sent only when the first content sequence is almost finished playing to reduce resource waste, while when the server has poor request processing performance, the first request needs to be sent shortly after the first content sequence begins playing to reduce waiting time.

[0024] It is evident that the timing of triggering the first request has the following characteristics: when the server has good request processing performance, the first request should be triggered as late as possible to minimize the waste of user traffic and service bandwidth resources when the second content sequence is obtained prematurely due to the user leaving after viewing only part of the first content sequence; however, when the server has poor request processing performance, the first request should be triggered as early as possible to ensure that the client has successfully obtained the second content sequence from the server before the first content sequence finishes playing, thereby ensuring the continuity of content playback on the client and effectively avoiding the deterioration of user experience caused by the user having to wait for a period of time because the second content sequence has not been obtained when the first content sequence has finished playing. This can effectively improve the user experience.

[0025] Based on the above characteristics, it can be seen that the technical solution provided in this application can better improve the balance between user experience and resource waste by dynamically determining the timing of request triggering based on the actual request processing performance of the server, thereby improving user experience while minimizing resource waste. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A schematic diagram illustrating a content acquisition process provided in an embodiment of this application;

[0028] Figure 2 This is a schematic diagram illustrating how new content is retrieved in response to a user operation, as provided in an embodiment of this application.

[0029] Figure 3 This is a schematic diagram illustrating how new content is obtained through a pre-request with a fixed triggering time, as provided in an embodiment of this application.

[0030] Figure 4 This is a schematic diagram illustrating how the request processing performance of a server changes over time, as provided in an embodiment of this application.

[0031] Figure 5 A flowchart illustrating a processing method provided in an embodiment of this application;

[0032] Figure 6 A schematic diagram illustrating a dynamic update process for request triggering timing provided in an embodiment of this application;

[0033] Figure 7 A schematic diagram illustrating another dynamic update process for request triggering timing provided in an embodiment of this application;

[0034] Figure 8 A schematic diagram illustrating a dynamic update process for a timeout threshold provided in an embodiment of this application;

[0035] Figure 9 This is a schematic diagram of the structure of a processing device provided in an embodiment of this application;

[0036] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0037] Research has found that for some information flow scenarios, such as short video recommendation scenarios, the information flow request process in this scenario is similar to... Figure 1 The process described is as follows: When a user is browsing pre-loaded content (such as short videos) using a client, they can express their desire to load more content by triggering an action (such as swiping up) on the client. When the client's interaction module detects this action, it generates a content request. This content request conveys the user's need to "load more content" to the client's network module. The network module then sends a Dynamic Application Programming Interface (API) request to the video streaming server based on this content request. The video streaming server, in turn, sends content data back to the network module based on this API request. This content data describes the characteristics of the new content to be loaded and displayed on the client (such as the short video's URL, number of comments, and title). This allows the network module to utilize these characteristics described by the content data (such as...) Figure 1When the streaming media description information shown is fed back to the interactive module, the interactive module renders and displays these features for the user to view. Additionally, when these features contain the address for retrieving streaming media data (such as short videos), the interactive module can also send a streaming media request (also known as a static resource request) to the network module based on that address. This allows the network module to retrieve the streaming media data indicated by that address from the streaming media server via network communication, and then feed that streaming media data back to the interactive module so that the interactive module can render and display it for the user to view. This allows the user to see new streaming media data and its description information on the client. It is evident that this information flow request process is implemented using both dynamic API requests and static resource requests, enabling the retrieval of not only data that may change over time (such as the comment list of short videos) but also data that will not change over time (such as video data).

[0038] It should be noted that dynamic API requests are used to request data that may change over time (such as the comment list of a short video); static resource requests are used to request data that will not change over time (such as streaming media data such as a short video indicated by a certain address or music indicated by a certain address).

[0039] Research further revealed that for any network request (such as a dynamic API request), the process of a client sending the request to a server involves the following steps: After the client generates the request, it first performs Domain Name System (DNS) resolution on the domain name carried in the request to obtain the server's Internet Protocol Address (IP address). Then, the client requests the server indicated by that IP address to establish a data transmission connection under a certain protocol, such as Transmission Control Protocol (TCP). Once the connection is successfully established, the client transmits the network request to the server, and the server transmits its response data determined in response to the network request back to the client for use. Therefore, the process of sending a network request can generally include three stages: DNS resolution, TCP connection establishment, and data transmission. Since each stage has a certain time cost, in order to prevent the waiting time in each stage from being too long and affecting the user experience, a fixed timeout threshold (such as 5 seconds) can be configured for each stage. Once it is detected that the time consumed by a certain stage (such as TCP connection establishment) exceeds the timeout threshold configured for it and is still not completed, it can be determined that the stage has timed out, and thus the execution of the stage is directly determined to have failed.

[0040] The study also found that because the network request process (such as the sending process) takes a certain amount of time, the method of sending the corresponding request to the server only after determining the user's needs based on the user's actions (such as...) Figure 2 The request triggering method shown can easily lead to users having to wait a long time to see new content, thus affecting the continuity of content playback and display, and consequently reducing the user experience. For example, as shown... Figure 2 As shown, when a user is browsing the first video sequence that has already been loaded on the client, if the user browses to the last video in that first video sequence (e.g., ... Figure 2 When the user swipes up on video 5 (as shown), indicating a desire to load more video content, the client sends a network request to the server. The server then responds with a second video sequence for the user to view. However, this network request process takes time, resulting in a significant time lag between the client receiving the second video sequence and the user swiping up. This causes the user to wait during this time, leading to noticeable stuttering and a negative user experience.

[0041] Research also found that to overcome the shortcomings mentioned above, pre-requesting can be used to retrieve content that meets user needs. Pre-requesting refers to initiating requests in advance and caching results to reduce user waiting time and thus improve user experience. For example, ... Figure 3 As shown, when a user is browsing the first video sequence that has already been loaded on the client, if it is detected that the user's browsing progress for the first video sequence has reached a pre-set fixed progress threshold (such as two videos remaining to be viewed), the client sends a network request to the server so that the server can subsequently respond to the client with the second video sequence. This can reduce the user's waiting time by triggering the network request in advance, thereby improving the continuity of the user experience.

[0042] The research also revealed that the solution described above, implemented through pre-requests with fixed trigger times (e.g., triggering a pre-request when two videos have not been viewed), suffers from two drawbacks: ① While triggering pre-requests more frequently (e.g., four videos before viewing) better ensures a consistent user experience, it easily leads to wasted user traffic and service bandwidth resources due to content retrieved in advance not being viewed, resulting in a high resource waste rate. ② Triggering pre-requests less frequently (e.g., one video before viewing) reduces resource waste, but it can easily result in the client retrieving new content from the server later than the user's action trigger time. This means the user still needs to wait for a period after their action before new content can be retrieved and played, thus degrading the user experience. Based on these drawbacks, it is clear that the solution implemented through pre-requests with fixed trigger times cannot achieve a good balance between user experience and resource waste.

[0043] The study also found that because a large number of users spend a significant amount of time using an application (App), while only a small number of users use the App at other times, the number of requests processed by the server corresponding to the App varies across different time periods, forming peaks and troughs (e.g., ...). Figure 4 The peaks and troughs shown in the diagram. Additionally, when the request volume is high, network operators may impose speed limits, and servers need to handle a large number of concurrent requests, resulting in significant processing latency for requests sent to the server. This degrades both the success rate and latency of requests sent to the server. Specifically, for requests such as... Figure 4 The [start time T] shown start End time T end During this period, when the number of requests peaks, the success rate of request processing decreases, and the processing time increases, resulting in poor server performance. Conversely, when the number of requests troughs, the success rate of request processing increases, and the processing time decreases, leading to better server performance. Therefore, as the number of requests gradually increases, the server's request processing performance (such as success rate and processing time) gradually deteriorates; conversely, as the number of requests gradually decreases, the server's request processing performance gradually improves.

[0044] The study also found that for any given server, the success rate and processing time of request processing vary at different times, resulting in different request processing performance. Consequently, the process of retrieving content from the server in advance by triggering pre-requests at fixed times exhibits different effects at different times. For example, sometimes new content can be retrieved before the user's action, but sometimes it cannot, thus affecting the user experience.

[0045] Based on the above research, in order to better improve the user experience, this application provides a processing method, which includes: the server providing status information to the client so that the status information can be used to indicate the request processing performance of the server, thereby enabling the status information to characterize the request processing speed of the server to a certain extent, so that when the playback progress of the first content sequence on the client reaches the progress threshold determined according to the status information, the client sends a first request to the server, so that the server with the request processing performance can respond to the first request and provide the client with a second content sequence for playback and display after the first content sequence. The progress threshold used to indicate the triggering timing (e.g., sending time) of the first request is determined based on the status information provided by the server. This allows the triggering timing of the first request to be dynamically adjusted as the server's request processing performance changes, rather than remaining fixed. This effectively overcomes the shortcomings of a fixed request triggering timing. Furthermore, the progress threshold is positively correlated with the request processing performance indicated by the status information. This means that the progress threshold is larger when the server has good request processing performance (e.g., a fast response time to requests) and smaller when the server has poor request processing performance (e.g., a slow response time to requests). Consequently, when the server has good request processing performance, the first request needs to be sent only when the first content sequence is almost finished playing to reduce resource waste, while when the server has poor request processing performance, the first request needs to be sent shortly after the first content sequence begins playing to reduce waiting time.

[0046] It is evident that the timing of the first request trigger has the following characteristics: when the server has good request processing performance, the first request should be triggered as late as possible to minimize the waste of user traffic and service bandwidth resources when the second content sequence is obtained prematurely due to the user leaving after viewing only part of the first content sequence; however, when the server has poor request processing performance, the first request should be triggered as early as possible to ensure that the client has successfully obtained the second content sequence from the server before the first content sequence finishes playing, thereby ensuring the continuity of content playback on the client and effectively avoiding the deterioration of user experience caused by the user having to wait for a period of time because the second content sequence has not been obtained when the first content sequence finishes playing. This effectively improves the user experience. Based on these characteristics, the technical solution provided in this application can better balance user experience and resource waste by dynamically determining the request triggering timing based on the actual request processing performance of the server, thereby improving user experience while minimizing resource waste.

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

[0048] To better understand the technical solution provided in this application, the processing method provided in this application will be explained below with reference to some accompanying drawings. For example... Figure 5 As shown, the processing method provided in the embodiments of this application includes S1-S2 below.

[0049] S1: The client receives status information provided by the server, which indicates the server's request processing performance.

[0050] In this context, status information refers to the information provided by the server to the client to inform the server of its current status. This status information can represent the actual request processing performance of the server at the current moment, thereby characterizing, to a certain extent, the success rate and time consumption of the server in request processing at the current moment. Furthermore, this status information can characterize the server's processing characteristics (such as time consumption and success rate) for subsequent pre-requests provided by the client.

[0051] It should be noted that request processing performance is used to represent the quality of a server in processing the requests it receives; and this application does not limit the implementation of the request processing performance, for example, it can be implemented using any index that can characterize the quality of the performance.

[0052] In addition, this application does not limit the way the above-mentioned status information is provided. For example, it can be that the server sends status information to each client once at a preset time interval, so that these clients can know the current status of the server in a timely manner from the status information, so that the clients can dynamically determine the triggering time of the pre-request based on the current status.

[0053] S2: In response to the first content sequence reaching a progress threshold determined based on the status information on the client, the client sends a first request to the server. The progress threshold is positively correlated with the request processing performance indicated by the status information. The first request is used to request a second content sequence, in which the first content in the second content sequence is played later on the client than the last content in the first content sequence.

[0054] The first content sequence refers to the content sequence that the client has obtained from the server and is currently being played and displayed by the client, such as... Figure 6 The first video sequence shown is used so that the timing of triggering a pre-request (such as a first request) can be determined by judging whether the playback progress of the first content sequence on the client has reached a progress threshold determined based on the status information.

[0055] As can be seen, because the progress threshold used to indicate the triggering timing of a pre-request (such as the first request) is determined based on the status information fed back by the server in real time, the triggering timing of the pre-request is dynamically adjusted according to the continuous changes in the server's request processing performance, rather than being fixed. This effectively overcomes the shortcomings that exist when the triggering timing of the pre-request is fixed. In addition, because the progress threshold is positively correlated with the request processing performance indicated by the status information, the progress threshold is larger when the server has good request processing performance (such as a fast response speed to requests) and smaller when the server has poor request processing performance (such as a slow response speed to requests). This means that when the server has good request processing performance, the pre-request needs to be sent when the first content sequence is almost finished playing to reduce resource waste, and when the server has poor request processing performance, the pre-request needs to be sent shortly after the first content sequence begins playing to reduce waiting time. This helps to improve the user experience while minimizing resource waste.

[0056] It should be noted that this application does not limit the process for determining the aforementioned progress threshold. For example, it can be implemented using a pre-built mapping relationship, which records the progress thresholds corresponding to different state information, and this mapping relationship can be configured based on the needs of the actual application scenario. Alternatively, it can be implemented using a pre-trained machine learning model that can predict the progress threshold based on state information.

[0057] The first request refers to a pre-request automatically triggered by the client before any user interaction, used to request the server for a new content sequence to continue playing after the first content sequence has finished. Figure 6 The "Request a second video sequence" request, as shown, allows the client to play and display a second content sequence provided by the server in response to this request, once the client detects the user's action. This second content sequence refers to a content sequence that the client requests in advance from the server while the client is playing and displaying the first content sequence, intended for playback and display after the first content sequence (e.g., [the second content sequence is missing here]). Figure 6 (The second video sequence shown).

[0058] As can be seen, for a client currently playing and displaying the first content sequence, after the client obtains the status information provided by the server, the client first looks up the progress threshold corresponding to the request processing performance indicated by the status information from a pre-built mapping relationship. This progress threshold indicates the triggering time of the pre-request for obtaining the next content sequence (such as the second content sequence) in advance, and thus represents how much content in the first content sequence remains unplayed when the pre-request is triggered. Therefore, the progress threshold can reflect, to some extent, the performance (such as time consumption) of the server in processing the pre-request at the current moment. Then, upon detecting... When the playback progress of the first content sequence on the client reaches the progress threshold, it can be determined that the triggering time of the pre-request has been reached. Therefore, the client can directly send the pre-request to the server, so that the time when the client obtains the next content sequence from the server is no later than the triggering time of the user operation on the client to request the playback of the next content sequence. And the distance between the time when the client obtains the next content sequence from the server and the triggering time of the user operation on the client is as small as possible (such as less than a preset distance threshold). This can better improve the balance between user experience and resource waste, thereby improving user experience while minimizing resource waste.

[0059] Based on the above S1 to S2, the pre-request scheme provided in this application is implemented by dynamically determining the triggering time according to the current state of the server. This scheme has the following characteristics: when the server has good request processing performance (e.g., a fast response speed), the pre-request (e.g., the first request) is triggered as late as possible to minimize the waste of user traffic and service bandwidth resources when the user leaves after viewing only part of the first content sequence; however, when the server has poor request processing performance (e.g., a slow response speed), the pre-request is triggered as early as possible to ensure that the client has successfully obtained the second content sequence from the server before the first content sequence finishes playing. This ensures the continuity of content playback on the client and effectively avoids the user experience degradation caused by waiting for a period of time after the first content sequence has finished playing. This effectively improves the user experience. As can be seen, the technical solution provided in this application can better improve the balance between user experience and resource waste by dynamically determining the triggering time of pre-request requests based on the actual request processing performance of the server, thereby improving user experience while minimizing resource waste.

[0060] Research has revealed that because clients only need to understand the server's request processing performance during certain time periods, when the server provides status information to the client through periodic distribution, a large amount of status information can easily become useless, resulting in a waste of resources.

[0061] Based on the above research, in order to better reduce resource waste, the aforementioned status information can be provided by the server in response to a second request sent by the client. The second request is sent earlier than the first request. In this way, the current status can be obtained by the client actively querying the server before the pre-request is triggered, thereby effectively overcoming the resource waste caused by the server providing status information to the client through periodic distribution.

[0062] As can be seen, in one possible implementation, the process of the server providing status information to the client can be specifically as follows: After the server receives the second request sent by the client, the server can learn from the second request that the client needs to use (or query) the server's current status. Therefore, the server can query its own current status in real time so that the current status can represent the server's request processing performance at the current moment (such as the moment the second request is received). The server can then feed this current status back to the client so that the client can promptly know the server's request processing performance at the current moment. This allows the client to dynamically adjust the triggering timing of pre-requests based on the current status, thus improving the user experience while minimizing resource waste. It should be noted that this application does not limit the method of querying the current status; for example, it can be implemented using any method that allows the server to query its own status.

[0063] Research has shown that at any given time, a significant increase in the number of requests a server needs to process concurrently (also known as concurrent access or load) will drastically worsen its request processing performance; conversely, a significant decrease in the number of requests a server needs to process concurrently will significantly improve its request processing performance. Therefore, the number of requests a server handles at any given time directly impacts its request processing performance.

[0064] The research also revealed that different servers have varying resource capacities, resulting in differences in the maximum number of requests they can handle. This leads to varying processing performance when dealing with the same batch of concurrent requests (e.g., some servers provide fewer resources for this batch of requests, resulting in poorer processing, while others provide more resources, resulting in better processing). Therefore, the maximum number of requests a server can handle also affects its request processing performance.

[0065] Based on the above research, in some scenarios, such as scenarios that require real-time evaluation of request processing performance or scenarios where the current status cannot be obtained through querying, when the above status information is provided by the server in response to the second request sent by the client, the status information can be determined based on the ratio between the number of requests actually carried by the server at the time of receiving the second request (also known as the current number of carried requests) and the maximum number of carried requests obtained by statistical analysis (such as maximum value analysis) of the number of requests carried by the server at various times in the historical time period.

[0066] The aforementioned ratio represents the proportion between the resources currently occupied by the server and the maximum resources the server can provide. This ratio reflects, to some extent, how much resource the server can allocate to process subsequent requests (such as the first request mentioned above). Therefore, the state information determined based on this ratio indicates whether the server has sufficient resources to process subsequent requests at the current moment. This state information better characterizes the server's request processing performance, allowing the progress threshold determined based on this state information (such as the progress threshold obtained by querying the mapping relationship shown in Table 1 below) to more accurately indicate when it is more appropriate to trigger a pre-request on the client. This mapping relationship records the progress thresholds corresponding to different server states.

[0067]

[0068] Table 1. Server-side progress thresholds under different states.

[0069] Furthermore, since the aforementioned ratio can characterize the server's resource usage at the current moment, it can, to some extent, indicate whether the number of requests the server is currently handling is at a peak or trough. This allows the ratio to also indicate the time consumed by the server in processing pre-requests sent by clients (e.g., a larger ratio indicates longer processing time, and a smaller ratio indicates shorter processing time). It is evident that this ratio is negatively correlated with the server's request processing performance (e.g., a larger ratio indicates worse performance, and a smaller ratio indicates better performance). This allows the ratio to, to some extent, characterize the most suitable triggering time for the pre-request at the current moment (e.g., a larger ratio indicates an earlier triggering time, and a smaller ratio indicates a later triggering time). Thus, the progress threshold used to indicate the triggering time is negatively correlated with the ratio, enabling accurate determination of the pre-request triggering time based on this relationship.

[0070] Furthermore, since each time within the aforementioned historical period is earlier than the time the second request was received, the maximum number of requests that can be carried based on this historical period can more accurately characterize the maximum amount of resources used for request processing on the server up to the time the second request was received. This allows the current state determined based on the maximum number of requests that can be carried to better describe the server's request processing performance at the current moment.

[0071] Based on the above four paragraphs, it can be concluded that the server can have at least the following functions: daily statistical analysis of the number of requests handled by the server to determine its maximum request capacity (e.g., 100,000 requests per second). This maximum request capacity represents the maximum amount of resources the server can utilize to process requests. Subsequently, when the server receives a request from a client inquiring about its current status, it first obtains the actual number of requests it is handling at the current moment (e.g., the moment the request is received); then, the server calculates the ratio between the actual number of requests it is handling at the current moment and the maximum request capacity (e.g., ...). Figure 6 Alternatively, the 20th percentile shown in Table 1 above can be used to indicate how much resource the server has used in the current situation. This ratio can, to some extent, indicate how much resource the server can provide for subsequent new requests in the current situation, and thus, to some extent, characterize the server's request processing performance. Therefore, this ratio can be directly fed back to the client as status information, so that the client can know the server's current request processing performance based on the ratio. This allows the client to look up the progress threshold corresponding to the ratio from the pre-built mapping relationship (such as the mapping relationship shown in Table 1) as the trigger time for subsequent pre-requests sent by the client (such as the first request mentioned above). In this way, the triggering time of pre-requests can be dynamically adjusted based on the actual status of the server.

[0072] Research revealed that different types of requests exhibit varying patterns of quantity changes over time. For example, the peak for the first type of request (e.g., consumption requests) occurs at 10 PM, while the peak for the second type (e.g., creation requests) occurs at 12 PM. This results in varying server processing performance for different types of requests at the same time. Furthermore, the quantity changes of requests triggered in different regions also differ over time. For instance, the peak for requests triggered in region 1 occurs at 10 AM, while the peak for requests triggered in region 2 occurs at 3 PM. This again leads to varying server processing performance for requests triggered in different regions at the same time.

[0073] Based on the above research, in order to better meet the request processing needs of different regions and different types, the server can allocate resources according to region and request type, so that different regions are allocated different resources and different types of requests are allocated different resources. This results in different maximum request capacity in different regions and different maximum request capacity in different types. Consequently, the server needs to determine the status information based on the type and sending location of the pre-request provided by the client, so that the status information can more accurately represent the processing performance of the server for the pre-request.

[0074] As can be seen, in some scenarios, such as when a single server allocates different resources to different regions and request types, when the aforementioned status information is provided by the server in response to a second request sent by the client, the process of obtaining this status information can be as follows: First, the server divides the requests carried by the server at different times within a historical time period according to at least one parameter (such as physical location and / or request type), obtaining at least one set (such as a set for recording the first type of request triggered in region A, a set for recording the second type of request triggered in region B, etc.), so that the parameter values ​​of two requests assigned to the same set are not different under at least one parameter, and the parameter values ​​of two requests assigned to different sets are different under at least one parameter, thereby enabling different sets to represent the server's different values ​​under at least one parameter. The server first analyzes the historical request carrying capacity under the parameter value combination. Then, for any set, the server performs a statistical analysis (e.g., maximum value analysis) on the requests in that set to obtain the maximum number of requests that can be carried corresponding to the parameter values ​​of that set. The parameter values ​​of that set are used to indicate the parameter values ​​of each request in that set under at least one dimension. Next, in response to a second request sent by the client, the server, based on the parameter values ​​specified by the second request under at least one parameter (e.g., the sending location of the first request and / or the request type of the first request), searches for the maximum number of requests that can be carried corresponding to the specified parameter value from the maximum number of requests that can be carried corresponding to the parameter values ​​of the at least one set. Finally, based on the ratio between the number of requests actually carried by the server at the time of receiving the second request and the maximum number of requests that can be carried corresponding to the specified parameter value, the server determines the status information. The specified parameter value is used to indicate the parameter value of the first request under at least one dimension, so that the maximum number of requests corresponding to the specified parameter value obtained by querying can represent the maximum resources allocated by the server for the specified parameter value. This allows the status information determined based on the "maximum number of requests corresponding to the specified parameter value" to more accurately represent the server's processing performance for subsequent pre-requests (such as the first request) sent by the client. Consequently, the progress threshold determined based on the status information can more accurately represent the triggering timing that is more suitable for the pre-request.

[0075] It should be noted that, for the above-mentioned at least one parameter, "at least one parameter" refers to the parameter used by the server when allocating resources, so that the "at least one parameter" can represent the parameters required when the client queries the server for the status; and this application does not limit the "at least one parameter", for example, the at least one parameter may include physical location (such as the region where the request is sent) and / or request type.

[0076] It should also be noted that the above-mentioned "parameter value specified by the second request under at least one parameter" is used to describe the characteristics of the pre-request (such as the first request) subsequently sent by the client under the at least one parameter; and this application does not limit the "parameter value specified by the second request under at least one parameter", for example, it may include the sending location (such as the sending region) of the pre-request and / or the request type to which the pre-request belongs.

[0077] Based on the above four paragraphs, it can be concluded that the server can have at least the following functions: It can separately count the number of requests carried by the server in different regions and request types each day to obtain the maximum number of requests the server can carry under different combinations of regions and request types (e.g., the maximum number of requests carried by the server for the first type of request in region A is 100,000 requests per second, and the maximum number of requests carried by the server for the second type of request in region B is 50,000 requests per second, etc.). This allows the maximum number of requests carried for each combination to represent the maximum amount of resources the server can use to process requests under each combination. This is so that when the server receives a request from the client to inquire about the current status (e.g., the second request), it first determines the sending location (e.g., region A) and request type (first type of request) of the subsequent pre-request sent by the client based on the request; then, the server obtains the number of requests of that request type that it is actually carrying at the current time, triggered from the region indicated by the sending location, as the current number of requests carried; and finally, the server calculates this current number of requests carried and the maximum number of requests carried under the combination of the sending location and the request type. The ratio between the number of requests per second (such as the aforementioned 100,000 requests per second) indicates how much of the server's allocated resources for the request processing of the "combination of sending location and request type" have been used at the current moment. This ratio, to some extent, indicates how much resource the server can provide for subsequent new requests received under the "combination of sending location and request type," thus characterizing the server's request processing performance for that "combination of sending location and request type." Therefore, this ratio can be directly fed back to the client as status information, allowing the client to understand the server's current request processing performance. The client can then use this ratio to find the corresponding progress threshold from a pre-built mapping relationship, serving as the triggering time for client-provided pre-requests (such as the first request). This allows for dynamic setting of triggering times for pre-requests of different types and locations at different times, thereby improving user experience while minimizing resource waste.

[0078] Research has found that, to ensure clients can obtain server request processing performance data as quickly as possible, a method of sending independent network requests in a polling manner (e.g., ...) can be used. Figure 6 The status query method shown allows the client to continuously query the server's request processing performance.

[0079] Based on the above research, in one possible implementation, when the aforementioned status information is provided by the server in response to the second request sent by the client, the second request is only used to request the status information from the server, and the second request is triggered by polling. This enables the client to obtain the current status of the server by periodically sending independent network requests at certain time intervals, which helps to ensure that the client can obtain the latest status of the server in a timely manner, and further helps to ensure that the timing of subsequent pre-requests is better.

[0080] It is evident that in some scenarios, such as scenarios with sufficient resources or scenarios with high accuracy requirements, the aforementioned client should have at least the following functions: the client sends a request to the server at preset intervals (e.g., 10 minutes) to inquire about the server's current status, so that the server can provide the client with real-time status information in response to the request. This is beneficial to improving the real-time nature of the status information, thereby improving the triggering effect of the pre-request.

[0081] Research has shown that in some scenarios, such as when users browse content quickly, clients may send multiple pre-requests in a short period of time. Therefore, to better save resources, a request to inquire about the current status of the server can be integrated into the pre-request. This allows the server to not only provide the content sequence of the current request but also the status information that influences the timing of sending the next pre-request. This enables the server to obtain multiple pieces of information with a single request, thereby saving resources.

[0082] Based on the above research, it can be seen that, in one possible implementation, for the first content sequence being played (such as...) Figure 7 For the client of the second video sequence shown, when the above status information is a response from the server to the second request sent by the client (such as...) Figure 7 The status information provided in request 1) shown here is used to influence the first request sent by the client (such as...). Figure 7 The timing of the triggering of request 2), and when the sending time of the second request is earlier than the sending time of the first request, the second request is the preceding request to the first request (e.g., Figure 7Request 1 shown above), the preceding request is used to request the first content sequence and the status information, so that the server can not only provide the first content sequence to the client in response to the preceding request, but also provide the client with the next pre-request (e.g., to influence the preceding request) to affect the preceding request. Figure 7 The status information of the triggering time of request 2) shown can effectively overcome the resource waste caused by obtaining the server's status information by sending independent network requests, thus helping to save resources better.

[0083] It is evident that, in order to better conserve resources, for the first request sent by the client (such as...) Figure 7 Regarding request 2), the server not only provides the client with a second content sequence (such as...) in response to the first request, but also... Figure 7 The third video sequence shown also provides the client with new status information (such as...) in response to the first request. Figure 7 The current state shown is the 80th percentile, so that the subsequent request corresponding to the first request (such as...) Figure 7 The sending time of request 3) shown is determined based on the status information returned by the server in response to the first request. The sending time of the subsequent request is later than the sending time of the first request, and the subsequent request is at least used to request a third content sequence (such as...) from the server. Figure 7 (As shown in the fourth video sequence), the playback time of the first content in the third content sequence on the client is later than the playback time of the last content in the second content sequence requested by the first request. This makes the triggering timing of the next pre-request in the adjacent pre-requests sent by the client determined based on the feedback content provided by the server for the previous pre-request. This helps to significantly reduce the number of requests that need to be triggered to query the current status of the server as in real time as possible, and thus helps to save resources better.

[0084] Based on the above two paragraphs, it can be seen that in some scenarios, such as resource-limited scenarios, ... Figure 7 As shown, the above client has at least the following functions: after starting the client, it first plays the pre-loaded content sequence 1 (e.g., ...) on the client. Figure 7 The first video sequence shown is provided for user viewing so that during playback of this content sequence 1, the client sends an independent network request to the server to inquire about the server's current status, enabling the server to respond to the network request with status information 1 (such as...). Figure 7 The current state shown is the 20th percentile; then, based on the current state described by this state information 1, the client determines pre-request 1 (such as...). Figure 7The timing of request 1) shown is determined so that when the triggering time is reached, the client sends the pre-request 1 to the server to obtain content sequence 2 (such as content sequence 2) that needs to be played after content sequence 1. Figure 7 The second video sequence shown) and state information 2 (such as the triggering timing that influences the next pre-request) Figure 7 The current state shown is the 50th percentile; subsequently, the client determines pre-request 2 (such as...) based on the current state described by this state information 2. Figure 7 The timing of request 2) shown is determined so that when the triggering time is reached, the client sends the pre-request 2 to the server to obtain the content sequence 3 (such as...) that needs to be played after content sequence 2. Figure 7 The third video sequence shown) and state information 3 (such as the triggering timing that influences the next pre-request) Figure 7 The current status shown is the 80th percentile; ... (and so on); until the client is closed.

[0085] Research has revealed that in some situations, after the client receives the content sequence and status information from the server regarding the current pre-request, if the user views the same content within that sequence for an extended period or closes the client due to various factors, the time between sending the next pre-request when the user resumes normal content browsing and the time the client receives the status information from the server regarding the current pre-request can be quite long. This results in the server's status information being almost entirely inaccurate in describing the server's request processing performance when the next pre-request is triggered. Consequently, the triggering timing indicated by the progress threshold determined based on this status information is difficult to align with the next pre-request. This can lead to either increased resource waste due to the next pre-request being triggered too early or increased waiting time for the user to access the next content sequence due to the next pre-request being triggered too late.

[0086] Based on the above research, in order to better overcome the above problems, this application provides an implementation method of the above-mentioned client. In this method, the client not only receives the first content sequence and status information fed back by the server for the previous request (such as the second request mentioned above) corresponding to the first request, but also receives the timeliness information provided by the server for the status information. The timeliness information is used to indicate the effective time period of the request processing performance of the server described by the status information, so that the timeliness information is also used to indicate the effective time period of the progress threshold determined according to the status information. In this way, the client can know from the timeliness information how long the progress threshold is continuously effective, so that in the subsequent response, if the playback progress of the first content sequence on the client reaches the progress threshold within the effective time period, the client sends the first request to the server. In this way, only the effective progress threshold is used to affect the triggering time of the pre-request, thereby better avoiding the defects caused by using the invalid progress threshold to affect the triggering time of the pre-request.

[0087] Furthermore, to better overcome the impact caused by the failure of progress thresholds or status information, this application provides an implementation of the aforementioned client. In this implementation, the client is not only used to receive the first content sequence, status information, and timeliness information indicating the effective period of the progress threshold determined based on the status information from the server in response to the previous request corresponding to the first request (such as the second request mentioned above), but also to: in response to the fact that the playback progress of the first content sequence on the client has not reached the progress threshold by the end time indicated by the effective period, send a third request to the server in a polling manner (such as an independent network request only used to inquire about the current status of the server). The third request is sent later than the termination time, so that the client can continuously query the server for its current status and respond to the first content sequence on the client reaching the progress threshold determined by the status information fed back by the server for the third request (such as the latest third request). In this way, by switching to polling to send independent network requests, the adverse effects caused by the long interval between two adjacent pre-requests sent by the client causing the status information fed back by the server for the previous pre-request to become invalid can be overcome. This is conducive to improving the user experience while minimizing resource waste.

[0088] Based on the above two paragraphs, it can be seen that in some scenarios, after the client receives the content sequence, status information, and corresponding timeliness information from the server regarding the current pre-request, if the user leaves the client or views the content sequence for an extended period, the status information will become invalid due to prolonged inactivity. This causes the time threshold determined based on the status information to also become invalid, making it almost impossible for the triggering timing of the pre-request indicated by the time threshold to match the next pre-request triggered by the client. Therefore, it is possible to continuously obtain new status information from the server by sending independent network requests in a polling manner. This allows the latest status information to be used to determine the triggering timing of the next pre-request when the user resumes normal content browsing on the client, thus improving the user experience while minimizing resource waste.

[0089] It should be noted that this application does not limit the implementation method of the above-mentioned timeliness information. For example, it can be implemented using any kind of information that can describe the effective period of an information, such as a time period, effective duration, or deadline.

[0090] It should also be noted that this application does not limit the method of obtaining the above-mentioned timeliness information. For example, it may refer to fixed information that is set in advance according to the actual application scenario, such as the effective duration of 3 minutes, the effective time period of a certain time period, or the deadline of a certain time point.

[0091] Research has revealed that the varying number of requests on the server side at different times makes it difficult for fixed time-sensitive information to meet the changing patterns of request volume across different time periods. Consequently, the status update process determined based on this fixed time-sensitive information struggles to adapt to the changing update requirements of request volume across different time periods, thus affecting the effectiveness of determining the timing of pre-requests.

[0092] The study also found that although the pattern of changes in the number of requests presented by the server at different times of the same day is different, the pattern of changes in the number of requests presented by the server at different times of the same day is almost constant.

[0093] Based on the above two studies, in order to better overcome the problems caused by fixed timeliness information, when the above status information is provided by the server in response to the second request sent by the client (such as the previous request corresponding to the first request), the timeliness information provided by the server for the status information is determined based on the status information, the receiving time of the second request, and the changing pattern of the number of received requests obtained by statistical analysis of the number of requests received by the server at various times in the historical time period. The "pattern of change in the number of received requests" is obtained through statistical analysis of historical data from the server. This pattern better represents the relatively consistent changes in the number of received requests within different time periods of the same day. Consequently, the timeliness information determined based on this pattern indicates the duration during which the server's status information remains unchanged or undergoes minor changes within a certain range at the time of receiving the second request. This timeliness information also indicates the point in time, based on historical data, at which the status information will drastically change after the second request is received. This makes the timing of pre-request triggering more accurate under the constraints of this timeliness information, thus improving user experience while minimizing resource waste. For clarity, an example is provided below.

[0094] As an example, when the server receives a pre-request from the client at 10:00, the server not only obtains the new content sequence and status information for the pre-request, but also analyzes the effective period of the status information based on the aforementioned "the changing pattern of the number of received requests obtained by statistically analyzing the number of requests received by the server at various times in the historical time period". The analysis results are as follows: the status information remains unchanged or undergoes minor changes within a certain range from 10:00 to the target time (e.g., 11:00). However, after the target time, the server's status changes drastically, allowing the server to determine from the analysis results that the effective period of the status information is [10:00, ...]. The target time period is defined so that the server can subsequently determine this time period [10:00, target time] as the time-sensitive information provided by the server for this status information and feed it back to the client. This allows the client to know from the time-sensitive information that the effective time period of the request processing performance described by the status information is [10:00, target time]. In turn, the client can know from the time-sensitive information that the effective time period of the progress threshold determined based on the status information is [10:00, target time]. This allows the client to determine the triggering time of the pre-request under the constraints of the time-sensitive information, which helps to improve the user experience while minimizing resource waste.

[0095] Research has revealed that server-side request processing performance varies at different times, causing inconsistent processing times for the same network request. This leads to the following drawbacks when a fixed timeout threshold (such as TCP connection establishment timeout) is used for pre-requests: ① If the timeout threshold is set too long (e.g., 60 seconds), users will wait indefinitely in weak network conditions without timely notification of network issues, resulting in ineffective waiting. ② If the timeout threshold is set too short (e.g., 3 seconds), the request success rate may decrease. For example, a pre-request might successfully establish a TCP connection in the 4th second, but fail due to the timeout threshold being reached in the 3rd second, causing the network request to be actively disconnected. Based on these drawbacks, a fixed timeout threshold cannot adapt to the varying request processing performance of the server at different times, resulting in low network request success rates and long processing times.

[0096] Based on the above research, in order to better solve the above problems, this application also provides a possible implementation of the processing method. In this implementation, the processing method may include at least the following steps: After the client receives the status information provided by the server, the client updates at least one timeout threshold (such as the TCP connection establishment timeout threshold) according to the status information, so that the updated timeout threshold is used to constrain part or all of the stages (such as the TCP connection establishment stage) in the sending process of the first request subsequently provided by the client, such that the updated timeout thresholds are negatively correlated with the request processing performance specified by the status information (e.g., the better the request processing performance, the smaller the timeout threshold, but the worse the request processing performance, the larger the timeout threshold, or the mapping relationship shown in Table 2 below, or...). Figure 8 The correspondence shown is as follows, and at least one updated timeout threshold includes a connection establishment timeout threshold, which indicates the maximum allowed time for establishing a data transmission connection (such as a TCP connection) between the client and the server for the first request. This enables the timeout threshold to be dynamically determined based on the server's request processing performance (e.g., dynamically determining different timeout thresholds for different regions and types of pre-requests at different times), thereby effectively overcoming the defects caused by fixed timeout thresholds. It should be noted that this application does not limit the implementation of the "partial or complete stage". For example, when the sending process of the first request includes a domain name resolution stage (such as a DNS resolution stage), a connection establishment stage (such as a TCP connection establishment stage), and a data transmission stage, the "partial or complete stage" may at least include the connection establishment stage.

[0097]

[0098] Table 2. Timeout thresholds for different request processing states on the server side.

[0099] Based on the above processing method, the pre-request implementation scheme provided in this application can be as follows: Since the client is an independent entity, it is difficult for the client to perceive the peaks and troughs of requests. Therefore, the server needs to perceive and identify the peaks and troughs so that during peak periods, because the App is in a high-usage period, it can be inferred that the user tends to continue viewing the content recommended by the App, thus avoiding a lot of resource waste when triggering pre-requests earlier. However, during trough periods, because the App is in a low-usage period, it can be inferred that the user tends not to continue viewing the content recommended by the App, thus avoiding a lot of resource waste when triggering pre-requests later. Based on this, it can be seen that the server needs to perform separate statistics for different regions and different request types to determine the maximum number of requests that the server can bear under each request type in each region. This allows the server to transmit the current status (such as the number of requests currently being carried as a fraction of the maximum number of requests) to the client in a certain way, so that the client can dynamically determine the triggering time of the pre-request and some timeout thresholds of the pre-request (such as the timeout threshold for TCP connection establishment) based on the current status. This is beneficial for dynamically determining the triggering time and timeout threshold of the pre-request for different regions and different types of pre-requests at different times, thus giving the solution the advantages shown in (1)-(3) below.

[0100] (1) The user experience has been optimized, specifically: because the network request latency is large during peak periods, pre-requests are triggered earlier to ensure the continuity of the user experience and reduce waiting; because the network request latency is small during trough periods, the timeout threshold for TCP connection establishment and other stages is reduced, resulting in faster failure and reduced invalid waiting.

[0101] (2) Reduce resource waste, specifically: because network request latency is smaller during off-peak hours, pre-requests are triggered later, reducing the waste of user traffic and service bandwidth resources.

[0102] (3) Improve the success rate of network requests. Specifically, since the network request delay is large during peak periods, increasing the timeout threshold for TCP connection establishment and other stages can effectively improve the success rate of network requests.

[0103] Based on the processing method provided in the embodiments of this application, the embodiments of this application also provide a processing device, which is described below in conjunction with... Figure 9 Explanation and clarification will be provided. Among them, Figure 9 This is a schematic diagram of a processing device provided in an embodiment of this application. It should be noted that for technical details of the processing device provided in this embodiment, please refer to the relevant content of the processing method described above.

[0104] like Figure 9 As shown, the processing apparatus 900 provided in this embodiment includes:

[0105] The receiving unit 901 is used to receive status information provided by the server, the status information being used to indicate the request processing performance of the server;

[0106] Sending unit 902 is configured to send a first request to the server in response to the playback progress of the first content sequence on the client reaching a progress threshold determined based on the status information. The progress threshold is positively correlated with the request processing performance. The first request is used to request a second content sequence, wherein the playback time of the first content in the second content sequence on the client is later than the playback time of the last content in the first content sequence on the client.

[0107] In one possible implementation, the status information is provided by the server in response to a second request sent by the client, the second request being sent earlier than the first request.

[0108] In one possible implementation, the status information is determined based on the ratio between the number of requests actually carried by the server at the time of receiving the second request and the maximum number of requests carried by the server at each time in the historical time period, obtained by statistical analysis of the number of requests carried by the server at each time in the historical time period. The progress threshold is negatively correlated with the ratio, and each time in the historical time period is earlier than the time of receiving the second request.

[0109] In one possible implementation, the process of determining the status information includes: dividing the requests carried by the server at various times within a historical time period according to at least one parameter to obtain at least one set, wherein two requests belonging to the same set have no difference in parameter values ​​under the at least one parameter, and two requests belonging to different sets have different parameter values ​​under the at least one parameter, wherein the at least one parameter includes physical location and / or request type, and each time within the historical time period is earlier than the reception time of the second request; for any set, performing a statistical analysis on the number of requests in the set to obtain the maximum number of requests carried corresponding to the parameter value of the set, wherein the parameter value of the set is used to indicate the parameter value of each request in the set under the at least one dimension; in response to the second request sent by the client, searching for the maximum number of requests carried corresponding to the specified parameter value from the maximum number of requests carried corresponding to the parameter value of the at least one set according to the parameter value specified by the second request under the at least one parameter, and determining the status information based on the ratio between the number of requests actually carried by the server at the reception time of the second request and the maximum number of requests carried corresponding to the specified parameter value, wherein the specified parameter value is used to indicate the parameter value of the first request under the at least one dimension.

[0110] In one possible implementation, the second request is used only to request the status information, and the second request is triggered by polling.

[0111] In one possible implementation, the second request is the preceding request corresponding to the first request, and the preceding request is used to request the first content sequence and the status information.

[0112] In one possible implementation, the sending time of the subsequent request corresponding to the first request is determined based on the status information fed back by the server in response to the first request. The sending time of the subsequent request is later than the sending time of the first request. The subsequent request is at least used to request a third content sequence from the server. The playback time of the first content in the third content sequence on the client is later than the playback time of the last content in the second content sequence on the client.

[0113] In one possible implementation, the receiving unit 901 is further configured to: receive timeliness information provided by the server for the status information, the timeliness information being used to indicate the effective time period of the progress threshold determined based on the status information;

[0114] The sending unit 902 is specifically configured to: in response to detecting that the playback progress of the first content sequence on the client reaches the progress threshold during the effective time period, send a first request to the server.

[0115] In one possible implementation, the sending unit 902 is further configured to: in response to the fact that the playback progress of the first content sequence on the client has not reached the progress threshold by the termination time indicated by the effective time period, send a third request to the server in a polling manner, wherein the sending time of the third request is later than the termination time; and in response to the fact that the playback progress of the first content sequence on the client reaches the progress threshold determined based on the status information fed back by the server in response to the third request, send a first request to the server.

[0116] In one possible implementation, the timeliness information provided by the server for the status information is determined based on the status information, the receiving time of the second request, and the changing pattern of the number of received requests obtained by statistically analyzing the number of requests received by the server at various times in a historical time period.

[0117] In one possible implementation, the processing apparatus 900 further includes: an update unit, configured to update at least one timeout threshold based on the status information before sending the first request to the server, wherein the updated at least one timeout threshold is used to constrain some or all stages of the sending process of the first request, and the updated timeout thresholds are negatively correlated with the request processing performance, and the updated at least one timeout threshold includes a connection establishment timeout threshold, wherein the connection establishment timeout threshold is used to indicate the maximum value of the time consumed when establishing a data transmission connection between the client and the server for the first request.

[0118] In one possible implementation, the processing device 900 is a client provided in this application or the client is deployed on the processing device 900.

[0119] Based on the aforementioned processing device 900, its working principle includes: the server providing status information to the device 900 to indicate the server's request processing performance. This status information can characterize the server's request processing speed to a certain extent. When the playback progress of the first content sequence on the device 900 reaches the progress threshold determined by the status information, the device 900 sends a first request to the server. This allows the server with the request processing performance to respond to the first request by providing the device 900 with a second content sequence to be arranged after the first content sequence for playback and display. This helps to improve the user experience while minimizing resource waste.

[0120] In addition, this application also provides an electronic device, the device including a processor and a memory: the memory is used to store instructions or computer programs; the processor is used to execute the instructions or computer programs in the memory, so that the electronic device performs any implementation of the processing method provided in this application.

[0121] See Figure 10 The diagram illustrates a structural schematic of an electronic device 1000 suitable for implementing embodiments of the present disclosure. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0122] like Figure 10As shown, the electronic device 1000 may include a processing unit (e.g., a central processing unit, a graphics processor, etc.) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1008 into a random access memory (RAM) 1003. The RAM 1003 also stores various programs and data required for the operation of the electronic device 1000. The processing unit 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0123] Typically, the following devices can be connected to the I / O interface 1005: input devices 1006 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 1007 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1008 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows electronic device 1000 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 10 An electronic device 1000 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0124] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 1009, or installed from storage device 1008, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of embodiments of this disclosure.

[0125] The electronic device provided in this embodiment belongs to the same inventive concept as the method provided in the above embodiments. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0126] This application also provides a computer-readable medium storing instructions or a computer program that, when executed on a device, causes the device to perform any implementation of the processing method provided in this application.

[0127] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0128] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0129] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0130] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, enable the electronic device to perform the aforementioned methods.

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

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0133] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units / modules do not necessarily limit the specific unit itself.

[0134] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0135] 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. A machine-readable medium 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 (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0136] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

[0137] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0138] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0139] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0140] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A processing method, characterized in that, The method is applied to a client, and the method includes: Receive status information provided by the server, the status information being used to indicate the request processing performance of the server; In response to the first content sequence reaching a progress threshold determined based on the status information on the client, a first request is sent to the server. The progress threshold is positively correlated with the request processing performance. The first request is used to request a second content sequence, wherein the playback time of the first content in the second content sequence on the client is later than the playback time of the last content in the first content sequence on the client.

2. The method according to claim 1, characterized in that, The status information is provided by the server in response to a second request sent by the client, the second request being sent earlier than the first request.

3. The method according to claim 2, characterized in that, The status information is determined based on the ratio between the number of requests actually carried by the server at the time of receiving the second request and the maximum number of requests carried by the server at each time in the historical time period, obtained by statistical analysis of the number of requests carried by the server at each time in the historical time period. The progress threshold is negatively correlated with the ratio, and each time in the historical time period is earlier than the time of receiving the second request.

4. The method according to claim 2, characterized in that, The process of determining the status information includes: Based on at least one parameter, the requests carried by the server at each time within a historical time period are divided to obtain at least one set. Two requests belonging to the same set have no difference in parameter values ​​under the at least one parameter, while two requests belonging to different sets have different parameter values ​​under the at least one parameter. The at least one parameter includes physical location and / or request type. Each time within the historical time period is earlier than the reception time of the second request. For any of the sets, a statistical analysis of the number of requests in the set is performed to obtain the maximum number of requests that can be carried corresponding to the parameter values ​​of the set. The parameter values ​​of the set are used to indicate the parameter values ​​of each request in the set under the at least one dimension. In response to a second request sent by the client, based on the parameter value specified in the second request under the at least one parameter, the maximum number of requests corresponding to the specified parameter value is searched from the maximum number of requests corresponding to the parameter values ​​in the at least one set, and the status information is determined based on the ratio between the number of requests actually carried by the server at the time of receiving the second request and the maximum number of requests corresponding to the specified parameter value, wherein the specified parameter value is used to indicate the parameter value of the first request under the at least one dimension.

5. The method according to claim 2, characterized in that, The second request is only used to request the status information, and the second request is triggered by polling.

6. The method according to claim 2, characterized in that, The second request is the preceding request to the first request, and the preceding request is used to request the first content sequence and the status information.

7. The method according to claim 6, characterized in that, The sending time of the subsequent request corresponding to the first request is determined based on the status information fed back by the server in response to the first request. The sending time of the subsequent request is later than the sending time of the first request. The subsequent request is at least used to request a third content sequence from the server. The playback time of the first content in the third content sequence on the client is later than the playback time of the last content in the second content sequence on the client.

8. The method according to claim 6, characterized in that, The method further includes: Receive timeliness information provided by the server for the status information, the timeliness information being used to indicate the effective time period of the progress threshold determined based on the status information; The step of sending a first request to the server in response to the playback progress of the first content sequence on the client reaching a progress threshold determined based on the status information includes: In response to detecting that the playback progress of the first content sequence on the client reaches the progress threshold during the effective time period, a first request is sent to the server.

9. The method according to claim 8, characterized in that, The method further includes: If the playback progress of the first content sequence on the client has not reached the progress threshold by the termination time indicated by the effective time period, a third request is sent to the server in a polling manner, and the third request is sent after the termination time. In response to the first content sequence reaching a progress threshold determined based on the status information returned by the server in response to the third request on the client, a first request is sent to the server.

10. The method according to claim 6, characterized in that, The timeliness information provided by the server for the status information is determined based on the status information, the receiving time of the second request, and the changing pattern of the number of received requests obtained by statistical analysis of the number of requests received by the server at various times in a historical time period.

11. The method according to any one of claims 1-10, characterized in that, Before sending the first request to the server, the method further includes: At least one timeout threshold is updated based on the status information. The updated timeout threshold is used to constrain some or all stages of the sending process of the first request. The updated timeout thresholds are negatively correlated with the request processing performance. The updated timeout threshold includes a connection establishment timeout threshold, which is used to indicate the maximum time consumed when establishing a data transmission connection between the client and the server for the first request.

12. A processing apparatus, characterized in that, include: A receiving unit is configured to receive status information provided by the server, the status information being used to indicate the request processing performance of the server; A sending unit is configured to send a first request to the server in response to the playback progress of a first content sequence on the client reaching a progress threshold determined based on the status information. The progress threshold is positively correlated with the request processing performance. The first request is used to request a second content sequence, wherein the playback time of the first content in the second content sequence on the client is later than the playback time of the last content in the first content sequence on the client.

13. An electronic device, characterized in that, The device includes: a processor and a memory; The memory is used to store instructions or computer programs; The processor is configured to execute the instructions or computer program in the memory to cause the electronic device to perform the method according to any one of claims 1-11.

14. A computer-readable medium, characterized in that, The computer-readable medium stores instructions or computer programs that, when executed on the device, cause the device to perform the method according to any one of claims 1-11.

15. A computer program product, characterized in that, It includes a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the method according to any one of claims 1-11.

Images