Server dynamic load dynamic adjustment system and method

Abstract

The application provides a kind of server dynamic load dynamic adjustment system and method, comprising: real-time monitoring module, for continuously collecting the data of server frame loss rate, Lua memory occupation, C++ memory occupation and network packet queue length;Hierarchical response module, according to the data collected by the real-time monitoring module and the preset threshold are compared, and four throttle grades of limit, warning, load and safety are divided out, and the grade change is confirmed by the sliding window algorithm smoothing instantaneous fluctuation;Self-adaptive throttle control module, based on the throttle grade executes corresponding operation, including at least one of closing non-core service, token bucket flow control, automatic shrinkage / extension, forced to remove inactive users;Load prediction module, through historical data analysis, current active user number and external event factor, predict future traffic peak and trigger early warning mechanism.

Description

Technical Field

[0001] This invention relates to the field of server dynamic load design technology, and more specifically, to a server dynamic load dynamic adjustment system and method. Background Technology

[0002] With the rapid development and widespread adoption of the internet, online games have become a significant form of leisure and entertainment. In the operation of online games, servers play a crucial role. Servers are responsible not only for storing, transmitting, and synchronizing game data, but also for multiple tasks such as player authentication, game logic calculations, real-time interaction, and the construction and maintenance of the game world.

[0003] Server stability and performance optimization have always been key areas of technological innovation. With the rapid growth of the online user base, servers face unprecedented pressure and challenges, especially during peak hours, where server load capacity often becomes a bottleneck restricting gaming experience and business expansion. Against this backdrop, designing and implementing an efficient and intelligent mechanism for dynamically adjusting server parameters is particularly important.

[0004] Traditional server management methods often rely on static configurations, making it difficult to flexibly respond to sudden traffic spikes or changes in user behavior patterns. This can easily lead to server overload, causing serious problems such as game latency, lag, and even server crashes. This not only impacts user experience but can also result in economic losses and damage to brand reputation. Therefore, developing a mechanism that can monitor server status in real time, dynamically adjust settings such as limiting the number of online players, intelligently identify and prioritize the removal of low-value user sessions, and automatically switch algorithms to cost-effective execution modes based on load has become crucial for improving server stability, optimizing resource utilization, and ensuring service quality. This mechanism effectively balances server load and user experience through accurate prediction and rapid response, ensuring stable server operation in high-concurrency scenarios while maximizing the use of existing hardware resources and reducing operating costs. Furthermore, this intelligent dynamic adjustment strategy promotes the continuous availability of game services, enhances user stickiness, and lays a solid technological foundation for the company's long-term development. In conclusion, developing and applying such a mechanism for dynamically adjusting server parameters is an indispensable and crucial step in addressing current and future internet service challenges and improving overall service quality.

[0005] In early server management and maintenance practices, a model based on server platform monitoring and manual intervention was typically adopted. This process begins with the server platform continuously monitoring various key indicators, including but not limited to CPU utilization, memory usage, disk I / O, network bandwidth, and performance metrics of specific applications. Once these monitoring data exceed preset security thresholds or abnormal patterns are detected, the server platform automatically triggers an alarm mechanism, sending alert information to the operations and maintenance team via email, SMS, or a dedicated operations and maintenance management system.

[0006] Upon receiving an alert, operations and maintenance (O&M) personnel must respond quickly. First, they should access the server via remote login tools to review detailed anomaly logs and performance metrics to initially determine the nature and scope of the problem. Based on the assessment, O&M personnel may manually adjust server parameters, such as increasing memory allocation, adjusting thread pool size, or limiting resource consumption for specific services, to attempt to alleviate server pressure. If the problem stems from a software defect or code error, O&M personnel must also collaborate closely with the development team, reporting the issue to the programmers for code review and correction, ultimately resolving the root cause by deploying an update patch.

[0007] Although this operation and maintenance model based on server monitoring and manual intervention has been widely used and played an important role in the past, its inherent defects are becoming increasingly apparent:

[0008] Slow response time: From server monitoring to the identification of abnormal data, and then to the response and manual adjustment of parameters by maintenance personnel, there is a significant time delay in the entire process. This may result in the server suffering irreversible damage or even service interruption before the problem is effectively resolved.

[0009] Human error risk: When manually adjusting server parameters or handling code issues, maintenance personnel may introduce new errors due to fatigue, misjudgment, or improper operation. This not only fails to solve the problem but may also increase the server's load, leading to more serious consequences.

[0010] Low resource utilization efficiency: Manual monitoring and adjustment methods are difficult to achieve fine management and optimization of server resources, often resulting in uneven resource allocation. Some servers may waste resources due to over-configuration, while other servers may frequently alarm due to insufficient resources.

[0011] Lack of intelligent prediction and prevention: Traditional methods based on anomaly data monitoring can only passively deal with problems that have already occurred, and cannot proactively predict potential risks or take effective preventive measures, which limits the foresight and initiative of operation and maintenance work.

[0012] In conclusion, while the traditional operation and maintenance model based on server monitoring and manual intervention has its historical value, it is no longer able to meet the needs of efficient, intelligent, and automated operation and maintenance in the face of an increasingly complex and ever-changing Internet service environment.

[0013] Patent application CN115878316A discloses a method for calculating the load fusion of remote monitoring traffic. This method includes employing a load distribution algorithm in video surveillance scene information, initializing the hash ring in the algorithm, collecting configuration information of all servers in the distributed storage content of the video surveillance, grouping the servers, initializing the hash ring using a hash random method, allocating read and write requests to the server with the lightest load, calculating the server's load value, determining the load level based on a set threshold, determining the load level of all servers in the video surveillance scene information storage, performing corresponding operations on virtual nodes when the number of servers changes, and restoring lost data to a replica or adjusting the status value of the virtual node corresponding to the abnormal group when a server crashes. However, this patent cannot completely solve the existing technical problems and cannot meet the needs of this invention. Summary of the Invention

[0014] To address the shortcomings of existing technologies, the purpose of this invention is to provide a system and method for dynamically adjusting server load.

[0015] The server dynamic load adjustment system provided by the present invention includes:

[0016] The real-time monitoring module is used to continuously collect data on the server's frame drop rate, Lua memory usage, C++ memory usage, and network packet queue length.

[0017] The graded response module compares the data collected by the real-time monitoring module with preset thresholds to divide the throttling into four levels: limit, warning, load, and safety. It also uses a sliding window algorithm to smooth out instantaneous fluctuations to confirm level changes.

[0018] The adaptive throttling control module performs corresponding operations based on the throttling level, including at least one of the following: shutting down non-core services, token bucket rate limiting, automatic scaling down / scaling up, and forcibly removing inactive users;

[0019] The load prediction module uses historical data analysis, current active user count, and external event factors to predict future traffic peaks and trigger an early warning mechanism.

[0020] Preferably, the sliding window algorithm is implemented in the following ways:

[0021] Set the window length k, and calculate the moving average of the continuously acquired sample sequence using the following formula:

[0022]

[0023] Where yt is the smoothed output value at time t, and xi is the sampled value at time i in the original data sequence;

[0024] When three consecutive test results exceed the threshold of the corresponding throttling level, the level is confirmed to have changed.

[0025] Preferably, the specific operations of the adaptive throttling control module include: at the extreme level, shutting down the chat module and non-core functions, and implementing a token bucket rate limiting strategy; at the warning level, automatically scaling down to 80% of the current online users, and forcibly removing inactive users through client operations; at the security level, automatically expanding to 125% of the current online users, until the preset user limit is reached.

[0026] The prediction formula of the load prediction module is: Weekend peak = Weekday average × Historical weekend increment coefficient × External event factor.

[0027] Preferably, it further includes:

[0028] The cold start data application module is used to use the operational data of similar games as the initial prediction benchmark when there is a lack of its own historical data, and to dynamically revise the prediction model in combination with stress test results.

[0029] The stress testing module's execution process includes: simulating the configuration of the production environment, developing robot scripts to cover login, combat, and equipment operation scenarios; gradually increasing the number of robots and monitoring server performance until the preset thresholds for CPU and memory are reached or the business module experiences a failure rate; determining the maximum server capacity based on the test results, and calculating the holiday incremental coefficient.

[0030] Preferably, the early warning mechanism includes: calculating the estimated peak user volume based on the historical periodic incremental coefficient and the current number of active users; if the estimated value exceeds the server's capacity limit, notifying the operations and maintenance team in advance to expand resources or optimize the code;

[0031] The throttling operation of the system is implemented through an asynchronous detection thread with a detection cycle of 60 seconds, and the detection frequency can be dynamically adjusted to adapt to different load scenarios.

[0032] The server dynamic load adjustment method provided by the present invention includes:

[0033] Step 1: Continuously collect data on the server's frame drop rate, Lua memory usage, C++ memory usage, and network packet queue length;

[0034] Step 2: Compare the collected data with the preset threshold to divide the throttling into four levels: limit, warning, load, and safety. Then, use a sliding window algorithm to smooth out instantaneous fluctuations to confirm level changes.

[0035] Step 3: Perform the corresponding operation based on the throttling level, including at least one of the following: shutting down non-core services, token bucket rate limiting, automatic scaling down / scaling up, and forced removal of inactive users;

[0036] Step 4: Predict future traffic peaks and trigger early warning mechanisms by analyzing historical data, current active user counts, and external event factors.

[0037] Preferably, the sliding window algorithm is implemented in the following ways:

[0038] Set the window length k, and calculate the moving average of the continuously acquired sample sequence using the following formula:

[0039]

[0040] Where yt is the smoothed output value at time t, and xi is the sampled value at time i in the original data sequence;

[0041] When three consecutive test results exceed the threshold of the corresponding throttling level, the level is confirmed to have changed.

[0042] Preferably, step 3 includes: at the extreme level, shutting down the chat module and non-core functions, and implementing a token bucket rate limiting strategy; at the warning level, automatically scaling down to 80% of the current online users, and forcibly removing inactive users through client operations; at the security level, automatically expanding to 125% of the current online users, until the preset user limit is reached.

[0043] The formula for predicting future traffic peaks is: Weekend peak = Weekday average × Historical weekend increment coefficient × External event factor.

[0044] Preferably, it further includes:

[0045] The cold start data application steps are used to use the operational data of similar games as the initial prediction benchmark when there is a lack of its own historical data, and to dynamically revise the prediction model in combination with stress test results.

[0046] The stress test steps and execution process include: simulating the configuration of the production environment, developing robot scripts to cover login, combat, and equipment operation scenarios; gradually increasing the number of robots and monitoring server performance until the preset thresholds for CPU and memory are reached or the business module experiences a failure rate; determining the maximum capacity of the server based on the test results, and calculating the holiday incremental coefficient.

[0047] Preferably, the early warning mechanism includes: calculating the estimated peak user volume based on the historical periodic incremental coefficient and the current number of active users; if the estimated value exceeds the server's capacity limit, notifying the operations and maintenance team in advance to expand resources or optimize the code;

[0048] Throttling is implemented through an asynchronous detection thread with a detection cycle of 60 seconds, and the detection frequency can be dynamically adjusted to adapt to different load scenarios.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] (1) By utilizing advanced real-time monitoring and data analysis technology, it is possible to capture subtle changes in server performance indicators in real time and automatically trigger early warning and adjustment mechanisms before or in the early stages of anomalies, thereby greatly shortening the time for problem response and resolution and effectively avoiding service interruption and data loss caused by server overload for a long time.

[0051] (2) By using automated and intelligent parameter adjustment strategies, the reliance on manual intervention is reduced, the risk of human error is lowered, and the system can automatically adjust the server's resource configuration, user session management and algorithm execution mode according to the real-time load and preset algorithm logic, ensuring efficient use of resources and stable operation of services, while reducing the workload of operation and maintenance personnel and improving the accuracy and efficiency of operation and maintenance work.

[0052] (3) By analyzing the patterns of historical data, the system can predict future traffic trends and server load, and adjust resource configuration and strategies in advance to cope with possible traffic peaks and abnormal events, thus realizing the foresight and initiative of operation and maintenance work. Attached Figure Description

[0053] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0054] Figure 1 A schematic diagram of a strategy for dynamic server load design. Detailed Implementation

[0055] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0056] Example 1

[0057] Server load is rarely stable; it can change abruptly due to various factors (such as a sudden influx of players at server launch or the unexpected deployment of defective code). This can cause a rapid increase in load, leading to a surge in server memory and CPU usage. This can result in lag and, more importantly, a sharp decline in server performance, potentially causing a cascading failure or even a crash.

[0058] Therefore, we need to dynamically balance the server's load capacity by monitoring processes' memory, network packets, and other parameters. See details... Figure 1 .

[0059] I. Dynamic Monitoring and Tiered Response Mechanism

[0060] This invention designs a monitoring system that, deployed via Lua scripts, can monitor multiple key parameters of a server in real time. When any of these parameters exceeds a preset threshold, the system will automatically activate a throttling mode and set different throttling levels according to specific circumstances. The core monitoring parameters include:

[0061] 1. Frame drop rate: The number of incomplete logical frames per second is counted by the rendering module.

[0062] 2. Memory Usage: Separately calculate Lua memory usage and C++ memory usage.

[0063] 3. Network load: Monitor the length of the pending network packet queue.

[0064] Based on the degree to which the threshold is exceeded and the different combinations of parameters, different throttling levels are defined, as shown in the table below:

[0065] grade Frame drop rate Lua memory C++ memory Network queue limit ＝100％ ≥6GB ≥6GB ≥500k warn ≥80％ ≥4GB ≥4GB ≥200k load ≥50％ ≥2GB ≥2GB ≥30k Safety <50％ <2GB <2GB <30k

[0066] The throttling level is determined by an asynchronous detection thread triggered by a timer, which performs a detection every 60 seconds and uses a sliding window algorithm to smooth out instantaneous fluctuations.

[0067] The core idea of ​​the sliding window algorithm for smoothing instantaneous fluctuations is to use the statistical characteristics of local data to replace individual data points, suppress short-term abnormal fluctuations, and preserve the overall trend of the data.

[0068] Assuming a continuously collected sample sequence: x1, x2, ..., xn, and a sliding window of length k, the smoothed output value yt at time t is:

[0069]

[0070] Where xi is the sampled value at time i in the original data sequence;

[0071] Each time yt is calculated, the window covers the latest k data points, that is, from t-k+1 to t.

[0072] Example: If k=5, then the window at time t=8 contains x4, x5, x6, x7, x8;

[0073] Effect: Random noise within the window is "diluted" by other data points, significantly reducing the fluctuation of the output yt and ensuring detection accuracy. When three consecutive detections exceed the threshold of the corresponding level, the system will confirm the change in throttling level and implement corresponding throttling measures.

[0074] II. Adaptive Throttling Control Method

[0075] The core objective of throttling mode is to limit the number of users the server can currently support, stabilize server performance, and minimize the impact on the gaming experience for online players. The corresponding behaviors for different throttling levels are shown in the table below:

[0076]

[0077] Load forecasting model

[0078] Core idea: To infer weekend traffic peaks by analyzing weekday user behavior patterns, it's necessary to map the traffic conversion relationship from weekdays to weekends and incorporate the influence of external event factors (such as promotional activities). The key steps and expressions are as follows:

[0079] Weekend peak = α (average weekday value) · β (historical weekend increment coefficient) · γ (external event factor)

[0080] Input variable description:

[0081] α-Workday Average: The average maximum number of online users over the most recent N workdays (e.g., 5 days) is taken as the baseline;

[0082] β Historical Weekend Increment Coefficient: The percentage increase in historical weekend traffic relative to weekday traffic (e.g., β = 1.5 means that weekend traffic is 50% higher than weekday traffic). The increment coefficient is calculated from previous data.

[0083] γ External event factor: The additional traffic boosting factor brought by external events (such as operational activities and competitions) (γ = 1 when there are no events);

[0084] Output: Predicted peak number of online users over the weekend;

[0085] Prediction example:

[0086] Weekday data: Peak online users: 5,000 on weekday evenings;

[0087] Historical patterns: Saturday's peak is usually 1.3 times that of Friday night, and an additional 30% if there are promotional activities.

[0088] Predicted peak this Saturday = 5000 × 1.3 × 1.3 = 8450 (assuming there are operational activities this week);

[0089] Weekends and holidays are typically peak periods for game user activity. By analyzing historical operational data and combining it with current active user numbers, it's possible to predict in advance whether the server will experience excessive load during the next peak period.

[0090] Stress testing and incremental coefficient calculation: First, according to the standard stress testing procedure, including:

[0091] (1) Preparation for the testing phase

[0092] 1. Determine the server's capacity limits, such as CPU and memory thresholds;

[0093] 2. Comprehensive scenario testing, including key test scenarios (login / logout, combat, equipment wearing and enhancement, etc.);

[0094] 3. Server configuration: Simulates the production environment, including parameters such as CPU, memory, disk space, and bandwidth;

[0095] 4. Robot script framework development;

[0096] (2) Test Robot Development

[0097] 1. Write bot scripts to simulate normal player operations (login / logout, combat, equipment wearing and enhancement, etc.);

[0098] 2. Increase test coverage scenarios by using parameterized inputs for different professions, etc.

[0099] (3) Perform stress test

[0100] 1. Gradually increase the number of robots and observe the server response;

[0101] 2. When the target stress value is reached, run continuously for 7x24 hours to test the stability of the server under long-term high load;

[0102] (4) Server performance monitoring

[0103] The following indicates that the server has reached its critical stress level:

[0104] 1. Core metrics such as CPU and memory reach the threshold;

[0105] 2. Business modules have started to experience failure rates (such as login failures and equipment donning timeouts);

[0106] Determine the maximum number of players the server can handle under normal operating conditions. Then, based on historical data, calculate the player increase coefficients for weekends and holidays compared to weekdays. The calculation formula is as follows:

[0107]

[0108] Daily maximum online user count recording and storage: The server resets the value of 'a' to 0 at 00:00 every day. Every five minutes, the current number of online users 'b' is obtained, and 'a = max(a, b)' is calculated. Then, at 23:59 on the same day, the value of 'a' is stored in the database. The next day, the value of 'a' is reset to 0, and the comparison between 'a' and 'b' continues, recording the value of 'a' and storing it in the database for the following day.

[0109] For example, from Monday to Friday, March 3rd to 7th, the values ​​of 'a' are 1800, 1900, 2000, 1900, and 1500 respectively. At 0:00 on Saturday, March 8th, the value of 'a' is reset to 0. Then, at 23:59 on March 8th, the final calculated value of 'a' (e.g., 2300) and the Saturday increment coefficient 'p' are stored in the database.

[0110] The formula for calculating the weekend increment factor p is:

[0111]

[0112] The incremental coefficient algorithm for holidays is consistent with that for weekends.

[0113] For example, the increment coefficient for weekends is 1.5, and the increment coefficient for a certain holiday is 2.

[0114] Exceeding limits and issuing warnings: Based on the current number of active users and the incremental coefficient corresponding to the next peak, calculate the estimated number of users during the peak period; retrieve the periodic incremental coefficients for the current month and week of the previous year from the database; then:

[0115] Estimated value = Number of active users · Corresponding cyclical incremental system of the previous year · External traffic coefficient;

[0116] If the incremental data stored on the second Sunday of February 2024 is 1.23, and the number of active users on all weekdays of the second week of February 2025 is 1600, then without additional traffic boosting factors from extra events (such as operational activities or competitions), the estimated number of users on Sundays in February 2025 can be 1968 = 1600 × 1.23 × 1. If the estimated number exceeds the server's capacity limit, an early warning mechanism will be triggered to notify the operations and maintenance team to take countermeasures in advance, such as increasing server resources and optimizing code.

[0117] Cold start data application: Before a game is officially launched and operated, due to the lack of its own historical data, data from other similar recently operated online games can be used as cold start data. Based on this, preliminary prediction and prevention strategies can be formulated.

[0118] Key points and protection points of this invention

[0119] Monitoring metrics: The key parameters selected in this invention, such as frame loss value, Lua memory, C++ memory, and network packet queue, can comprehensively and accurately reflect the current load status of the server. The combination of these metrics, threshold settings, and the application of the sliding window algorithm are the core of achieving effective monitoring and adjustment.

[0120] Throttling operations: The specific operations corresponding to different throttling levels, such as shutting down non-core service modules and applying the token bucket rate limiting algorithm under the extreme throttling level, and automatic scaling down and kicking out inactive users under the warning throttling level, are key measures to ensure the stable operation of the server under different load conditions.

[0121] Prediction Algorithm: Based on historical data, current active user count, and stress test results, the prediction algorithm calculates incremental coefficients and makes over-limit judgments. It can detect potential risks in advance, provide a basis for server resource allocation and optimization, and is an important technical point for realizing the prevention function.

[0122] Compared to traditional manual intervention in operation and maintenance, the dynamic adjustment mechanism for server parameters proposed in this invention demonstrates significant advantages, mainly in the following aspects:

[0123] Significantly improved response speed: In traditional operation and maintenance models, there is often a long time delay from anomaly detection to manual response and problem resolution. However, this invention, through a real-time monitoring and intelligent early warning system, can automatically trigger adjustment mechanisms in the early stages of anomalies or even in the stage of potential risks, significantly shortening the problem response time and effectively avoiding service interruptions and data loss caused by delayed processing.

[0124] Reducing human error and intervention: During manual operation and maintenance (O&M) processes, factors such as the judgment, operational experience, and fatigue level of O&M personnel can all affect the O&M results and even introduce new errors. This invention, through intelligent parameter adjustment algorithms and predictive models, automates and intelligentizes O&M work, reducing human intervention, lowering the risk of errors, and improving the accuracy and reliability of O&M operations.

[0125] Resource utilization efficiency optimization: Traditional operation and maintenance models often struggle to achieve fine-grained management and optimization of server resources, leading to uneven resource allocation and waste. This invention, however, utilizes a dynamic parameter adjustment algorithm to intelligently adjust resource configuration based on real-time load conditions, ensuring efficient resource utilization, reducing operating costs, and improving overall service performance.

[0126] Intelligent prediction and prevention capabilities: Traditional operation and maintenance models typically only respond passively to problems that have already occurred, lacking foresight and initiative. This invention, however, utilizes an intelligent prediction and prevention mechanism to anticipate future server load conditions and adjust resource configurations and strategies accordingly. This effectively prevents potential service interruptions and performance bottlenecks, enhancing the foresight and initiative of operation and maintenance work.

[0127] In summary, by introducing innovative technologies such as real-time monitoring, intelligent analysis, and automated adjustment, this invention significantly improves the intelligence level of server management, reduces operation and maintenance costs, and enhances service stability and user experience. Compared with the traditional manual intervention operation and maintenance mode, it demonstrates unparalleled advantages and broad application prospects.

[0128] Example 2

[0129] This invention also provides a method for dynamically adjusting server load, comprising: Step 1: continuously collecting data on server frame drop rate, Lua memory usage, C++ memory usage, and network packet queue length; Step 2: comparing the collected data with preset thresholds to classify four throttling levels: limit, warning, load, and security, and smoothing instantaneous fluctuations using a sliding window algorithm to confirm level changes; Step 3: performing corresponding operations based on the throttling levels, including at least one of shutting down non-core services, token bucket rate limiting, automatic scaling down / scaling up, and forcibly removing inactive users; Step 4: predicting future traffic peaks and triggering an early warning mechanism through historical data analysis, current active user count, and external event factors.

[0130] The sliding window algorithm is implemented by: setting a window length k, and performing a moving average calculation on the continuously collected sample sequence, using the following formula: Where yt is the smoothed output value at time t, and xi is the sampled value at time i in the original data sequence; when three consecutive detection results exceed the threshold of the corresponding throttling level, the level change is confirmed.

[0131] Step 3 includes: at the extreme level, shutting down the chat module and non-core functions, and implementing a token bucket rate limiting strategy; at the warning level, automatically scaling down to 80% of the current online users, and forcibly removing inactive users through client operations; at the security level, automatically scaling up to 125% of the current online users, until the preset user limit is reached; the formula for predicting future traffic peaks is: weekend peak = weekday average × historical weekend increment coefficient × external event factor.

[0132] It also includes: a cold start data application step, which uses the operational data of similar games as an initial prediction benchmark when there is a lack of its own historical data, and dynamically corrects the prediction model in combination with stress test results; a stress test step, the execution process of which includes: simulating the configuration of the formal environment, developing robot scripts to cover login, combat, and equipment operation scenarios; gradually increasing the number of robots and monitoring server performance until the preset thresholds of CPU and memory are reached or the business module experiences a failure rate; determining the maximum capacity of the server based on the test results, and calculating the holiday incremental coefficient.

[0133] The early warning mechanism includes: calculating the estimated peak user volume based on the historical periodic incremental coefficient and the current number of active users; if the estimated value exceeds the server's capacity limit, notifying the operations and maintenance team in advance to expand resources or optimize the code; the throttling operation is implemented through an asynchronous detection thread with a detection cycle of 60 seconds, and supports dynamic adjustment of the detection frequency to adapt to different load scenarios.

[0134] Those skilled in the art will understand that, in addition to implementing the system, apparatus, and their modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and their modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

[0135] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A server dynamic load adjustment system, characterized in that, include: The real-time monitoring module is used to continuously collect data on the server's frame drop rate, Lua memory usage, C++ memory usage, and network packet queue length. The graded response module compares the data collected by the real-time monitoring module with preset thresholds to divide the throttling into four levels: limit, warning, load, and safety. It also uses a sliding window algorithm to smooth out instantaneous fluctuations to confirm level changes. The adaptive throttling control module performs corresponding operations based on the throttling level, including at least one of the following: shutting down non-core services, token bucket rate limiting, automatic scaling down / scaling up, and forcibly removing inactive users; The load prediction module uses historical data analysis, current active user count, and external event factors to predict future traffic peaks and trigger an early warning mechanism.

2. The server dynamic load adjustment system according to claim 1, characterized in that, The sliding window algorithm is implemented in the following ways: Set the window length k, and calculate the moving average of the continuously acquired sample sequence using the following formula: Where yt is the smoothed output value at time t, and xi is the sampled value at time i in the original data sequence; When three consecutive test results exceed the threshold of the corresponding throttling level, the level is confirmed to have changed.

3. The server dynamic load adjustment system according to claim 1, characterized in that, The specific operations of the adaptive throttling control module include: at the extreme level, shutting down the chat module and non-core functions, and implementing a token bucket rate limiting strategy; at the warning level, automatically scaling down to 80% of the current online users, and forcibly removing inactive users through client operations; at the security level, automatically expanding to 125% of the current online users, until the preset user limit is reached. The prediction formula of the load prediction module is: Weekend peak = Weekday average × Historical weekend increment coefficient × External event factor.

4. The server dynamic load adjustment system according to claim 1, characterized in that, Also includes: The cold start data application module is used to use the operational data of similar games as the initial prediction benchmark when there is a lack of its own historical data, and to dynamically revise the prediction model in combination with stress test results. The stress testing module's execution process includes: simulating the configuration of the production environment, developing robot scripts to cover login, combat, and equipment operation scenarios; gradually increasing the number of robots and monitoring server performance until the preset thresholds for CPU and memory are reached or the business module experiences a failure rate; determining the maximum server capacity based on the test results, and calculating the holiday incremental coefficient.

5. The server dynamic load adjustment system according to claim 1, characterized in that, The early warning mechanism includes: calculating the estimated peak user volume based on the historical periodic incremental coefficient and the current number of active users; if the estimated value exceeds the server's capacity limit, notifying the operations and maintenance team in advance to expand resources or optimize the code; The throttling operation of the system is implemented through an asynchronous detection thread with a detection cycle of 60 seconds, and the detection frequency can be dynamically adjusted to adapt to different load scenarios.

6. A method for dynamically adjusting server load, characterized in that, include: Step 1: Continuously collect data on the server's frame drop rate, Lua memory usage, C++ memory usage, and network packet queue length; Step 2: Compare the collected data with the preset threshold to divide the throttling into four levels: limit, warning, load, and safety. Then, use a sliding window algorithm to smooth out instantaneous fluctuations to confirm level changes. Step 3: Perform the corresponding operation based on the throttling level, including at least one of the following: shutting down non-core services, token bucket rate limiting, automatic scaling down / scaling up, and forced removal of inactive users; Step 4: Predict future traffic peaks and trigger early warning mechanisms by analyzing historical data, current active user counts, and external event factors.

7. The server dynamic load dynamic adjustment method according to claim 6, characterized in that, The sliding window algorithm is implemented in the following ways: Set the window length k, and calculate the moving average of the continuously acquired sample sequence using the following formula: Where yt is the smoothed output value at time t, and xi is the sampled value at time i in the original data sequence; When three consecutive test results exceed the threshold of the corresponding throttling level, the level is confirmed to have changed.

8. The server dynamic load dynamic adjustment method according to claim 6, characterized in that, Step 3 includes: at the extreme level, shutting down the chat module and non-core functions, and implementing a token bucket rate limiting strategy; at the warning level, automatically scaling down to 80% of the current online users, and forcibly removing inactive users through client operations; at the security level, automatically expanding to 125% of the current online users, until the preset user limit is reached. The formula for predicting future traffic peaks is: Weekend peak = Weekday average × Historical weekend increment coefficient × External event factor.

9. The server dynamic load dynamic adjustment method according to claim 6, characterized in that, Also includes: The cold start data application steps are used to use the operational data of similar games as the initial prediction benchmark when there is a lack of its own historical data, and to dynamically revise the prediction model in combination with stress test results. The stress test steps and execution process include: simulating the configuration of the production environment, developing robot scripts to cover login, combat, and equipment operation scenarios; gradually increasing the number of robots and monitoring server performance until the preset thresholds for CPU and memory are reached or the business module experiences a failure rate; determining the maximum capacity of the server based on the test results, and calculating the holiday incremental coefficient.

10. The server dynamic load dynamic adjustment method according to claim 6, characterized in that, The early warning mechanism includes: calculating the estimated peak user volume based on the historical periodic incremental coefficient and the current number of active users; if the estimated value exceeds the server's capacity limit, notifying the operations and maintenance team in advance to expand resources or optimize the code; Throttling is implemented through an asynchronous detection thread with a detection cycle of 60 seconds, and the detection frequency can be dynamically adjusted to adapt to different load scenarios.

Images