Method for slowly starting system service

Abstract

The invention provides a method for slowly starting a system service, which comprises the following steps of: in response to system starting, initializing a control parameter; the control parameter at least comprises an allowable request parameter value; the allowed request parameter value is used for controlling the number of registration requests allowed to be accepted by the system; judging whether the system state is busy; if yes, the step of judging whether the system state is busy or not is executed again after preset operation time; if not, updating the control parameters by using the historical data; configuring a system according to the control parameters; judging whether a registration request exists currently or not; if yes, re-executing the step of judging whether the system state is busy; and if not, the limitation on the registration request is ended, and the system startup is completed. According to the invention, the control parameters are updated by using the historical data according to the actual parameters to realize full utilization of the system service performance; the number of registration requests accepted by the system at a time is limited by using the control parameters, so that the system is started slowly.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and more particularly to a method for slowly starting a system service. Background Art

[0002] With the continuous development of computer technology, system services play a vital role. They provide various supports and functions for applications. The performance optimization of system services has become one of the key issues. However, in some cases, fast startup of system services may not be the best choice. For example, for the video surveillance system platform using the national standard GB28181 protocol in the security field, according to the protocol, all front-end points need to register with the platform CMS module from time to time. If the CMS module is generally started in a common way, when a large number of front-ends register at the same time, it will cause service request congestion and cause the CMS module to stop serving. Therefore, in some specific scenarios, it is necessary to use a slow startup method for system services to meet specific needs. Slow startup can better ensure the stability of the system and the smooth utilization of resources. Summary of the invention

[0003] In view of the above problems, the present disclosure provides a method for slowly starting system services to achieve smooth system startup.

[0004] The present disclosure provides a method for slowly starting a system service, comprising: in response to system startup, initializing control parameters; the control parameters at least include an allowed request parameter value; the allowed request parameter value is used to control the number of registration requests that the system allows to accept; judging whether the system status is busy; if so, re-executing the step of judging whether the system status is busy after a preset time; if not, updating the control parameters using historical data; configuring the system according to the control parameters; judging whether there is a registration request currently; if so, re-executing the step of judging whether the system status is busy; if not, ending the restriction on registration requests and completing system startup.

[0005] According to an embodiment of the present disclosure, updating the control parameter using historical data includes: updating the allowed request parameter value according to the allowed request parameter value at the last moment, the actually completed request parameter value at the last moment, and the weighting coefficient; wherein the formula for updating the allowed request parameter value is as follows:

[0006] V q =V q-1 ×W+(1-W)×Vr q-1

[0007] Where V q Indicates that the parameter value is allowed to be requested at time q; V q-1 Indicates that the parameter value is allowed to be requested at time q; Vr q-1represents the actual completed request parameter value from time q-1 to time q; W represents the preset weighting coefficient, which is used to characterize the influence ratio of the historical allowed request parameter value and the actual completed request parameter value.

[0008] According to an embodiment of the present disclosure, the allowed request parameter value is updated according to the allowed request parameter value at the previous moment, the actually completed request parameter value at the previous moment and the weighting coefficient, and the method also includes: setting the weighting coefficient according to the actually completed request parameter value at the previous moment, including: determining whether the actually completed request parameter value is greater than a preset threshold; if so, setting it to a first weighting coefficient greater than 0.5; if not, setting it to a second weighting coefficient less than 0.5; the weighting coefficient ranges from 0 to 1.

[0009] According to an embodiment of the present disclosure, configuring a system according to control parameters includes: using a firewall tool to add newly allowed registration requests to a permission list of an input chain according to a request parameter value allowed; the input chain is used to process data packets entering the system.

[0010] According to an embodiment of the present disclosure, the control parameters are initialized, including: according to a preset step coefficient and the total number of registration requests, an average expected number of distributed requests is calculated as the allowed request parameter value for initialization; the step coefficient represents the number of times the system adjusts the control parameters; the total number of registration requests includes the number of front-end device registrations and the number of back-end module registrations that the system needs to process at startup; according to the average expected number of distributed requests and the average request service time, an average update time of the control parameters is obtained; the average request service time is the number of registration requests processed per unit time; and according to the average update time of the control parameters, a preset running time is set.

[0011] According to an embodiment of the present disclosure, the average update time of the control parameters is obtained according to the average expected number of distributed requests and the average request service time, which also includes: determining the average request service time according to the hardware configuration.

[0012] According to an embodiment of the present disclosure, according to the preset step coefficient and the total number of registration requests, the average expected distribution request number is calculated to be used as the initialization allowed request parameter value, and the method also includes: calculating the total number of registration requests, including: counting the number of front-end devices and back-end modules, and calculating the total number of registration requests; wherein the calculation formula of the total number of registration requests is as follows:

[0013] R=F×N1+B×N2

[0014] In the formula, R represents the total number of registration requests; F represents the number of front-end devices; B represents the number of back-end modules; N1 and N2 represent the processing time coefficients of the front-end devices and back-end devices, respectively.

[0015] A second aspect of the present disclosure provides a device for slowly starting a system service, which can be used to implement the above method. The device for starting a system service includes: an initialization module, which is used to initialize control parameters in response to system startup; the control parameters at least include an allowed request parameter value; the allowed request parameter value is used to control the number of registration requests allowed by the system; a control module, which is used to determine whether the system status is busy; if so, re-execute the step of determining whether the system status is busy after a preset time; if not, update the control parameters using historical data; configure the system according to the control parameters; a loop module, which is used to determine whether there is a registration request currently; if so, re-execute the step of determining whether the system status is busy; if not, end the restriction on registration requests and complete system startup.

[0016] A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the above-mentioned method of slowly starting system services.

[0017] A fourth aspect of the present disclosure further provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to execute the above-mentioned method of slowly starting the system service.

[0018] According to the method for slowly starting system services provided by the present disclosure, the availability of service resources is gradually adjusted by controlling the scope of network application of the resources where the service is located. Since the control parameters are updated by using the historical data of the previous moment to calculate the current appropriate resource increase range in each stage, the technical problem of system congestion caused by a large number of requests in the startup is at least partially solved, and the technical effect of avoiding excessive system load at the startup moment is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 A flowchart of a method for slowly starting a system service according to an embodiment of the present disclosure is schematically shown;

[0020] Figure 2 A flowchart schematically shows a system startup according to an embodiment of the present disclosure;

[0021] Figure 3 Schematically shows a parameter variation curve with a weighting coefficient of 0.1 according to an embodiment of the present disclosure;

[0022] Figure 4 Schematically shows a parameter variation curve with a weighting coefficient of 0.3 according to an embodiment of the present disclosure;

[0023] Figure 5 Schematically shows a parameter variation curve with a weighting coefficient of 0.6 according to an embodiment of the present disclosure;

[0024] Figure 6 Schematically shows a parameter variation curve with a weighting coefficient of 0.9 according to an embodiment of the present disclosure;

[0025] Figure 7 A structural block diagram of a device for slowly starting system services according to an embodiment of the present disclosure is schematically shown;

[0026] Figure 8 A block diagram of an electronic device suitable for implementing a method for slowly starting system services according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0027] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0028] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0029] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.

[0030] When using expressions such as "at least one of A, B, and C, etc.", they should generally be interpreted according to the meaning of the expression commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0031] First, the technical terms involved in this disclosure are explained as follows:

[0032] Slow startup system services: The core principle of slow startup system services is to control the scope of network application of service resources and use appropriate algorithms to gradually adjust the availability of service resources to avoid excessive system load at the moment of startup. Among the commonly used algorithms, the following algorithms can be used to achieve slow startup:

[0033] (1) Exponentially Weighted Moving Average (EWMA): This algorithm assigns a weight to each data point, with the more recent data having a larger weight. In a slow system startup, EWMA can be used to smoothly increase resource allocation or service processing capacity. For example, based on historical performance data, EWMA can be used to calculate the appropriate amount of resource increase at the moment.

[0034] (2) Leaky Bucket Algorithm: It can be used to control the rate at which data is injected into the system. It is like a bucket with a fixed water leakage rate. No matter how much water flows in (data arrives), the outflow rate is constant. During the slow start of the system, the outflow rate of the leaky bucket can be adjusted to achieve a smooth growth of data processing or resource allocation, avoiding sudden large amounts of data or requests that may cause the system to crash.

[0035] (3) Token Bucket Algorithm: The system will put tokens into the bucket at a certain rate. When there is data to be processed, tokens must be obtained from the bucket. If there are not enough tokens in the bucket, the data needs to wait or be discarded. In the slow start phase, the rate of token generation can be gradually increased, thereby gradually improving the system's ability to process data.

[0036] (4) Adaptive algorithms: These algorithms can dynamically adjust startup parameters based on the system's real-time performance indicators (such as response time, throughput, resource utilization, etc.). For example, if the system load is detected to be too high or performance is degraded, the algorithm will automatically reduce the growth rate; when the system is running well, the growth rate will be appropriately accelerated. Common adaptive algorithms include fuzzy logic algorithms, neural network algorithms, etc.

[0037] (5) Step-by-step increase algorithm: Set a series of fixed growth steps. In each step, increase a certain amount of resources or processing power. After each step, pause for a period of time to observe the stability and performance of the system before deciding whether to enter the next growth step. This method is relatively simple and direct and can avoid excessively rapid growth.

[0038] (6) Rule-based algorithms: The startup behavior of the system is determined according to pre-defined rules. For example, different growth strategies are triggered based on time, system status, or other conditions. Rules can be formulated based on expert experience or analysis of system performance.

[0039] Preferably, the method is used in the national standard GB28181 platform. According to the national standard protocol, the communication with the core CMS module is the front-end camera point, and the back-end storage, alarm, database and other fixed service modules. The overall application service request is a fixed value, and the resources required by the back-end service module and the front-end point registration request service are different, so a single algorithm cannot be used for calculation.

[0040] In actual engineering environments, large-scale national standard platforms will form multiple domains to manage front-end and back-end devices. Each domain corresponds to a central communication module CMS. Each CMS corresponds to an ALS alarm module, an NRM video management module, and a large number of NRU video storage modules. At the same time, each CMS module needs to manage all registration and communication messages of a large number of front-end devices.

[0041] According to the national standard GB28181 protocol, the front-end device will randomly send registration messages to the CMS module within a time range (for example, 120 seconds). After receiving the CMS confirmation message, the front-end point will stop sending messages until the next cycle arrives. However, if the CMS module fails to reply to the registration message of the front-end device due to unknown reasons, the front-end device will continue to send registration messages until it receives the confirmation message from the CMS module.

[0042] Therefore, when the CMS module restarts due to abnormal reasons, the system will receive a large number of device registration messages and cause request congestion. It is necessary to adopt a more effective application request method to enable the system to smoothly enter the normal working mode. The method of controlling all front-end devices in the domain to suspend sending registration messages until the system returns to normal, although logically feasible, requires a huge workload and usually takes no less than 8 hours to configure. This is obviously not advisable in actual engineering applications. In view of this situation, this scheme will provide a solution, that is, the system service module end controls the number of received applications according to the algorithm during the startup phase, gradually opens application requests, and smoothly transitions to the normal working environment. According to the actual situation, this method uses a combination of exponentially weighted moving algorithm and step-by-step increase algorithm to coordinate work.

[0043] Figure 1 The flowchart of the method for slowly starting system services according to an embodiment of the present disclosure is schematically shown. Figure 1As shown, an embodiment of the present disclosure provides a method for slowly starting system services, including: in response to system startup, initializing control parameters; the control parameters at least include an allowed request parameter value; the allowed request parameter value is used to control the number of registration requests that the system allows to accept; judging whether the system status is busy; if so, re-executing the step of judging whether the system status is busy after a preset time; if not, updating the control parameters using historical data; configuring the system according to the control parameters; judging whether there is a registration request currently; if so, re-executing the step of judging whether the system status is busy; if not, ending the restriction on registration requests and completing system startup.

[0044] In this embodiment, according to the result of demand analysis, a specific slow start process is designed as follows: Figure 2 As shown in the figure, in the system initialization phase, the initial parameters of the smoothing control algorithm are set; in the phase of obtaining system status parameters, the current system status value is obtained through system commands or process return values; in the system status judgment phase, the current system status value is judged. If the system status value is true (the system is in a state where requests can be accepted), the system is set up. If the system status value is false (the system is busy), a fixed time (such as 10s, which is less than the average update time) is waited for, and the system status parameter acquisition phase is entered again; in the system setting phase, the parameter values ​​to be configured are dynamically calculated through the algorithm, and the system request strategy is configured; in the loop phase, it is determined whether the system has any unprocessed requests. If there are still requests, jump to the phase of obtaining system status parameters. If there are no unprocessed requests, the control termination phase is directly entered; in the control termination phase, all control request strategies of the system are released, so that the system enters a normal state.

[0045] Through the embodiments of the present disclosure, a slow startup method suitable for the national standard system service module is provided to deal with the problem of system congestion caused by the need to process massive data requests in the early stage of system startup. Specifically, by updating the control parameters according to historical data, it is ensured that the system performance is not wasted and the processing efficiency is improved; by adjusting the control parameters, the number of registration requests allowed to be accepted by the system is adjusted.

[0046] Based on the above embodiment, the control parameter is updated by using historical data, including: updating the allowed request parameter value according to the allowed request parameter value at the last moment, the actually completed request parameter value at the last moment and the weighting coefficient; wherein the formula for updating the allowed request parameter value is as follows:

[0047] V q =V q-1 ×W+(1-W)×Vr q-1

[0048] Where V q Indicates that the parameter value is allowed to be requested at time q; Vq-1 Indicates that the parameter value is allowed to be requested at time q; Vr q-1 represents the actual completed request parameter value from time q-1 to time q; W represents the preset weighting coefficient, which is used to characterize the influence ratio of the historical allowed request parameter value and the actual completed request parameter value.

[0049] In this embodiment, the control parameter V is adjusted for the first time. q-1 Obtained when initializing control parameters.

[0050] In this embodiment, the following table records the process of iteratively calculating the allowed request parameter values ​​when requesting parameter settings once.

[0051] W <![CDATA[V q ]]> <![CDATA[Vr q+1 ]]> <![CDATA[V q+1 ]]> 1 0.3 160 91 111.7 2 0.3 111 127 122.2 3 0.3 122 175 159.1 4 0.3 159 157 157.6 5 0.3 157 153 154.2 6 0.3 154 175 168.7 7 0.3 168 157 160.3 8 0.3 160 127 136.9 9 0.3 136 175 163.3 10 0.3 163 89 111.2 11 0.3 112 120 117.3 12 0.3 117 180 161.1

[0052] In this embodiment, for example, assuming that the total number of original requests is 1600, that is, each domain receives a total of 1600 requests from the front-end device and the back-end in each block, and the step coefficient in the step-by-step increase algorithm is specified as 10 times, that is, all requests are processed in 10 steps, and the total number of registered requests / step coefficient is used to calculate the average expected number of step requests Vr q-1 The initial value is 1600 / 10 = 160. Taking the server configuration 8C-16G / 1000M environment as an example, by looking up the table, it is found that the time to completely process these requests under the current configuration is 1600 / 8 = 200 seconds. It is planned to complete the above request processing in 10 steps, that is, it is planned to modify the allowed request parameters every 20 seconds, and the average update time is 20 seconds.

[0053] Set the preset running time to 10 seconds. After the system runs for 10 seconds, it determines whether the system has reached the state of obtaining new requests through system commands or process return values. If the system is busy, it continues to wait for 10 seconds and repeats the execution to determine whether the system has reached the state of obtaining new requests. When the system reaches the state of obtaining new requests, it reaches time V1, and obtains time V0 to V1. The system actually completes 91 request processing, calculated by the formula: V1 = V0 × W + (1-W) × Vr0 = 160 × 0.3 + 91 × (1-0.3) = 111.7, and the result is rounded down to 111. That is, at time V1, the algorithm determines that the system setting allows request parameters to be 111 times at this moment.

[0054] By calling the iptables tool, the newly added request range is added to the permission list of the INPUT chain to achieve the purpose of setting the allowed parameters. At V1, the allowed request parameter value is set to 111.

[0055] Determine whether there are any unprocessed requests. Since only 111 requests have been processed at this stage, which is less than the total number of requests of 1,600, the system will jump to determine whether the system has reached the state of obtaining new requests and continue to process requests.

[0056] Repeat the above state cycle 11 times, and set the system's request value at each request time in turn, until the 12th cycle, when it is determined that the system has actually completed 1726 requests, which is greater than the original request 1600 times, the system determines that the above smooth startup process is complete. The system enters the end control stage, and the system calls the iptables tool to open the address range of all requests, ends the restriction on system requests, and completes the entire smooth startup process.

[0057] Through the embodiments of the present invention, a new algorithm model suitable for slow startup is introduced. Based on the historical actual completion request parameter values ​​and the historical allowed request parameter values, the allowed request parameter values ​​at the current moment are iteratively updated, so that congestion will not be caused by registration requests accepted at the same time, and dynamic adjustments can be made according to the instantaneous processing speed and the average processing speed, thereby making full use of system performance and reducing the time for smooth startup.

[0058] On the basis of the above embodiment, the allowed request parameter value is updated according to the allowed request parameter value at the previous moment, the actually completed request parameter value at the previous moment and the weighting coefficient, and the above also includes: setting the weighting coefficient according to the actually completed request parameter value at the previous moment, including: judging whether the actually completed request parameter value is greater than a preset threshold; if so, setting it to a first weighting coefficient greater than 0.5; if not, setting it to a second weighting coefficient less than 0.5; the value range of the weighting coefficient is 0 to 1.

[0059] In this embodiment, W is a weighted coefficient, which represents the correlation coefficient between the expected permission request parameter and the actual completion request parameter. The value of W ranges from 0 to 1. When W tends to 0, V q With the historical allowed request value V q-1 It has nothing to do with it. It depends entirely on the number of requests actually completed, Vr. q-1 When B approaches 1, V q Request value and actual completed quantity Vr q-1 It has nothing to do with it. It depends entirely on the historical request parameter V. q-1 Preferably, the W value is set to 0.3, that is, the request parameters allowed each time are strongly related to the number of requests actually completed last time, while taking into account the number of request parameters allowed in history.

[0060] Furthermore, the implementation of the algorithm model, the tuning of weighted coefficient parameters and the scope of application are discussed.

[0061] (1) Since this model is designed for the smooth startup of the service module of the national standard 28181 system, according to the existing national standard system construction plan, we can calculate the request value in the initial stage of the system, and we can obtain the average value of the system processing performance through previous engineering experience. Therefore, the initial conditions of this model are easy to calculate. When the total request volume and the average processing volume are known, using the step-by-step increase algorithm for application control is a relatively simple processing method. However, using this algorithm control alone will lead to a type of inapplicable scenario. That is, when there is a large fluctuation between the instantaneous processing speed and the average processing speed, the step-by-step increase algorithm cannot dynamically adjust the difference between the two speeds, that is, the application volume allowed by the model can only be a fixed value, that is, the empirical average value. If this value is smaller than the instantaneous processing value, the system tasks will gradually accumulate, which may eventually lead to system congestion. Therefore, the allowed application value can only be set to a smaller value. Although this is not easy to cause system congestion, it wastes some service performance and causes the system to take longer to achieve smooth startup. Therefore, the design combines the exponentially weighted moving average algorithm and the step-by-step increase algorithm. And some modifications were made to the exponentially weighted moving algorithm, removing the exponentially weighted part of the historical data and only weighting the data from the previous step.

[0062] (2) About the setting of the parameter W value in the model. The W value is actually the weight coefficient of the value of the current moment that the system calculates to allow the application, the value of the request actually completed at the previous moment, and the value of the request allowed by the system last time. The W value range is between 0 and 1. When the W value tends to 0, the system refers less to the previous request moment, and the current request value tends to the actual completion value of the previous step. If the actual completion request value of the previous step fluctuates greatly compared to the table experience value, then the calculation of the allowed application value at the current moment will have obvious feedback and will also produce large fluctuations.

[0063] Discussing VR in the experiment q-1 The value of is a random value within a range, simulating the impact of the randomness of system requests on system computing requests. The boundary of the random interval is 85% of the system experience value, that is, it is assumed that the minimum number of actually completed requests is 85% of the experience value. The boundary is the difference between the historical cumulative number of system requests and the historical completion number, that is, the number of remaining requests in the system.

[0064] By adjusting different W values, calculate V q When the standard deviation is large, it means that this group of V q The dispersion is high, that is, the fluctuation between the allowed request parameters and the actual completed request parameters is large.

[0065] The simulation results are as follows for W values ​​of 0.1, 0.3, 0.6 and 0.9: Figure 3 , Figure 4 , Figure 5 and Figure 6As shown in the figure (where solid line series 1 indicates allowed request parameters; dashed line series 2 indicates actual completed request parameters), when 0.1, the discreteness is 6.517071599; when 0.3, the discreteness is 5.082650227; when 0.6, the discreteness is 5.816642789; when 0.9, the discreteness is 3.294566233. Through multiple simulation operations, we can see that different model parameter W values ​​have an effect on the system request parameter Vr q-1 As the W value increases, the calculated Vr q-1 The value curve will tend to be smooth. That is, when the W value tends to 1, the system calculates the requested allowable value Vr q-1 The feedback corresponding to the actual completion value is less sensitive, the request window size is more stable, and it is more inclined to the historical experience value. On the contrary, when the W value tends to 0, the calculation of the allowed request value Vr q-1 The value of the request is more sensitive to the actual completion, and the window adjustment is faster.

[0066] Through the embodiments of the present disclosure, the corresponding W value setting model can be selected according to the situation. For systems with large actual request completion values ​​(for example, the request types are widely differentiated, there are database requests and registration requests at the same time, and the time difference between the two to complete the actual requests is large), a smaller W value is selected; conversely, a larger W value can be selected, corresponding to a relatively simple and stable request business. Furthermore, a reasonable dynamic adjustment is made to the speed difference between the instantaneous processing speed and the average processing speed, achieving the technical effect of obtaining reasonable utilization performance based on historical data while the system is not congested.

[0067] Based on the above embodiment, the system is configured according to the control parameters, including: using a firewall tool to add the newly allowed registration request to the permission list of the input chain according to the allowed request parameter value; the input chain is used to process the data packets entering the system.

[0068] Through the embodiments of the present disclosure, control parameters are used to control data packets received by the system, thereby controlling registration requests accepted by the system, thereby achieving slow system startup.

[0069] On the basis of the above embodiment, the control parameters are initialized, including: according to the preset step coefficient and the total number of registration requests, the average expected number of distributed requests is calculated as the initialization allowed request parameter value; the step coefficient represents the number of times the system adjusts the control parameters; the total number of registration requests includes the number of front-end device registrations and the number of back-end module registrations that the system needs to process at startup; according to the average expected number of distributed requests and the average request service time, the average update time of the control parameters is obtained; the average request service time is the number of registration requests processed per unit time; according to the average update time of the control parameters, the preset running time is set.

[0070] In this embodiment, in the initial state, the total amount of service registration requests and the total number of requests (i.e., the step coefficient) are obtained according to the actual situation, and the average request service time V is estimated. d .

[0071] Through the embodiments of the present disclosure, a reasonable preset step coefficient is set according to the total amount of registration requests that the system actually needs to process and the degree of slowness required; a reasonable preset running time for polling whether the system is busy is set according to the average update time of the control parameters. The stability of the system is increased by setting parameters reasonably, and the startup time of the system is adjusted.

[0072] On the basis of the above embodiment, the average update time of the control parameters is obtained according to the average expected number of distributed requests and the average request service time, which also includes: determining the average request service time according to the hardware configuration.

[0073] Among them, V d These are engineering experience values ​​and can be found in the table below.

[0074] Serial number Hardware configuration environment Experience Request Value 1 4C / 8G / 1000M 4 2 4C / 16G / 1000M 4 3 8C / 16G / 1000M 8 4 8C / 32G / 1000M 16 5 8C / 16G / 10000M 32 6 8C / 32G / 10000M 64

[0075] Through the embodiments of the present disclosure, control parameters are initialized according to the hardware configuration environment, initial parameters that meet various application environments are obtained, and the accuracy of control parameter adjustment is increased.

[0076] On the basis of the above embodiment, according to the preset step coefficient and the total number of registration requests, the average expected distribution request number is calculated to be used as the initialization allowed request parameter value, which also includes: calculating the total number of registration requests, including: counting the number of front-end devices and back-end modules, and calculating the total number of registration requests; wherein the calculation formula of the total number of registration requests is as follows:

[0077] R=F×N1+B×N2

[0078] In the formula, R represents the total number of registration requests; F represents the number of front-end devices; B represents the number of back-end modules; N1 and N2 represent the processing time coefficients of the front-end devices and back-end devices, respectively.

[0079] For example, the total number of registration requests R refers to the total number of application requests that the system needs to process when it starts, including the number of front-end device registrations and the number of back-end module registration queries. Since the number of front-end devices and back-end modules in each CMS domain in the national standard system is known (for example, the domain manages 1,000 front-end devices, 50 NRUs and a series of management modules), the total number of requests can be calculated, for example: R = 1000 × 1 + 50 × 10 + 8 × 10, where 1000 is the number of front-end devices, 50 is the number of NRU modules, and 8 is the number of other back-end modules. 1 and 10 are processing time coefficients, respectively. That is, the unit processing time of the back-end module or NRU is 10 times the front-end processing time.

[0080] Through the embodiments of the present disclosure, the total number of registration requests is counted according to the actual situation of the system, so as to set a reasonable distribution coefficient.

[0081] Based on the above method for slowly starting system services, the present disclosure also provides a device for slowly starting system services, which can be used to implement the above method. Figure 7 The device is described in detail.

[0082] like Figure 7 As shown, the device for slowly starting system services in this embodiment includes an initialization module, a control module and a circulation module.

[0083] The initialization module is used to initialize the control parameters in response to system startup; the control parameters at least include the allowed request parameter value; the allowed request parameter value is used to control the number of registration requests that the system is allowed to accept.

[0084] The control module is used to determine whether the system status is busy; if so, re-execute the step of determining whether the system status is busy after a preset time; if not, update the control parameters using historical data; and configure the system according to the control parameters.

[0085] The loop module is used to determine whether there is a registration request currently; if so, re-execute the step of determining whether the system status is busy; if not, end the restriction on the registration request and complete the system startup.

[0086] Figure 8 A block diagram of an electronic device suitable for implementing a method for slowly starting system services according to an embodiment of the present disclosure is schematically shown.

[0087] like Figure 8 As shown, the electronic device 800 according to an embodiment of the present disclosure includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage part 808 to a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include an onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0088] In RAM 803, various programs and data required for the operation of electronic device 800 are stored. Processor 801, ROM 802 and RAM 803 are connected to each other via bus 804. Processor 801 performs various operations of the method flow according to the embodiment of the present disclosure by executing the program in ROM 802 and / or RAM 803. It should be noted that the program can also be stored in one or more memories other than ROM 802 and RAM 803. Processor 801 can also perform various operations of the method flow according to the embodiment of the present disclosure by executing the program stored in the one or more memories.

[0089] According to an embodiment of the present disclosure, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to the bus 804. The electronic device 800 may further include one or more of the following components connected to the I / O interface 805: an input portion 806 including a keyboard, a mouse, etc.; an output portion 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 808 including a hard disk, etc.; and a communication portion 809 including a network interface card such as a LAN card, a modem, etc. The communication portion 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed, so that a computer program read therefrom is installed into the storage portion 808 as needed.

[0090] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

[0091] The embodiment of the present disclosure also includes a computer program product, which includes a computer program, and the computer program contains program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the method provided by the embodiment of the present disclosure.

[0092] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level process and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, python, "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on the remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect through the Internet).

[0093] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0094] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0095] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A method for slowly starting a system service, characterized in that: include: In response to system startup, initializing control parameters; the control parameters at least include an allowed request parameter value; The allowed request parameter value is used to control the number of registration requests that the system allows to accept; Determine whether the system status is busy; if so, re-execute the step of determining whether the system status is busy after a preset running time; If not, updating the control parameters using historical data; configuring the system according to the control parameters; Determine whether there is a registration request currently; if so, re-execute the step of determining whether the system status is busy; if not, end the restriction on the registration request and complete the system startup.

2. The method according to claim 1, wherein: Updating the control parameters using historical data includes: Update the allowed request parameter value according to the allowed request parameter value at the last moment, the actually completed request parameter value at the last moment and the weighting coefficient; The formula for updating the allowed request parameter value is as follows: V q =V q-1 ×W+(1-W)×Vr q-1 Where V q Indicates that the parameter value is allowed to be requested at time q; V q-1 Indicates that the parameter value is allowed to be requested at time q; Vr q-1 represents the actual completed request parameter value from time q-1 to time q; W represents the preset weighting coefficient, which is used to characterize the influence ratio of the historical allowed request parameter value and the actual completed request parameter value.

3. The method according to claim 2, wherein: The allowed request parameter value is updated according to the allowed request parameter value at the previous moment, the actually completed request parameter value at the previous moment, and the weighted coefficient, wherein the allowed request parameter value also includes: According to the actual completed request parameter value at the last moment, set the weighting coefficient, including: Determine whether the actual completion request parameter value is greater than a preset threshold; if so, set it to a first weighting coefficient greater than 0.5; if not, set it to a second weighting coefficient less than 0.5; the value range of the weighting coefficient is 0 to 1.

4. The method according to claim 2, wherein: Configuring the system according to the control parameters includes: By using a firewall tool, the newly added registration request is added to the permission list of the input chain according to the permission request parameter value; the input chain is used to process the data packets entering the system.

5. The method according to claim 1, wherein: Initialize control parameters, including: According to the preset step coefficient and the total number of registration requests, the average expected number of distributed requests is calculated to be used as the initialization allowed request parameter value; the step coefficient represents the number of times the system adjusts the control parameter; the total number of registration requests includes the number of front-end device registrations and the number of back-end module registrations that the system needs to process when starting up; According to the average expected number of distributed requests and the average request service time, the average update time of the control parameter is obtained; the average request service time is the number of registration requests processed per unit time; The preset running time is set according to the average update time of the control parameters.

6. The method according to claim 5, wherein: According to the average expected number of distributed requests and the average request service time, the average update time of the control parameters is obtained, which also includes: The average request service time is determined according to hardware configuration.

7. The method according to claim 5, wherein: According to the preset step coefficient and the total number of registration requests, the average expected number of distributed requests is calculated to be used as the allowed request parameter value for initialization, and the above also includes: Calculate the total number of registration requests, including: Count the number of front-end devices and back-end modules, and calculate the total number of registration requests; The calculation formula for the total number of registration requests is as follows: R=F×N1+B×N2 In the formula, R represents the total number of registration requests; F represents the number of front-end devices; B represents the number of back-end modules; N1 and N2 represent the processing time coefficients of the front-end devices and back-end devices, respectively.

8. A device for slowly starting system services, characterized in that: The device can be used to implement the method according to any one of claims 1 to 7, and the device comprises: An initialization module, for initializing control parameters in response to system startup; the control parameters at least include a request permission parameter value; the request permission parameter value is used to control the number of registration requests that the system allows to accept; A control module, used to determine whether the system status is busy; if so, re-execute the step of determining whether the system status is busy after a preset running time; if not, update the control parameters using historical data; and configure the system according to the control parameters; The loop module is used to determine whether there is a registration request currently; if so, re-execute the step of determining whether the system status is busy; if not, end the restriction on the registration request and complete the system startup.

9. An electronic device, comprising: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors are enabled to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to execute the method according to any one of claims 1 to 7.

Images