Time-out time determination method, apparatus, device, medium, and program product

Abstract

This application provides a method, apparatus, device, medium, and program product for determining timeout, relating to the field of electronic equipment technology, and is used to improve the stability and resource utilization efficiency of distributed systems. The specific technical solution is as follows: Obtain call data from the most recent N calls to a distributed service; the call data includes: call response time, call result, percentage of active threads in the thread pool, and call frequency load; N is a positive integer; determine a real-time load coefficient based on the percentage of active threads in the thread pool and the call frequency load; determine a response time fluctuation coefficient based on the standard deviation and average value of the call response time; determine a timeout failure rate based on the number of timeout failures in the call results; and determine the timeout time corresponding to the distributed service based on the real-time load coefficient, response time fluctuation coefficient, and timeout failure rate. This application is applied to scenarios involving determining the timeout time of distributed services.

Description

Technical Field

[0001] This application relates to the field of electronic equipment technology, and in particular to a method, apparatus, device, medium, and program product for determining timeout. Background Technology

[0002] In distributed systems, remote calls between distributed services are the core interaction method for implementing business functions. Timeout settings, as a key parameter for ensuring system stability, directly affect the availability and performance of distributed services. Therefore, reasonable timeout values ​​must be set during the development of distributed services.

[0003] Currently, timeouts for distributed services are primarily set using a static configuration approach. This means developers preset a timeout based on experience and encode it in a configuration file or code. This allows for setting a fixed timeout for distributed service calls.

[0004] However, according to the above method, the timeout of the distributed service can only be configured to a fixed timeout. A fixed timeout is difficult to adapt to the dynamic changes in the response time of the distributed service, resulting in poor stability and low resource utilization efficiency of the distributed system. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and program product for determining timeout time, which can increase the stability of distributed systems and improve resource utilization efficiency.

[0006] In a first aspect, embodiments of this application provide a method for determining timeout, the method comprising: obtaining call data from the most recent N calls to a distributed service; the call data including: call response time, call result, percentage of active threads in the thread pool, and call frequency load; a call result being used to characterize any one of the following: call success, call timeout failure; N being a positive integer; determining a real-time load coefficient based on the percentage of active threads in the thread pool and the call frequency load; determining a response time fluctuation coefficient based on the standard deviation and average value of the call response time; determining a timeout failure rate based on the number of timeout failures in the call results; and determining the timeout corresponding to the distributed service based on the real-time load coefficient, the response time fluctuation coefficient, and the timeout failure rate.

[0007] The technical solution provided in this application brings at least the following beneficial effects: the timeout time corresponding to the distributed service can be determined based on the response time and call result of the most recent N calls to the distributed service. That is, the timeout time corresponding to the distributed service can be dynamically adjusted based on the response time and call result, so that the determined timeout time can adapt to the dynamic changes in the response time of the distributed service. This can increase the stability of the distributed system and improve the efficiency of resource utilization.

[0008] One possible implementation involves determining the real-time load coefficient based on the aforementioned active thread percentage and call frequency load of the thread pool, including: weighting the active thread percentage of the thread pool to obtain a first active thread percentage; weighting the call frequency load to obtain a first call frequency load; and determining the sum of the first active thread percentage and the first call frequency load as the real-time load coefficient.

[0009] Another possible implementation, which determines the response time fluctuation coefficient based on the standard deviation and the average value of the call response time, includes: determining the ratio of the standard deviation and the average value of the call response time as the response time fluctuation coefficient.

[0010] Another possible implementation is to determine the timeout failure rate based on the number of timeout failures in the call results, which includes: determining the timeout failure rate as the ratio of the number of timeout failures in the call results to the total number of calls to the distributed service.

[0011] Another possible implementation involves determining the timeout for a distributed service based on the real-time load coefficient, response time fluctuation coefficient, and timeout failure rate. This includes: multiplying the base timeout, compensation time, and adjustment factor to determine the timeout for the distributed service; where the adjustment factor is the sum of the first parameter, the second parameter, and the third parameter; the first parameter is the product of the real-time load coefficient and the first weight; the second parameter is the product of the response time fluctuation coefficient and the second weight; the third parameter is the product of the timeout failure rate and the third weight; the base timeout is determined based on the historical response time of the distributed service; and the compensation time is determined based on the average latency of the network where the electronic device is located and the service reservation time of the distributed service.

[0012] Another possible implementation is that, before determining the timeout time corresponding to the distributed service by multiplying the base timeout time, the compensation time, and the adjustment factor, the method further includes: adjusting the base timeout time using a first value when the timeout failure rate is greater than or equal to the circuit breaker threshold.

[0013] Another possible implementation of the above method includes: adjusting the first weight, second weight, and third weight using a linear regression model according to a first time interval.

[0014] Secondly, embodiments of this application provide a timeout determination device, comprising: an acquisition module and a determination module; the acquisition module is used to acquire call data of the most recent N calls to a distributed service; the call data includes: call response time, call result, percentage of active threads in the thread pool, and call frequency load; the determination module is used to determine a real-time load coefficient based on the percentage of active threads in the thread pool and the call frequency load; and to determine a response time fluctuation coefficient based on the standard deviation and average value of the call response time; and to determine a timeout failure rate based on the number of timeout failures in the call result; and to determine the timeout time corresponding to the distributed service based on the real-time load coefficient, the response time fluctuation coefficient, and the timeout failure rate.

[0015] One possible implementation is that the aforementioned determining module is specifically used to perform weighted processing on the active thread ratio of the thread pool to obtain the first active thread ratio of the thread pool; and to perform weighted processing on the call frequency load to obtain the first call frequency load; and to determine the sum of the first active thread ratio of the thread pool and the first call frequency load as the real-time load coefficient.

[0016] Another possible implementation is that the aforementioned determining module is specifically used to determine the response time fluctuation coefficient as the ratio of the standard deviation of the call response time to the average value of the call response time.

[0017] Another possible implementation is that the aforementioned determining module is also specifically used to determine the timeout failure rate as the ratio of the number of timeout failures in the call results to the total number of calls to the distributed service.

[0018] In another possible implementation, the aforementioned determining module is further specifically used to determine the timeout time corresponding to the distributed service by multiplying the base timeout time, the compensation time, and the adjustment factor; wherein, the adjustment factor is the sum of the first parameter, the second parameter, and the third parameter; the first parameter is the product of the real-time load coefficient and the first weight; the second parameter is the product of the response time fluctuation coefficient and the second weight; the third parameter is the product of the timeout failure rate and the third weight; the base timeout time is determined based on the historical response time of the distributed service; the compensation time is determined based on the average latency of the network where the electronic device is located and the service reservation time of the distributed service.

[0019] In another possible implementation, the timeout determination device further includes an adjustment module; the adjustment module is used to adjust the basic timeout using a first value before the determination module determines the product of the basic timeout, the compensation time, and the adjustment factor as the timeout corresponding to the distributed service, provided that the timeout failure rate is greater than or equal to the circuit breaker threshold.

[0020] In another possible implementation, the aforementioned adjustment module is also used to adjust the first weight, the second weight, and the third weight using a linear regression model according to a first time interval.

[0021] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory stores a program or instructions executable on the processor, wherein the program or instructions, when executed by the processor, implement the method of the first aspect described above.

[0022] Fourthly, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the method of the first aspect described above.

[0023] Fifthly, this application provides a computer program product stored in a storage medium, which, when executed by a computer, implements the method described in the first aspect.

[0024] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the method described in the first aspect.

[0025] The beneficial effects of the second to sixth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0026] Figure 1 A schematic diagram of the network architecture for applying a timeout determination method provided in this application embodiment;

[0027] Figure 2 A flowchart illustrating a method for determining timeout duration provided in an embodiment of this application;

[0028] Figure 3 A flowchart illustrating another method for determining timeout duration provided in an embodiment of this application;

[0029] Figure 4 A flowchart illustrating another method for determining timeout duration provided in an embodiment of this application;

[0030] Figure 5 A flowchart illustrating another method for determining timeout duration provided in an embodiment of this application;

[0031] Figure 6 A flowchart illustrating another method for determining timeout duration provided in this application embodiment;

[0032] Figure 7 A flowchart illustrating another method for determining timeout duration provided in this application embodiment;

[0033] Figure 8 A flowchart illustrating another method for determining timeout duration provided in this application embodiment;

[0034] Figure 9 This is a schematic diagram of a timeout determination device provided in an embodiment of this application;

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

[0036] The following is a detailed description, with reference to the accompanying drawings, of a method, apparatus, device, medium, and program product for determining timeout time provided in this application.

[0037] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0038] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0039] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0040] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0041] The present application provides a method, apparatus, device, medium, and program product for determining timeout, which can be applied to scenarios involving determining the timeout of distributed services.

[0042] In distributed systems, remote calls between services are the core interaction method for implementing business functions, and timeout settings, as a key parameter to ensure system stability, directly affect service availability and performance. Java, as a mainstream development language, is widely used in building distributed services; service calls in frameworks such as Spring Cloud and Dubbo all require setting reasonable timeout values.

[0043] Currently, timeout settings for distributed services primarily employ a static configuration approach. This means developers preset a fixed value based on experience and hard-coded it into configuration files or code. This allows for setting a fixed timeout for distributed service calls.

[0044] However, this approach has significant shortcomings in practical applications: First, the response time of services in a distributed environment is affected by various factors, such as network fluctuations, changes in service load, and data volume, and a fixed timeout setting cannot adapt to such dynamic changes; Second, when the service load suddenly increases, a fixed short timeout can easily lead to a large number of call failures, or even trigger a service avalanche; while when the load is low, an excessively long timeout will cause thread resources to be occupied for a long time, reducing the overall concurrency capability of the system; thus, the distributed system has poor stability and low resource utilization efficiency.

[0045] To address the aforementioned technical problems, embodiments of this application provide a method, apparatus, device, medium, and program product for determining timeout. This method can determine the timeout corresponding to a distributed service based on the response time and call results of the most recent N calls. In other words, the timeout corresponding to the distributed service can be dynamically adjusted based on the response time and call results, thereby adapting the determined timeout to the dynamic changes in the distributed service response time. This increases the stability of the distributed system and improves resource utilization efficiency.

[0046] The following description, in conjunction with the accompanying drawings, details a method, apparatus, device, medium, and program product for determining timeout provided in this application.

[0047] Figure 1 The network architecture for applying a timeout determination method provided in an embodiment of this application is illustrated. For example... Figure 1 As shown, the network architecture includes a timeout determination device 101 and a terminal device 102. The timeout determination device 101 and the terminal device 102 are interconnected.

[0048] In some embodiments, the timeout determination device 101 may be a server, a computer, or a processor or processing unit within a server or computer. The server may be a single server or a server cluster comprising multiple servers. It should be noted that the specific device form of the timeout determination device 101 is not limited in the embodiments of this application. Figure 1 The timeout determination device 101 is used as an example of a single server.

[0049] In some embodiments, the terminal device may be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., and the embodiments of this application do not specifically limit it. Figure 1 The example shown is a mobile phone, with terminal device 102 as an example.

[0050] It should be noted that the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0051] See Figure 2 This is a flowchart illustrating a method for determining timeout duration provided in an embodiment of this application. Figure 2 As shown in the figure, the timeout determination method provided in this application embodiment can be implemented by the above-mentioned timeout determination device, specifically including the following steps 201 to 205.

[0052] Step 201: The timeout determination device obtains the call data of the most recent N calls to the distributed service.

[0053] The aforementioned call data includes: call response time, call result, percentage of active threads in the thread pool, and call frequency load; a call result is used to represent any of the following: call success, call timeout failure; N is a positive integer.

[0054] In some embodiments, the call data of the distributed service is obtained (i.e., the call data of the most recent N calls to the distributed service). The Java AOP interceptor is used to intercept the distributed service calls in the entire chain. The context of each call is stored in ThreadLocal. Key data is obtained: call timestamp, service identifier, method name, request parameter size, response time, call result (success / timeout failure / business exception), and the data is output to the ELK distributed logging system through structured logs.

[0055] Furthermore, in the above steps, Spring AOP technology is used to implement interceptors, which intercept service call methods annotated with @FeignClient or @Reference through the @Around annotation, ensuring that data can be effectively collected for different types of remote calls.

[0056] In some embodiments, the above-mentioned distributed service can be a Java distributed service, applied in frameworks such as Spring Cloud (cloud framework) and Dubbo.

[0057] In some embodiments, the call frequency load can be the percentage of the number of requests per unit time relative to the system's maximum processing capacity; it is obtained by calculating the number of calls per second and dividing by 100.

[0058] In some embodiments, the above-mentioned call response time is the total time taken from when the user initiates a request to when the system returns a complete result.

[0059] In some embodiments, the timeout determination device described above can be implemented using Spring AOP to intercept service calls. The interceptor uses ThreadLocal to store the call context and retrieves the aforementioned call data.

[0060] In some embodiments, a call timeout failure is a call failure caused by a timeout.

[0061] In some embodiments, the percentage of active threads in the thread pool is a quantitative indicator of thread pool resource utilization.

[0062] Step 202: The timeout determination device determines the real-time load coefficient based on the percentage of active threads in the thread pool and the call frequency load.

[0063] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, step 202 above can be implemented through steps 202a to 202c.

[0064] Step 202a: The timeout determination device performs weighted processing on the proportion of active threads in the thread pool to obtain the proportion of active threads in the first thread pool.

[0065] In some embodiments, the above weighting process can be: the percentage of active threads in the thread pool is weighted at 0.6.

[0066] Step 202b: The timeout determination device performs weighted processing on the call frequency load to obtain the first call frequency load.

[0067] In some embodiments, the above weighting process can be: the above call frequency load weighting is 0.4.

[0068] Step 202c: The timeout determination device determines the real-time load coefficient by summing the percentage of active threads in the first thread pool and the first call frequency load.

[0069] In some embodiments, the aforementioned real-time call frequency load is the real-time ratio of the service's current actual call frequency to its maximum processing capacity within a preset short time window, used to dynamically reflect the instantaneous load pressure of the system.

[0070] In some embodiments, the real-time load coefficient is determined by obtaining the percentage of active threads in the first thread pool and the first call frequency load. This method can improve the accuracy of determining the real-time load coefficient because it weights the percentage of active threads in the thread pool and the call frequency load.

[0071] Step 203: The timeout determination device determines the response time fluctuation coefficient based on the standard deviation of the call response time and the average value of the call response time.

[0072] In some embodiments, the above-mentioned call response time can be the total time spent from initiating a service request to fully receiving and parsing the returned response result.

[0073] In some embodiments, the standard deviation of the call response time can be a core statistical indicator for quantifying the dispersion of a single call response time of a service or interface relative to the average response time.

[0074] In some embodiments, the above-mentioned response time fluctuation coefficient can be used to measure the relative fluctuation of the interface response; the smaller the value, the more stable the response.

[0075] In some embodiments, combined with Figure 2 ,like Figure 4 As shown, step 203 above can be implemented through step 203a as follows.

[0076] Step 203a: The timeout determination device determines the response time fluctuation coefficient by the ratio of the standard deviation of the call response time to the average value of the call response time.

[0077] In some embodiments, since the ratio of the standard deviation of the call response time to the average call response time can be determined as the response time fluctuation coefficient, the fluctuation of the response time can be accurately reflected by this ratio, thereby improving the accuracy of the time fluctuation coefficient.

[0078] Step 204: The timeout determination device determines the timeout failure rate based on the number of timeout failures in the call results.

[0079] In some embodiments, combined with Figure 2 ,like Figure 5 As shown, step 204 above can be implemented through step 204a as follows.

[0080] Step 204a: The timeout determination device determines the timeout failure rate by the ratio of the number of timeout failures in the call results to the total number of calls to the distributed service.

[0081] In some embodiments, based on the acquired data, a scheduled task (ScheduledExecutorService) is used to perform a status analysis every 10 seconds: a sliding window (the window size is dynamically adjusted to max(100, number of calls in the last minute / 2)) is constructed to store the data of the most recent N calls; the real-time load coefficient is calculated by combining the proportion of active threads in the thread pool (0~1) and the call frequency load (number of calls per second / 100, 0~1), and weighted to obtain (thread pool load × 0.6 + frequency load × 0.4); the response time fluctuation coefficient is calculated as the ratio of the standard deviation to the average response time within the sliding window; and the timeout failure rate is calculated as the proportion of timeout failure calls within the window to the total number of calls.

[0082] Furthermore, in the above steps, the size N of the sliding window is dynamically adjusted according to the service call frequency to ensure that there is a sufficient sample size in high-frequency call scenarios and that the analysis is not delayed due to waiting for samples in low-frequency call scenarios.

[0083] In some embodiments, the total number of calls to the above-mentioned distributed service can be the sum of the number of times the call to the supermarket failed and the number of times the call timed out successfully.

[0084] In some embodiments, the ratio of the number of timeout failures in the call result to the total number of calls to the distributed service can be determined as the timeout failure rate. The obtained timeout failure rate can quickly locate service unavailability issues, thereby ensuring system stability.

[0085] Step 205: The timeout determination device determines the timeout time corresponding to the distributed service based on the real-time load coefficient, response time fluctuation coefficient, and timeout failure rate.

[0086] In some embodiments, the timeout time corresponding to the above-mentioned distributed service is the "maximum wait response time" set when one service calls another service.

[0087] In some embodiments, combined with Figure 2 ,like Figure 6 As shown, step 205 above can be implemented through step 205a. If no result is received after this time, the call is deemed to have failed and no further waiting is allowed.

[0088] Step 205a: The timeout determination device determines the timeout time corresponding to the distributed service by multiplying the basic timeout time, the compensation time, and the adjustment factor.

[0089] The adjustment factor is the sum of the first parameter, the second parameter, and the third parameter. The first parameter is the product of the real-time load coefficient and the first weight. The second parameter is the product of the response time fluctuation coefficient and the second weight. The third parameter is the product of the timeout failure rate and the third weight. The basic timeout time is determined based on the historical response time of the distributed service. The compensation time is determined based on the average latency of the network where the electronic device is located and the service reservation time of the distributed service.

[0090] In some embodiments, the average latency of the network can be the average time taken from sending a request to receiving a response across multiple service calls, reflecting the overall response speed of the network and services.

[0091] In some embodiments, the business reservation time for the above-mentioned distributed service is a buffer period specifically reserved for the execution of business logic within the total timeout time. This excludes time-consuming processes such as network and middleware issues, ensuring that the business has enough time to process normally and avoiding misjudgment of timeout.

[0092] In some embodiments, the aforementioned base timeout is determined by the 95th percentile response time.

[0093] In some embodiments, the compensation time can be the sum of the average network latency and the service reservation time.

[0094] In some embodiments, the sum of the first weight, the second weight, and the third weight is 1.

[0095] For example, the first weight is 0.4, the second weight is 0.3, and the third weight is 0.3.

[0096] In some embodiments, the timeout time is obtained by adjusting the base timeout time and the adjustment factor. This method enables adaptive timeout calculation because it allows for the adjustment of the base timeout time and the adjustment factor according to the embodiments.

[0097] In the timeout determination method provided in the embodiments of this application, the timeout time corresponding to the distributed service can be determined based on the response time and call result of the most recent N calls to the distributed service. That is, the timeout time corresponding to the distributed service can be dynamically adjusted based on the response time and call result, so that the determined timeout time can adapt to the dynamic changes in the response time of the distributed service. This can increase the stability of the distributed system and improve the efficiency of resource utilization.

[0098] In some embodiments, combined with Figure 6 ,like Figure 7 As shown, before step 205a and after step 204, the timeout determination method provided in this application embodiment may further include step 206.

[0099] Step 206: If the timeout failure rate is greater than or equal to the circuit breaker threshold, the timeout determination device adjusts the base timeout time using the first value.

[0100] In some embodiments, the timeout calculation for distributed services uses a weighted algorithm to calculate the timeout period, with the formula: Timeout Period = T1 × adjustFactor + T2, where T1 is the base timeout period (determined by the 95th percentile response time in the service's history), adjustFactor is the adjustment factor (α × load coefficient + β × volatility coefficient + γ × failure rate, α + β + γ = 1, initial values ​​α = 0.4, β = 0.3, γ = 0.3, limited to between 0.5 and 2.0), and T2 is the compensation time (average network latency + service reservation time, default 150ms); when the failure rate exceeds the circuit breaker threshold (default 20%), circuit breaker protection is triggered, T1 = T1 × 1.5;

[0101] Furthermore, in the above steps, the basic timeout time T1 is determined by periodically (every hourly) calculating the 95th percentile response time of the service history call data, and the compensation time T2 is set comprehensively based on the average network latency and the preset service processing reserve time.

[0102] In some embodiments, the timeout configuration is dynamically updated by updating the timeout calculated by S3 to the configuration center via the Spring CloudConfig API, and then sending a refresh event via Spring Cloud Bus to trigger all service callers to load the new configuration in real time.

[0103] Furthermore, in the above steps, the configuration update adopts a two-level caching mechanism, with local cache timeout configuration and validity period set (default 30 seconds) to reduce the frequency of access to the configuration center and reduce system overhead.

[0104] In some embodiments, the aforementioned base timeout period is adjusted to 1.5 times this base.

[0105] In some embodiments, the aforementioned circuit breaker threshold can be a critical value for determining whether to enable circuit breaker protection. When indicators such as failure rate and response time exceed this critical value, the system will automatically cut off the call to prevent the fault from escalating.

[0106] For example, the aforementioned circuit breaker threshold could be 20%.

[0107] In some embodiments, the timeout period can be adjusted when the timeout failure rate is greater than or equal to the circuit breaker threshold. Since the base timeout period can be dynamically adjusted, the timeout period can be dynamically calculated, thus enabling adaptive adjustment of the timeout period.

[0108] In some embodiments, combined with Figure 6 ,like Figure 8 As shown, the timeout determination method provided in this application embodiment may further include the following step 207.

[0109] It should be noted that, Figure 8 The example shown is only illustrative, with step 207 performed after step 205a. In actual implementation, step 207 can be performed before or after step 205a, and this embodiment does not impose any limitations.

[0110] Step 207: The timeout determination device adjusts the first weight, second weight, and third weight using a linear regression model according to the first time interval.

[0111] In some embodiments, historical data (service status and timeout adjustment effects over the past 7 days) are trained using a linear regression model at 3:00 AM every day to dynamically optimize the weight coefficients of α, β, and γ, thereby improving the adjustment accuracy.

[0112] Furthermore, in the above steps, the weight coefficient optimization adopts the gradient descent algorithm, with the optimization objectives of "lowest timeout failure rate" and "optimal average response time" to iteratively calculate the optimal weight combination.

[0113] In some embodiments, the first time interval can be the system default time interval, or it can be a time interval that the user can arbitrarily set according to actual usage needs.

[0114] For example, taking the first time interval as an arbitrary time interval set by the user according to actual usage needs, the first time interval can be any time interval such as 3 days or 7 days set by the user.

[0115] In some embodiments, the linear regression model described above can be used to fit the data with a straight line to find the linear relationship between the independent variable X and the dependent variable Y, which can then be used for prediction.

[0116] In some embodiments, the linear regression model described above can be trained on historical data within a first time interval set by the user, and the weight coefficients can be dynamically optimized based on the service status and timeout adjustment effect within the first time interval.

[0117] In some embodiments, the above-mentioned adjustment of weights dynamically optimizes the weight coefficients by considering the service status and timeout adjustment effect within a first time interval.

[0118] In some embodiments, the weights are adjusted using a linear regression model. This approach can dynamically adjust the weights by predicting the effect of timeout adjustment based on data within a first time interval, thereby optimizing the adjustment strategy and improving the adjustment accuracy.

[0119] The timeout determination method of this application will be described below through specific embodiments.

[0120] This embodiment takes a Java distributed service based on Spring Cloud as an example to explain in detail the implementation process of the timeout determination method provided in this application embodiment.

[0121] Step 1: Service call data collection (i.e., obtaining call data from the most recent N calls to the distributed service)

[0122] Service call interception is implemented using Spring AOP. An interceptor class `ServiceCallInterceptor` is defined, which intercepts service call methods annotated with `@FeignClient` using the `@Around` annotation. Within the interceptor, `ThreadLocal` is used to store the call context, and data such as call timestamp, service name, request parameter size, and response time are collected and output to the ELK logging system via the Logback logging framework. The specific implementation code is as follows:

[0123] Java

[0124] @Aspect

[0125] @Component

[0126] public class ServiceCallInterceptor {

[0127] private static final Logger logger = LoggerFactory.getLogger(ServiceCallInterceptor.class);

[0128] private static final ThreadLocal <callcontext>callContextThreadLocal = new ThreadLocal<>();

[0129] @Around("@within(org.springframework.cloud.openfeign.FeignClient)")

[0130] public Object around(ProceedingJoinPoint joinPoint) throwsThrowable {

[0131] / / Record the start time of the call

[0132] long startTime = System.currentTimeMillis();

[0133] String serviceName = getServiceName(joinPoint);

[0134] int paramSize = calculateParamSize(joinPoint.getArgs());

[0135] CallContext context = new CallContext();

[0136] context.setTimestamp(startTime);

[0137] context.setServiceName(serviceName);

[0138] context.setParamSize(paramSize);

[0139] callContextThreadLocal.set(context);

[0140] try {

[0141] / / Perform the actual service call

[0142] Object result = joinPoint.proceed();

[0143] / / Successful call, record response time

[0144] long responseTime = System.currentTimeMillis() -startTime;

[0145] context.setResponseTime(responseTime);

[0146] context.setSuccess(true);

[0147] logCallData(context);

[0148] return result;

[0149] } catch (Exception e) {

[0150] / / Call failed, record the exception type

[0151] long responseTime = System.currentTimeMillis() -startTime;

[0152] context.setResponseTime(responseTime);

[0153] context.setSuccess(false);

[0154] context.setExceptionType(e instanceof TimeoutException ?"timeout" : "business");

[0155] logCallData(context);

[0156] throw e;

[0157] finally {

[0158] callContextThreadLocal.remove();

[0159] }

[0160] }

[0161] private void logCallData(CallContext context) {

[0162] / / Output the call data to the ELK system

[0163] logger.info("SERVICE_CALL_DATA|service:{}|timestamp:{}|paramSize:{}|responseTime:{}|success:{}|exceptionType:{}",

[0164] context.getServiceName(), context.getTimestamp(),context.getParamSize(),

[0165] context.getResponseTime(), context.isSuccess(),context.getExceptionType());

[0166] }

[0167] / / Other auxiliary methods...

[0168] }

[0169] ```

[0170] In a preferred embodiment, Java's ThreadLocal is used to store the context information of a single call, ensuring thread safety during data collection. ThreadLocal can isolate the call context of different threads in high-concurrency scenarios, avoiding data confusion and improving the accuracy of data collection.

[0171] Step 2: Service Status Analysis

[0172] Based on the collected call data, a service status evaluation model is constructed to calculate the service's real-time load coefficient, response time fluctuation coefficient, and failure rate. The specific implementation code is as follows:

[0173] Java

[0174] @Service

[0175] public class ServiceStatusAnalyzer {

[0176] @Autowired

[0177] private LogDataReader logDataReader;

[0178] / / Slide the window size dynamically based on service call frequency.

[0179] private int windowSize = 100;

[0180] public ServiceStatus analyzeServiceStatus(String serviceName) {

[0181] / / Get recent call data from the log system

[0182] List <calldata>callDataList = logDataReader.getRecentCallData(serviceName, windowSize);

[0183] / / Calculate real-time load factor

[0184] double loadFactor = calculateLoadFactor(serviceName);

[0185] / / Calculate the response time fluctuation coefficient

[0186] double responseTimeVariation = calculateResponseTimeVariation(callDataList);

[0187] / / Calculate the failure rate

[0188] double failureRate = calculateFailureRate(callDataList);

[0189] ServiceStatus status = new ServiceStatus();

[0190] status.setServiceName(serviceName);

[0191] status.setLoadFactor(loadFactor);

[0192] status.setResponseTimeVariation(responseTimeVariation);

[0193] status.setFailureRate(failureRate);

[0194] return status;

[0195] }

[0196] private double calculateLoadFactor(String serviceName) {

[0197] / / Get service thread pool information

[0198] ThreadPoolExecutor executor = getServiceThreadPool(serviceName);

[0199] int activeThreads = executor.getActiveCount();

[0200] int maxThreads = executor.getMaximumPoolSize();

[0201] / / Calculate the number of calls per unit of time

[0202] int callCount = logDataReader.getCallCountInLastMinute(serviceName);

[0203] int avgCallCount = logDataReader.getAverageCallCountPerMinute(serviceName);

[0204] / / Taking into account thread utilization and call frequency

[0205] double threadOccupancyRate = (double) activeThreads / maxThreads;

[0206] double callFrequencyRate = avgCallCount == 0 ? 1.0 : (double)callCount / avgCallCount;

[0207] return 0.6 * threadOccupancyRate + 0.4 * callFrequencyRate;

[0208] }

[0209] private double calculateResponseTimeVariation(List <calldata>callDataList) {

[0210] if (callDataList.isEmpty()) {

[0211] return 0.0;

[0212] }

[0213] / / Calculate the average response time

[0214] double avgResponseTime = callDataList.stream()

[0215] .mapToLong(CallData::getResponseTime)

[0216] .average()

[0217] .orElse(0.0);

[0218] / / Calculate the standard deviation of response time

[0219] double sumSquaredDiff = callDataList.stream()

[0220] .mapToDouble(data -> Math.pow(data.getResponseTime()- avgResponseTime, 2))

[0221] .sum();

[0222] double standardDeviation = Math.sqrt(sumSquaredDiff / callDataList.size());

[0223] / / Calculate the coefficient of variation (standard deviation / mean)

[0224] return avgResponseTime == 0 ? 0 : standardDeviation / avgResponseTime;

[0225] }

[0226] private double calculateFailureRate(List <calldata>callDataList){

[0227] if (callDataList.isEmpty()) {

[0228] return 0.0;

[0229] }

[0230] long failureCount = callDataList.stream()

[0231] .filter(data ->!data.isSuccess())

[0232] .count();

[0233] return (double) failureCount / callDataList.size();

[0234] }

[0235] / / Dynamically adjust the sliding window size

[0236] public void adjustWindowSize(String serviceName) {

[0237] int callFrequency = logDataReader.getCallCountInLastMinute(serviceName);

[0238] if (callFrequency > 1000) {

[0239] windowSize = 500;

[0240] } else if (callFrequency > 500) {

[0241] windowSize = 200;

[0242] } else if (callFrequency > 100) {

[0243] windowSize = 100;

[0244] } else {

[0245] windowSize = 50;

[0246] }

[0247] }

[0248] }

[0249] ```

[0250] In a preferred embodiment, the size N of the sliding window can be dynamically adjusted according to the service call frequency. The higher the call frequency, the larger the value of N, to ensure the accuracy of the statistical results. When the service call frequency exceeds 1000 times / minute, the window size is set to 500; when the call frequency is between 500 and 1000 times / minute, the window size is set to 200; when the call frequency is between 100 and 500 times / minute, the window size is set to 100; and when the call frequency is less than 100 times / minute, the window size is set to 50.

[0251] Step 3: Timeout Calculation

[0252] Based on the output of the service status assessment model, a weighted algorithm is used to calculate the adaptive timeout for the current service. The specific implementation code is as follows:

[0253] Java

[0254] @Service

[0255] public class TimeoutCalculator {

[0256] @Autowired

[0257] private ServiceStatusAnalyzer statusAnalyzer;

[0258] @Autowired

[0259] private HistoryDataRepository historyDataRepository;

[0260] / / Weighting coefficient

[0261] private double alpha = 0.5; / / Load factor weight

[0262] private double beta = 0.3; / / Response time fluctuation coefficient weight

[0263] private double gamma = 0.2; / / Failure rate weight

[0264] public long calculateTimeout(String serviceName) {

[0265] / / Get service status

[0266] ServiceStatus status = statusAnalyzer.analyzeServiceStatus(serviceName);

[0267] / / Get the base timeout (95th percentile response time)

[0268] long baseTimeout = historyDataRepository.get95PercentileResponseTime(serviceName);

[0269] / / Get network latency compensation time

[0270] long compensationTime = historyDataRepository.getAverageNetworkDelay();

[0271] / / Calculate the dynamic adjustment factor

[0272] double adjustFactor = calculateAdjustFactor(status);

[0273] / / Calculate adaptive timeout

[0274] long adaptiveTimeout = (long) (baseTimeout * adjustFactor +compensationTime);

[0275] / / Set upper and lower limits for timeout

[0276] long minTimeout = 500; / / Minimum timeout time, in milliseconds

[0277] long maxTimeout = 10000; / / Maximum timeout in milliseconds

[0278] return Math.max(minTimeout, Math.min(adaptiveTimeout,maxTimeout));

[0279] }

[0280] private double calculateAdjustFactor(ServiceStatus status) {

[0281] / / Calculate adjustment factor based on service status

[0282] double loadAdjust = 1 + status.getLoadFactor();

[0283] double variationAdjust = 1 + status.getResponseTimeVariation();

[0284] double failureAdjust = 1 + status.getFailureRate() * 2; / / The impact of failure rate on timeout is doubled.

[0285] / / Calculate the final adjustment factor using weighted average.

[0286] return alpha * loadAdjust + beta * variationAdjust + gamma *failureAdjust;

[0287] }

[0288] / / Update weight coefficients

[0289] public void updateWeightCoefficients(double newAlpha, doublenewBeta, double newGamma) {

[0290] double sum = newAlpha + newBeta + newGamma;

[0291] if (sum > 0) {

[0292] / / Normalization

[0293] this.alpha = newAlpha / sum;

[0294] this.beta = newBeta / sum;

[0295] this.gamma = newGamma / sum;

[0296] }

[0297] }

[0298] }

[0299] ```

[0300] In a preferred embodiment, the base timeout T is determined using the 95th percentile response time of historical service call data, and the compensation time T is set based on the average network latency. This approach more accurately reflects the actual response characteristics of the service and avoids unreasonable timeout settings due to extreme values.

[0301] Step 4: Dynamically update timeout period

[0302] The calculated adaptive timeout is updated in the service call configuration center, and the Java configuration refresh mechanism ensures that the service caller obtains the latest timeout configuration in real time. The specific implementation code is as follows:

[0303] Java

[0304] @Service

[0305] public class TimeoutConfigUpdater {

[0306] @Autowired

[0307] private TimeoutCalculator timeoutCalculator;

[0308] @Autowired

[0309] private ConfigurationService configService;

[0310] / / Update timeout configuration periodically

[0311] @Scheduled(fixedRate = 60000) / / Execute once per minute

[0312] public void updateTimeoutConfig() {

[0313] / / Get a list of all services that need to be monitored

[0314] List <string>serviceList = configService.getMonitoredServices();

[0315] for (String serviceName : serviceList) {

[0316] / / Calculate the new timeout

[0317] long newTimeout = timeoutCalculator.calculateTimeout(serviceName);

[0318] / / Update Configuration Center

[0319] String configKey = "service.timeout." + serviceName;

[0320] configService.updateConfig(configKey, String.valueOf(newTimeout));

[0321] / / Record update log

[0322] logger.info("Updated timeout for service {}: {} ms",serviceName, newTimeout);

[0323] }

[0324] / / Trigger configuration refresh

[0325] refreshServiceConfigs();

[0326] }

[0327] private void refreshServiceConfigs() {

[0328] / / Broadcast the RefreshRemoteApplicationEvent via Spring Cloud Bus

[0329] ApplicationEventPublisher publisher = ApplicationContextProvider.getApplicationContext();

[0330] publisher.publishEvent(new RefreshRemoteApplicationEvent(this, null, null));

[0331] }

[0332] }

[0333] ```

[0334] Step 5: Anomaly Feedback and Adjustment Optimization

[0335] When the service call failure rate exceeds a preset threshold, an exception feedback mechanism is triggered, adjusting the values ​​of weight coefficients α, β, and γ, and recalculating the timeout period to achieve self-optimization of the adjustment strategy. The specific implementation code is as follows:

[0336] Java

[0337] @Service

[0338] public class FeedbackOptimizer {

[0339] @Autowired

[0340] private ServiceStatusAnalyzer statusAnalyzer;

[0341] @Autowired

[0342] private TimeoutCalculator timeoutCalculator;

[0343] / / Failure rate threshold

[0344] private double failureRateThreshold = 0.05; / / 5%

[0345] / / Regularly check service status and optimize tuning strategies

[0346] @Scheduled(fixedRate = 300000) / / Executes every 5 minutes

[0347] public void optimizeStrategy() {

[0348] / / Get a list of all services that need to be monitored

[0349] List <string>serviceList = configService.getMonitoredServices();

[0350] for (String serviceName : serviceList) {

[0351] / / Get service status

[0352] ServiceStatus status = statusAnalyzer.analyzeServiceStatus(serviceName);

[0353] / / Check if the failure rate exceeds the threshold

[0354] if (status.getFailureRate() > failureRateThreshold) {

[0355] / / Adjust weighting coefficients based on service status characteristics

[0356] adjustWeightCoefficients(status);

[0357] / / Recalculate and update the timeout period

[0358] long newTimeout = timeoutCalculator.calculateTimeout(serviceName);

[0359] String configKey = "service.timeout." + serviceName;

[0360] configService.updateConfig(configKey, String.valueOf(newTimeout));

[0361] / / Record optimization logs

[0362] logger.info("Optimized timeout strategy for service{}: new timeout {} ms",

[0363] serviceName, newTimeout);

[0364] }

[0365] }

[0366] }

[0367] private void adjustWeightCoefficients(ServiceStatus status) {

[0368] double newAlpha, newBeta, newGamma;

[0369] / / Adjust weights based on service status characteristics

[0370] if (status.getLoadFactor() > 0.8) {

[0371] / / Increase the weight of the load factor if the load is high.

[0372] newAlpha = 0.7;

[0373] newBeta = 0.2;

[0374] newGamma = 0.1;

[0375] } else if (status.getResponseTimeVariation() > 0.5) {

[0376] / / Response time fluctuates significantly; increase the weight of the fluctuation coefficient.

[0377] newAlpha = 0.3;

[0378] newBeta = 0.6;

[0379] newGamma = 0.1;

[0380] } else if (status.getFailureRate() > 0.1) {

[0381] / / If the failure rate is high, increase the weight of the failure rate.

[0382] newAlpha = 0.3;

[0383] newBeta = 0.2;

[0384] newGamma = 0.5;

[0385] } else {

[0386] / / Default weight

[0387] newAlpha = 0.5;

[0388] newBeta = 0.3;

[0389] newGamma = 0.2;

[0390] }

[0391] / / Update weight coefficients

[0392] timeoutCalculator.updateWeightCoefficients(newAlpha, newBeta,newGamma);

[0393] }

[0394] }

[0395] In this way, the timeout time corresponding to the distributed service can be determined based on the response time and call result of the most recent N calls to the distributed service. That is, the timeout time corresponding to the distributed service can be dynamically adjusted based on the response time and call result, so that the determined timeout time can adapt to the dynamic changes in the response time of the distributed service. This can increase the stability of the distributed system and improve the efficiency of resource utilization.

[0396] Furthermore, this method collects service call data in real time through Java interceptors, analyzes service status based on a sliding window algorithm, dynamically adjusts timeout using a weighted calculation method, and possesses self-optimization capabilities. The entire process requires no manual intervention and can automatically adapt to different load scenarios based on the actual operating status of the service, effectively improving the success rate of distributed service calls and system resource utilization.

[0397] In practical applications, this method integrates seamlessly with mainstream Java distributed frameworks such as Spring Cloud and Dubbo, boasts low deployment costs, and is suitable for various microservice architecture systems. By dynamically adjusting timeout periods, the system can automatically adjust timeout strategies between services in response to traffic fluctuations and changes in network latency, avoiding system instability or resource waste caused by fixed timeout settings.

[0398] Furthermore, this method achieves adaptive adjustment of timeout time. Compared to existing fixed timeout configurations, it can dynamically adjust the timeout time based on the real-time status of the service, matching the timeout configuration with the actual service response capability, reducing the "false timeout" rate by approximately 40%, and improving the overall system availability. Through sliding windows and weighted algorithms, it comprehensively considers multiple factors such as service load, response fluctuations, and failure rates, making timeout adjustment more precise. In scenarios with fluctuating service load, it can reduce timeout failures by approximately 35% compared to static configurations. It has self-optimization capabilities, automatically adjusting weight coefficients through historical data analysis, so that the adjustment strategy is continuously optimized as the system runs, reducing the need for manual intervention and lowering operation and maintenance costs by approximately 50%. Based on the Java technology stack, it seamlessly integrates with mainstream distributed frameworks (Spring Cloud, Dubbo), making deployment simple, with minimal impact on existing systems, and achieving high availability and scalability of the technical solution.

[0399] Furthermore, the core algorithm modules of this method (sliding window state analysis and weighted adaptive calculation) can be organized into open-source components and submitted to the Spring Cloud Alibaba community contribution library in the future to form an industry reuse standard and reduce the integration cost of similar distributed service architectures.

[0400] Furthermore, this method can reduce the service call timeout failure rate and improve thread resource utilization, thus demonstrating practical effectiveness and laying the foundation for its full implementation.

[0401] Furthermore, this application addresses the shortcomings of the static timeout configuration mode in existing Java distributed service architectures by providing a Java-based distributed service timeout adaptive adjustment method and system, solving the problems of poor adaptability, insufficient stability, and high maintenance costs in existing timeout configurations.

[0402] It should be noted that the descriptions of steps one through five in this embodiment can be found in the descriptions in the above embodiments, and will not be repeated here.

[0403] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

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

[0405] This application embodiment can divide the timeout determination device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0406] In some embodiments, this application also provides a timeout determination device. The timeout determination device may include one or more functional modules for implementing the timeout determination method of the above method embodiments.

[0407] For example, Figure 9 This is a schematic diagram of a timeout determination device provided in an embodiment of this application. Figure 9 As shown, the timeout determination device 900 includes an acquisition module 901 and a determination module 902.

[0408] The aforementioned acquisition module 901 is used to acquire call data from the most recent N calls to the distributed service. The call data includes: call response time, call result, percentage of active threads in the thread pool, and call frequency load. The aforementioned determination module 902 is used to determine the real-time load coefficient based on the percentage of active threads in the thread pool and the call frequency load; and to determine the response time fluctuation coefficient based on the standard deviation and average value of the call response time; and to determine the timeout failure rate based on the number of timeout failures in the call results; and to determine the timeout time corresponding to the distributed service based on the real-time load coefficient, the response time fluctuation coefficient, and the timeout failure rate.

[0409] The timeout determination device provided in this application can determine the timeout time corresponding to the distributed service based on the response time and call result of the most recent N calls to the distributed service. That is, the timeout time corresponding to the distributed service can be dynamically adjusted based on the response time and call result, so that the determined timeout time can adapt to the dynamic changes in the response time of the distributed service. This can increase the stability of the distributed system and improve the efficiency of resource utilization.

[0410] In some embodiments, the determining module 902 is specifically used to perform weighted processing on the active thread ratio of the thread pool to obtain a first active thread ratio; and to perform weighted processing on the call frequency load to obtain a first call frequency load; and to determine the sum of the first active thread ratio of the thread pool and the first call frequency load as the real-time load coefficient.

[0411] In some embodiments, the determining module 902 is specifically used to determine the response time fluctuation coefficient as the ratio of the standard deviation of the call response time to the average value of the call response time.

[0412] In some other embodiments, the determining module 902 is further configured to determine the timeout failure rate as the ratio of the number of timeout failures in the call results to the total number of calls to the distributed service.

[0413] In some other embodiments, the determining module 902 is further configured to determine the timeout time corresponding to the distributed service by multiplying the basic timeout time, the compensation time, and the adjustment factor; wherein the adjustment factor is the sum of the first parameter, the second parameter, and the third parameter; the first parameter is the product of the real-time load coefficient and the first weight; the second parameter is the product of the response time fluctuation coefficient and the second weight; the third parameter is the product of the timeout failure rate and the third weight; the basic timeout time is determined based on the historical response time of the distributed service; and the compensation time is determined based on the average latency of the network where the electronic device is located and the service reservation time of the distributed service.

[0414] In some other embodiments, the timeout determination device 900 further includes an adjustment module; the adjustment module is used to adjust the basic timeout time using a first value before the determination module determines the product of the basic timeout time, the compensation time, and the adjustment factor as the timeout time corresponding to the distributed service, provided that the timeout failure rate is greater than or equal to the circuit breaker threshold.

[0415] In some other embodiments, the adjustment module is further configured to adjust the first weight, the second weight, and the third weight using a linear regression model according to a first time interval.

[0416] It should be noted that the timeout determination device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0417] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 10 As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0418] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0419] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0420] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0421] As one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the timeout determination method provided in the embodiments of this application.

[0422] In another possible implementation, memory 91 can also be integrated with processor 92.

[0423] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0424] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0425] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described timeout determination method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0426] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0427] This application also provides a readable storage medium storing a program or instructions that, when executed by a computer, implement the timeout determination method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; the readable storage medium can be any of the foregoing embodiments or memory; the readable storage medium can also be an external storage device of the service invocation device, such as a pluggable hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, flash card, etc., equipped on the service invocation device. Further, the readable storage medium can include both internal storage units of the service invocation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the service invocation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0428] This application also provides a computer program product, which is stored in a storage medium and, when executed by a computer, implements the timeout determination method provided in the above embodiments.

[0429] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0430] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0431] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.< / string> < / string> < / calldata> < / calldata> < / calldata> < / callcontext>

Claims

1. A method for determining timeout duration, characterized in that, include: Retrieve call data from the N most recent calls to the distributed service; The call data includes: call response time, call result, percentage of active threads in the thread pool, and call frequency load; a call result is used to represent any of the following: call successful, call timeout failure; N is a positive integer; The real-time load coefficient is determined based on the percentage of active threads in the thread pool and the call frequency load. The response time fluctuation coefficient is determined based on the standard deviation of the call response time and the average value of the call response time; The timeout failure rate is determined based on the number of timeout failures in the call results. The timeout period for the distributed service is determined based on the real-time load coefficient, the response time fluctuation coefficient, and the timeout failure rate.

2. The method for determining timeout period according to claim 1, characterized in that, The determination of the real-time load coefficient based on the percentage of active threads in the thread pool and the call frequency load includes: The active thread percentage of the thread pool is weighted to obtain the first active thread percentage of the thread pool. The call frequency load is weighted to obtain the first call frequency load; The sum of the percentage of active threads in the first thread pool and the load of the first call frequency is determined as the real-time load coefficient.

3. The method for determining timeout period according to claim 1, characterized in that, The determination of the response time fluctuation coefficient based on the standard deviation and the average value of the call response time includes: The ratio of the standard deviation of the call response time to the average value of the call response time is determined as the response time fluctuation coefficient.

4. The method for determining timeout period according to claim 1, characterized in that, The determination of the timeout failure rate based on the number of timeout failures in the call results includes: The timeout failure rate is determined by the ratio of the number of timeout failures in the call results to the total number of calls to the distributed service.

5. The method for determining timeout period according to claim 1, characterized in that, The determination of the timeout period for the distributed service based on the real-time load coefficient, the response time fluctuation coefficient, and the timeout failure rate includes: The product of the base timeout, the compensation time, and the adjustment factor is determined as the timeout time corresponding to the distributed service. Wherein, the adjustment factor is the sum of the first parameter, the second parameter, and the third parameter; the first parameter is the product of the real-time load coefficient and the first weight; the second parameter is the product of the response time fluctuation coefficient and the second weight; the third parameter is the product of the timeout failure rate and the third weight; the basic timeout time is determined based on the historical response time of the distributed service; and the compensation time is determined based on the average latency of the network where the electronic device is located and the service reservation time of the distributed service.

6. The method for determining timeout period according to claim 5, characterized in that, Before determining the timeout time corresponding to the distributed service by multiplying the base timeout time, the compensation time, and the adjustment factor, the method further includes: If the timeout failure rate is greater than or equal to the circuit breaker threshold, the base timeout time is adjusted using a first value.

7. The method for determining timeout period according to claim 5 or 6, characterized in that, The method further includes: According to the first time interval, the first weight, the second weight, and the third weight are adjusted using a linear regression model.

8. A timeout determination device, characterized in that, include: Get the module and determine the module; The acquisition module is used to acquire call data from the most recent N calls to the distributed service; The call data includes: call response time, call result, percentage of active threads in the thread pool, and call frequency load; a call result is used to represent any of the following: call successful, call timeout failure; N is a positive integer; The determining module is used to determine a real-time load coefficient based on the percentage of active threads in the thread pool and the call frequency load; and to determine a response time fluctuation coefficient based on the standard deviation of the call response time and the average value of the call response time; and to determine a timeout failure rate based on the number of timeout failures in the call results; and to determine the timeout time corresponding to the distributed service based on the real-time load coefficient, the response time fluctuation coefficient, and the timeout failure rate.

9. The timeout determination device according to claim 8, characterized in that, The determining module is specifically used to perform weighted processing on the active thread ratio of the thread pool to obtain a first active thread ratio of the thread pool; and to perform weighted processing on the call frequency load to obtain a first call frequency load; and to determine the sum of the first active thread ratio of the thread pool and the first call frequency load as the real-time load coefficient.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the timeout determination method as described in any one of claims 1-7.

11. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a computer, implement the timeout determination method as described in any one of claims 1-7.

12. A computer program product, characterized in that, The computer program product is stored in a storage medium, and when executed by a computer, the computer program product implements the timeout adaptive adjustment method as described in any one of claims 1-7.

Images