A reverse weight reduction scheduling method for streaming media services
Through the reverse weight reduction scheduling method of streaming media services, the load data is calculated using hardware configuration values, and streaming media service calls are dynamically adjusted, which solves the problem of inaccurate load situation identification in existing technologies and improves system stability and user experience.
Patent Information
- Application Number
- CN202310645868.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-01
- Publication Date
- 2025-09-16
- Estimated Expiration
- 2043-06-01
AI Technical Summary
Existing streaming media service scheduling methods cannot accurately identify the load conditions of backend streaming media services, resulting in some services being excessively idle or overloaded, affecting system stability and user experience.
A reverse weighted scheduling method for streaming media services is adopted. By testing the relative configuration values of streaming media services and hardware devices, weighted information is calculated and the initial load data is reversely calculated. A load service pool is established, streaming media requests are stored and allocated in order of load values, and the load values are dynamically adjusted to optimize service calls.
It achieves accurate tracking of streaming media service load conditions, avoids excessive idleness or excessive load, and improves system stability and user experience.
Smart Images

Figure CN119071297B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of digital media technology, and in particular to a reverse weight reduction scheduling method for streaming media services. Background Art
[0002] A streaming system can be composed of one or more streaming nodes (generally distributed geographically), depending on the business structure. A streaming node can handle functions such as on-demand, live broadcast, or streaming distribution. Each streaming node is composed of a set of streaming services, which together handle streaming media processing related to different businesses. As the number of visits increases, a single streaming service can only handle a limited number of requests. Therefore, it is necessary to switch excess requests to other streaming services according to certain rules. Otherwise, the streaming service will respond slowly, and prolonged excessive load may cause it to crash, to ensure that the current and other access requests can be fully processed.
[0003] Currently, streaming media service processing mainly adopts the following methods:
[0004] 1. Polling
[0005] Each request is assigned to a different backend service in chronological order. If a backend server crashes, the faulty system is automatically removed, ensuring user access is unaffected. However, this approach has the disadvantage of not considering the load on the backend services and simply assigning requests. This approach makes it impossible to determine whether the backend service being assigned the request is overloaded.
[0006] 2. Polling weight
[0007] A larger polling weight results in a higher probability of assigned access. This approach is primarily used when the performance of each backend server is uneven. Alternatively, different weights can be set for master-slave scenarios to achieve efficient and effective utilization of host resources. A specific polling probability is used, with the polling weight proportional to the access ratio. This approach is used when the performance of backend servers is uneven. The disadvantages of this approach are that it does not consider the load of the backend service and only allocates requests. It cannot determine whether the backend service being assigned the request is overloaded. Furthermore, requests are prioritized for the service with the highest configuration, leaving the service with a lower configuration idle.
[0008] 3. IP hashing algorithm
[0009] Each request is assigned based on the hash result of the access IP address, ensuring that visitors from the same IP address consistently access a single backend server. This approach has the following drawbacks: it ignores the load on the backend service and simply assigns requests. This approach makes it impossible to determine whether the backend service being assigned requests is overloaded. Furthermore, some services may be idle, and if requests from the most shared IP addresses fall on the same backend service, this can severely impact the response speed of that service.
[0010] 4. Fair Algorithm
[0011] The fair algorithm allocates requests based on the response time of the backend server, giving priority to requests with shorter response times. The disadvantages of this method are: it does not consider the load of the backend service and only allocates requests. It cannot determine whether the backend service to which the request is allocated is overloaded. In addition, some services may be idle, and the backend service cannot be judged simply by speed (requests are divided into time-consuming tasks and non-time-consuming tasks). Non-time-consuming tasks frequently fall on services with low load, which may cause the next time-consuming task to fall on this service, affecting the backend service.
[0012] In summary, the main problem with the aforementioned streaming service processing is that it is concentrated on the distribution side, and none of them can accurately identify the load of the backend streaming services. In addition, some streaming services may be excessively idle. Therefore, it is urgent to propose a new streaming service scheduling method to address these problems. Summary of the Invention
[0013] The present invention provides a method for reverse weight reduction scheduling of streaming media services to address the problem that the existing streaming media service processing is centralized on the distribution side and cannot accurately identify the load of the backend streaming services. In addition, some streaming media services may be excessively idle.
[0014] The present invention provides a streaming media service reverse weight reduction scheduling method, comprising the following steps:
[0015] Testing relative configuration values of N streaming services and streaming service processing hardware devices, aggregating and weighting the relative configuration values to obtain weighted information, reversely calculating the weighted information to initialize load data, aggregating the load data into a load service pool, and sequentially sorting and storing the aggregated load data in the load service pool; the load data includes a streaming service number and a current load value of the streaming service;
[0016] The streaming media service with the smallest current load value in the initialization load data is used as the first streaming media service request call object;
[0017] The client sends the first streaming service request and retrieves the streaming service with the smallest current load value from the initial load data. At the same time, the occupied load value of the retrieved streaming service is added to the load value corresponding to the retrieved streaming service to obtain an incremental load value. This value is then reordered together with the load values of the streaming services that were not requested to be retrieved. The streaming service with the smallest load value is then processed by the next streaming service request, and the same process continues from the second streaming service request to the Nth streaming service request.
[0018] The client sends the N+1th streaming service request, deducts the occupied load value of the extracted streaming service from the incremental load value corresponding to the N-1th streaming service processed in the load service pool after the Nth streaming service request, and reorders the load values of all streaming services in the current load pool. The streaming service with the smallest load value is calculated and waits for the next streaming request to call for streaming processing, and then the same process continues from the N+2th streaming service request to the 2Nth streaming service request.
[0019] Furthermore, the relative configuration values of the N streaming media services and the streaming media service processing hardware device are measured by a stress testing tool. The relative configuration value is measured when any one of the component modules of the streaming media service processing hardware device reaches 90% utilization when processing the streaming media service. The component modules of the streaming media service processing hardware device include but are not limited to CPU, memory, and graphics card.
[0020] Furthermore, the weighted information obtained by aggregating and weighting the relative configuration values is specifically as follows: a streaming service processing hardware device H0 is selected from the streaming service processing hardware devices and its relative configuration value is defined as the benchmark weight W0. Suppose the relative configuration values of the remaining streaming service processing hardware devices H1, H2...Hn and the relative configuration value of the selected streaming service processing hardware device H0 have ratio coefficients of K1, K2...Kn respectively, then the weights of the remaining streaming service processing hardware devices H1, H2...Hn are respectively: W1=W0*K1, W2=W0*K2..., Wn=W0*Kn.
[0021] Furthermore, the weighted information is reversely calculated to initialize the load data, specifically:
[0022] The weights W0, W1, W2, ... Wn of multiple streaming service processing hardware devices are added together to obtain the total weight Ws. The weight of the current streaming service processing hardware device is defined as Wm. Then, the load value corresponding to the initialization load data of the current streaming service processing hardware device is calculated by reverse calculation as follows:
[0023] L=(Ws-Wm) / Ws, where L is the load value, rounded to two decimal places, m (1-n).
[0024] Furthermore, the calculation formula for extracting the occupied load value of the streaming media service is:
[0025] Occupied load value = (1 / Ws) * resolution factor
[0026] Wherein, Ws is the total weight obtained by adding the weights of multiple streaming service processing hardware devices, wherein the occupied load value has two decimal places.
[0027] Furthermore, the resolution coefficient ratio setting rule is: the width of the corresponding resolution multiplied by the height is used as the total pixels, and the total pixels of different resolutions divided by the total pixels of 720P are used as the corresponding occupied resource ratio value.
[0028] Furthermore, the ordered sorting storage is sorted according to the current load value of the streaming media service, and the streaming media service current load values with the same size are first inserted first out.
[0029] Furthermore, the stress testing tool is the srs_bench testing algorithm.
[0030] Furthermore, the reference weight W0 is 1.
[0031] Furthermore, after performing streaming processing on the streaming service with the minimum load value, the streaming result is returned to the client.
[0032] At least one of the above technical solutions adopted in the embodiments of the present invention can achieve the following beneficial effects:.
[0033] The present invention can accurately track the load of the current streaming media node and the back-end streaming media service, avoid the situation where a single streaming media service is overloaded and some streaming media services are excessively idle, and can help the node run smoothly and improve the user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0034] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:
[0035] Figure 1 This is a schematic diagram of the streaming media scheduling structure of the present invention;
[0036] Figure 2 This is a flow chart of the reverse weight reduction scheduling method for streaming media services of the present invention. DETAILED DESCRIPTION
[0037] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present invention and corresponding drawings. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.
[0038] The technical solutions provided by various embodiments of the present invention are described in detail below with reference to the accompanying drawings.
[0039] like Figure 1 、 2As shown, the present invention provides a method for reverse weight reduction scheduling of streaming media services, comprising the following steps:
[0040] Test the relative configuration values of N streaming media services and streaming media service processing hardware devices, summarize and weight the relative configuration values to obtain weighted information, reversely calculate the weighted information to initialize load data, summarize the load data into a load service pool, and store the load data summarized in the load service pool in an orderly manner; the load data includes the streaming media service number and the current load value of the streaming media service; wherein the orderly sorted storage is sorted according to the size of the current load value of the streaming media service, and the streaming media services with the same current load value are first inserted first out.
[0041] The streaming media service with the smallest current load value in the initialization load data is used as the first streaming media service request call object;
[0042] The client sends the first streaming service request and retrieves the streaming service with the smallest current load value from the initial load data. At the same time, the occupied load value of the retrieved streaming service is added to the load value corresponding to the retrieved streaming service to obtain an incremental load value. This value is then reordered together with the load values of the streaming services that were not requested to be retrieved. The streaming service with the smallest load value is then processed by the next streaming service request, and the same process continues from the second streaming service request to the Nth streaming service request.
[0043] The client sends the N+1th streaming service request, deducts the occupied load value of the extracted streaming service from the incremental load value corresponding to the N-1th streaming service processed in the load service pool after the Nth streaming service request, and reorders the load values of all streaming services in the current load pool. The streaming service with the smallest load value is calculated and waits for the next streaming request to call for streaming processing, and then the same process continues from the N+2th streaming service request to the 2Nth streaming service request.
[0044] After streaming media processing for the streaming media service with the minimum load value, the streaming media result is returned to the client. Figure 1 As shown, N in this embodiment is 3, and there are three streaming services A, B and C.
[0045] In this embodiment, the relative configuration values of N streaming media services and the streaming media service processing hardware device are measured by a stress testing tool, which is the srs_bench testing algorithm. The relative configuration value is measured when any of the component modules of the streaming media service processing hardware device reaches 90% utilization when processing the streaming media service. The component modules of the streaming media service processing hardware device include but are not limited to CPU, memory, and graphics card.
[0046] In this embodiment, the relative configuration values are aggregated and weighted to obtain weighted information as follows: a streaming service processing hardware device H0 is selected from the streaming service processing hardware devices, and its relative configuration value is defined as the reference weight W0. Suppose the relative configuration values of the remaining streaming service processing hardware devices H1, H2...Hn and the relative configuration value of the selected streaming service processing hardware device H0 have ratio coefficients of K1, K2...Kn respectively. Then, the weights of the remaining streaming service processing hardware devices H1, H2...Hn are respectively: W1=W0*K1, W2=W0*K2..., Wn=W0*Kn; wherein, the reference weight W0 is 1.
[0047] In this embodiment, the weighted information is reversely calculated to initialize the load data, specifically:
[0048] The weights W0, W1, W2, ... Wn of multiple streaming service processing hardware devices are added together to obtain the total weight Ws. The weight of the current streaming service processing hardware device is defined as Wm. Then, the load value corresponding to the initialization load data of the current streaming service processing hardware device is calculated by reverse calculation as follows:
[0049] L=(Ws-Wm) / Ws, where L is the load value, rounded to two decimal places, m (1-n).
[0050] In this embodiment, the calculation formula for obtaining the occupied load value of the streaming media service is:
[0051] Occupied load value = (1 / Ws) * resolution factor
[0052] Wherein, Ws is the total weight obtained by adding the weights of multiple streaming service processing hardware devices, wherein the occupied load value has two decimal places.
[0053] Among them, the different resolutions of streaming media can be 640P, 720P (currently commonly used in the project), 1080P, etc. Taking 720P as the benchmark, the width of the corresponding resolution multiplied by the height is used as the total pixel value, and the total pixels of different resolutions divided by the total pixels of 720P is used as the corresponding resource occupation ratio value.
[0054] 720p means the picture is composed of 720 scan lines, and p stands for progressive scan, which means refreshing the picture line by line. Therefore, the specific resolution of 720p is: width 1280 pixels, height 720 pixels. 1080p (Full HD): resolution is 1920x1080 pixels; 4K (UHD): resolution is 3840x2160 pixels; 8K (UHD): resolution is 7680x4320 pixels. The different proportions are as follows:
[0055] 720P=1280*720=921,600, set the weight to 1;
[0056] 640P=640*480=307,200,307,200 / 921,600 specific gravity is 0.33;
[0057] 1080P=1920*1080=2,073,600, the ratio of 2,073,600 / 921,600 is 2.25;
[0058] The same applies to other resolutions.
[0059] The above implementation method of the present invention is illustrated by way of example:
[0060] like Figure 1 As shown, three streaming services A, B, and C form a cluster. A performance concurrency stress test determines a baseline value for each streaming service. (For example, assuming a 4-core, 4-core CPU can handle 500 streaming requests, an 8-core, 8-core CPU has twice the performance of the baseline.) This method derives the relative configuration values of the streaming services and the streaming service processing hardware. For example, the 4-core, 4-core CPU configuration described above is C, and its relative configuration value is 500 streaming requests. The 500 streaming requests of 4-core, 4-core CPUs are defined as the baseline weight W0, where W0 = 1. If a B configuration with 4 cores and 6 CPUs can handle 600 streaming requests, its weight is 1.2. If a A configuration with 6 cores and 6 CPUs can handle 750 streaming requests, its weight is 1.5.
[0061] In summary, A configuration high can handle 1.5 times the request processing, B configuration average can handle 1.2 times the request processing, and C configuration base can handle 1 times the request processing.
[0062] According to the above rules, the cluster composed of A, B, and C processes a total of 3.7 times the baseline requests. 3.7 is the total weight of the configurations of A, B, and C. The load value corresponding to the reverse calculation of the initial load data is calculated as: L = (Ws - Wm) / Ws. Then, the reverse load calculation initialization ratio is performed for each streaming media (mainly reflecting the reverse characteristics):
[0063] A: (3.7-1.5) / 3.7=0.59 (round to two decimal places);
[0064] B: (3.7-1.2) / 3.7=0.68 (round to two decimal places);
[0065] C: (3.7-1) / 3.7=0.73 (round to two decimal places);
[0066] Next, calculate the load increment of a single request conversion, which is the allocated single streaming load (if none, it is initialized) plus its occupied load value. The calculation method is: occupied load value = 1 / total proportion * resolution coefficient.
[0067] The following example uses a 720P playback request as the condition. Other resolutions need to be multiplied by the corresponding coefficients:
[0068] The load value occupied by a single request is 1 / 3.7=0.27 (rounded to two decimal places), and 0.27 is the aforementioned occupied load value.
[0069] If it is assigned to A, the current value of A load is: 0.59+0.27=0.86;
[0070] If it is assigned to B, the current value of B load is: 0.68+0.27=0.95;
[0071] If it is assigned to C, the current value of C load is: 0.73+0.27=1.
[0072] The load pool is sorted by the lowest load value, and after weighting, it is sorted by value. The lowest load service is selected each time (mainly reflecting the weight reduction feature). The following example uses a 720P playback request as the condition. Other resolutions need to be multiplied by the corresponding coefficient:
[0073] Initialization: A: 0.59B: 0.68C: 0.73The service to be taken out is A;
[0074] After the first request: B: 0.68C: 0.73A: 0.86The service to be retrieved is B;
[0075] After the second request: C: 0.73 A: 0.86 B: 0.95 The service to be retrieved is C;
[0076] After the third request: A: 0.86 B: 0.95 C: 1 The service to be retrieved is A;
[0077] ...and so on;
[0078] The subsequent loop calculates the scores and then takes out the streaming service with the lowest value.
[0079] After the streaming service cluster consisting of A, B, and C is completed, the load value is subtracted, and the weighted values are allocated and sorted by value. The service with the lowest load is taken each time. The following example uses a single 720P playback request as the condition. Other resolutions need to be multiplied by the corresponding coefficient:
[0080] After the third request: A: 0.86 B: 0.95 C: 1 The service to be retrieved is A. At this time, B has completed the processing (when B corresponds to 0.68, the occupied load value 0.27 is added after the processing in the second request above). Then B needs 0.95-0.27=0.68 to restore the original value.
[0081] Therefore, the values are now reordered:
[0082] After the third request: B: 0.68 A: 0.86 C: 1 The service to be retrieved becomes B
[0083] ...and so on;
[0084] After each streaming request is processed, the load quantity is reduced and then reordered to wait for the next request to arrive.
[0085] In summary, the present invention first initializes the weighting of each streaming service based on the hardware configuration, with higher weights assigned to higher hardware configurations and lower weights assigned to lower hardware configurations. This weighting is then reversely converted into a load value, and the loads of each streaming service are aggregated into a load service pool (format: streaming service number + current load value number, with the load values sorted in reverse order, with the stream with the lowest load value appearing first). Each individual streaming request directly retrieves the streaming service with the lowest load, converts the request into an increased load value, and adds it to the capacity of the streaming service. The entire load service pool then recalculates the load, calculating the streaming service with the lowest load for the next streaming request. After the streaming service completes the corresponding request, the load value is subtracted, and the sorting calculation is retriggered.
[0086] Streaming requests can run for a long or short time. Frequent requests and disconnections will put pressure on the streaming cluster. Only when the overall load of the streaming service runs stably can a good user experience be guaranteed. After repeated testing and verification, by setting the running weight according to the hardware configuration, all configured services use the same load buffer pool, record the load of each streaming service, and take out the minimum load media stream to respond to the current request each time. After the streaming is completed, the record of the load buffer pool is modified to dynamically calculate the load situation. This can help avoid load imbalance, effectively utilize the parallel capabilities of the streaming service, and greatly enhance the stability of the streaming service.
[0087] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.
[0088] The foregoing is merely an embodiment of the present invention and is not intended to limit the present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.
Claims
1. A method for reverse weight reduction scheduling of streaming media services, characterized in that: The following steps are involved: Testing relative configuration values of N streaming services and streaming service processing hardware devices, aggregating and weighting the relative configuration values to obtain weighted information, reversely calculating the weighted information to initialize load data, aggregating the load data into a load service pool, and sequentially sorting and storing the aggregated load data in the load service pool; the load data includes a streaming service number and a current load value of the streaming service; The streaming media service with the smallest current load value in the initialization load data is used as the first streaming media service request call object; The client sends the first streaming service request and retrieves the streaming service with the smallest current load value from the initialization load data; At the same time, the occupied load value of the extracted streaming service is added to the load value corresponding to the extracted streaming service to obtain the incremental load value, and the incremental load value is reordered together with the load values of the streaming services that have not been requested to be extracted. The streaming service with the smallest load value is then processed by the next streaming service request, and the same process is repeated from the second streaming service request to the Nth streaming service request. The client sends the N+1th streaming service request, deducts the occupied load value of the extracted streaming service from the incremental load value corresponding to the N-1th streaming service processed in the load service pool after the Nth streaming service request, and reorders the load values of all streaming services in the current load pool. The streaming service with the smallest load value is calculated and waits for the next streaming request to call for streaming processing, and then the same process continues from the N+2th streaming service request to the 2Nth streaming service request.
2. A streaming media service reverse weight reduction scheduling method according to claim 1, characterized in that: The relative configuration values of the N streaming services and the streaming service processing hardware device are measured by a stress testing tool. The relative configuration value is measured when any of the component modules of the streaming service processing hardware device reaches 90% utilization when processing streaming services. The component modules of the streaming service processing hardware device include but are not limited to CPU, memory, and graphics card.
3. A streaming media service reverse weight reduction scheduling method according to claim 1, characterized in that: The weighted information obtained by aggregating and weighting the relative configuration values is specifically as follows: a streaming service processing hardware device H0 is selected from the streaming service processing hardware devices and its relative configuration value is defined as the benchmark weight W0. Suppose the relative configuration values of the remaining streaming service processing hardware devices H1, H2...Hn and the relative configuration value of the selected streaming service processing hardware device H0 have ratio coefficients of K1, K2...Kn respectively, then the weights of the remaining streaming service processing hardware devices H1, H2...Hn are respectively: W1=W0*K1, W2=W0*K2..., Wn=W0*Kn.
4. A streaming media service reverse weight reduction scheduling method according to claim 3, characterized in that: The weighted information is reversely calculated to initialize the load data, specifically: The weights W0, W1, W2, ... Wn of multiple streaming service processing hardware devices are added together to obtain the total weight Ws. The weight of the current streaming service processing hardware device is defined as Wm. Then, the load value corresponding to the initialization load data of the current streaming service processing hardware device is calculated by reverse calculation as follows: L=(Ws-Wm) / Ws, where L is the load value, rounded to two decimal places, m (1-n).
5. A streaming media service reverse weight reduction scheduling method according to claim 4, characterized in that: The calculation formula for the occupied load value of the streaming media service is: Occupied load value = (1 / Ws) * resolution factor Wherein, Ws is the total weight obtained by adding the weights of multiple streaming service processing hardware devices, wherein the occupied load value has two decimal places.
6. A streaming media service reverse weight reduction scheduling method according to claim 5, characterized in that: The resolution coefficient ratio setting rule is: the width of the corresponding resolution multiplied by the height is used as the total pixels, and the total pixels of different resolutions divided by the total pixels of 720P is used as the corresponding occupied resource ratio value.
7. A streaming media service reverse weight reduction scheduling method according to claim 1, characterized in that: The ordered sorting storage is sorted according to the current load value of the streaming media service, and the current load values of the streaming media services with the same value are first inserted first out.
8. A streaming media service reverse weight reduction scheduling method according to claim 2, characterized in that: The stress testing tool is the srs_bench testing algorithm.
9. A streaming media service reverse weight reduction scheduling method according to claim 3, characterized in that: The reference weight W0 is 1.
10. A streaming media service reverse weight reduction scheduling method according to claim 1, characterized in that: After performing streaming processing on the streaming service with the minimum load value, the streaming result is returned to the client.
Citation Information
Patent Citations
Dynamic load balancing method under cloud environment
CN109120715A
A load dispatching method and device
CN109274707A