A task time consumption estimation method and device
By pre-embedding an SDK in the business backend of the music platform, generating an estimated time consumption request and querying configuration data, the problem of high network and system resource consumption in existing time consumption estimation methods is solved, achieving more efficient task time consumption estimation and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- TENCENT MUSIC ENTERTAINMENT TECH (SHENZHEN) CO LTD
- Filing Date
- 2026-04-22
- Publication Date
- 2026-06-16
Smart Images
Figure CN122220631A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet technology, and in particular to a method and apparatus for estimating task time consumption. Background Technology
[0002] Music platforms offer numerous services, each provided by its respective service provider. When a user engages with a service, the front-end periodically polls the corresponding service provider's back-end. This allows the back-end to calculate the latest estimated time based on the current task's execution time, displaying a countdown or progress percentage to the front-end and enhancing the user experience during the wait. However, the current method of estimating task execution time by periodically polling the service provider's back-end incurs significant costs in terms of network bandwidth and system computing power. Summary of the Invention
[0003] This application provides a method and apparatus for estimating task time, with the aim of reducing the cost of estimating task time for various business units under a music platform.
[0004] To achieve the above objectives, this application provides the following technical solution:
[0005] A method for estimating task duration includes:
[0006] Based on the currently obtained estimated time consumption requests, the corresponding target business scenario is determined; the estimated time consumption requests are generated and pushed based on the SDK pre-embedded in the business party's backend; the target business scenario represents the business scenario of the business party;
[0007] Query the configuration data corresponding to the target business scenario; the configuration data includes historical task duration and duration determination mode;
[0008] Based on the time consumption determination mode and the historical task time consumption, the estimated task time is determined;
[0009] The estimated task time is sent to the business backend so that the business backend can feed back the corresponding estimated task time to the frontend.
[0010] A task time estimation device, comprising:
[0011] The scenario determination unit is used to determine the corresponding target business scenario based on the currently obtained estimated time consumption request; the estimated time consumption request is generated and pushed based on the SDK pre-embedded in the business party's backend; the target business scenario represents the business scenario of the business party;
[0012] The configuration query unit is used to query the configuration data corresponding to the target business scenario; the configuration data includes historical task time consumption and time consumption determination mode;
[0013] A time consumption estimation unit is used to determine the estimated time consumption of a task based on the time consumption determination mode and the historical task time consumption.
[0014] The result feedback unit is used to send the estimated task time to the business backend, so that the business backend can feed back the corresponding estimated task time to the frontend.
[0015] A storage medium comprising a stored program, wherein the program is executed by a processor to perform the task time estimation method.
[0016] An electronic device includes: a processor, a memory, and a bus; the processor and the memory are connected via the bus.
[0017] The memory is used to store the program, and the processor is used to run the program, wherein the program is executed by the processor to perform the task time estimation method.
[0018] The technical solution provided in this application determines the corresponding target business scenario based on the currently obtained estimated time request; queries the configuration data corresponding to the target business scenario, including historical task time and time determination mode; determines the estimated task time based on the time determination mode and historical task time; and sends the estimated task time to the business backend, so that the business backend can feed back the corresponding estimated task time to the frontend. This application, based on the estimated time request pushed by the SDK pre-embedded in the business backend, queries the configuration data corresponding to the target business scenario to determine the estimated task time, which can effectively reduce the task time estimation cost for the business. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is a first flowchart illustrating a task time estimation method provided in an embodiment of this application;
[0021] Figure 2 This is a second flowchart illustrating a task time estimation method provided in an embodiment of this application.
[0022] Figure 3 A schematic diagram of the third process of a task time estimation method provided in an embodiment of this application;
[0023] Figure 4A schematic diagram of the fourth process of a task time estimation method provided in an embodiment of this application;
[0024] Figure 5 A fifth flowchart illustrating a task time estimation method provided in an embodiment of this application;
[0025] Figure 6 A schematic diagram illustrating a business party maintenance approach provided in this application embodiment;
[0026] Figure 7 This application provides a schematic diagram of a service provider's periodic update process.
[0027] Figure 8 A schematic diagram of a service provider maintenance approach provided in this application embodiment;
[0028] Figure 9 This is a schematic diagram of the architecture of a task time estimation device provided in an embodiment of this application. Detailed Implementation
[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0030] In this application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. 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 limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0031] like Figure 1 The diagram shown is a first flowchart of a task time estimation method provided in an embodiment of this application, which includes the following steps.
[0032] S101: Based on the currently obtained estimated time-consuming requests, determine the corresponding target business scenario.
[0033] Among them, the estimated time-consuming request is generated and pushed based on the SDK pre-embedded in the business backend; the target business scenario represents the business scenario of the business party.
[0034] In some examples, backends from different business units can share the same SDK. This standardized SDK reduces the cost of task time estimation for business units, provides a unified interface specification, and improves code reusability. The SDK provides capabilities including requesting the estimated time of the currently executing task, providing feedback on the task time estimation results (such as countdown, progress percentage), and reporting the task pipeline information of the currently executing task.
[0035] S102: Query the configuration data corresponding to the target business scenario.
[0036] The configuration data includes historical task duration and duration determination mode.
[0037] In some examples, the configuration database stores configuration data for various business scenarios in real time. After determining the target business scenario, the configuration database can be queried to obtain the configuration data corresponding to the target business scenario.
[0038] It should be noted that the backend systems of different business units are not the same. Some business units have complete time recording functions in their backends, which can be used to obtain the historical task time of the business unit's past tasks by accessing the database tables of the business unit's backend. Other business units do not have time recording functions in their backends or their task execution process is closed to the outside world, so it is not possible to directly access the business unit's backend to obtain the historical task time.
[0039] Therefore, the methods for querying configuration data differ depending on the type of business backend. Optionally, the query process for configuration data for different types of business backends can be found in [link to relevant documentation]. Figure 2 and Figure 3 The steps are shown.
[0040] S103: Determine the estimated time of a task based on the time consumption determination mode and historical task time consumption.
[0041] Among them, the time consumption determination mode can determine how to use the historical task consumption time to calculate the estimated task consumption time.
[0042] Optionally, the process of determining the estimated task time based on the time determination mode and historical task time includes: if the time determination mode is to reuse the most recent historical value, the estimated task time is determined based on the target historical task time that occurred latest among multiple historical task times; if the time determination mode is to calculate the average value, the estimated task time is determined based on the average value of multiple historical task times; if the time determination mode is to calculate the 90th percentile, the estimated task time is determined based on the 90th percentile of multiple historical task times.
[0043] In some examples, the estimated task time is determined based on the average of multiple historical task time records, which can also be regarded as an average time strategy applied to short-term tasks. Since short-term tasks usually have a short duration and are easily affected by temporary factors such as network fluctuations and system load, the reasons for adopting an average time strategy for short-term tasks include: (1) the impact of outliers on the average value of short-term tasks is relatively small; (2) users are more sensitive to the expectations of short-term tasks, and the average value is more in line with psychological expectations; (3) to avoid the estimated time being too long due to individual abnormal tasks, which would affect the user experience.
[0044] In some examples, the 90th percentile of the time taken by multiple historical tasks is used to determine the estimated time taken by a task, which can be regarded as a 90th percentile time strategy applied to long-duration tasks. Since long-duration tasks take a long time, users are more concerned about the completion time in most cases. The reasons for adopting a 90th percentile time strategy for long-duration tasks include: (1) Long-duration tasks are more likely to have extreme outliers, and the 90th percentile can effectively filter these outliers; (2) Ensure that 90% of users complete the task within the estimated time, thereby improving user satisfaction; (3) Reserve a certain buffer time to cope with sudden load.
[0045] In another embodiment, if the type of the target business scenario is unknown, the corresponding time consumption determination mode is to use a prediction model.
[0046] Optionally, the process of determining the estimated task time based on the time consumption determination mode and historical task time consumption also includes: if the time consumption determination mode is to use a prediction model, generating a corresponding historical task time consumption time series based on multiple historical task times consumption; inputting the historical task time consumption time series into the time series prediction model to obtain the estimated task time consumption; the time series prediction model is obtained by fitting the sample task time consumption of the target business scenario using a time series prediction algorithm.
[0047] In some examples, the types of time series forecasting models include, but are not limited to, ARIMA models, LSTM models, etc.
[0048] In some examples, if the target business scenario is anomaly monitoring and capacity planning, the estimated task time is usually not directly displayed to the user. The corresponding time determination mode is to calculate the 99th percentile. Therefore, the estimated task time can be determined based on the 99th percentile of multiple historical task time records.
[0049] Generally speaking, determining the estimated time of a task based on the 99th percentile of multiple historical task time records can also be regarded as a 99th percentile time strategy. This 99th percentile time strategy is mainly used to identify the system performance boundary of the business backend and provide data support for scaling decisions.
[0050] S104: Send the estimated task time to the business backend so that the business backend can report the corresponding estimated task time to the frontend.
[0051] Once the latest estimated task time is obtained, it can be sent directly to the SDK on the business side's backend, so that the SDK can feed back the corresponding estimated task time to the frontend. For example, the estimated task time can be displayed on the frontend through a visual screen to improve the user experience, such as a visual countdown or progress percentage.
[0052] In some examples, the operation and maintenance mode of the estimated time management system is usually a passive loop of "user complaint → problem location → problem repair". In order to eliminate the negative effects of the passive loop, an active monitoring and alarm mechanism is introduced into the estimated time management system, realizing the transformation from passive response to active prevention and improving system stability.
[0053] Optionally, the implementation process of the proactive monitoring and alarm mechanism can be found in [reference needed]. Figure 4 The steps are shown.
[0054] In some examples, the task time estimation method shown in the embodiments of this application can be applied to the estimated time management service. Accordingly, the business party accessing this estimated time management service needs to embed the corresponding estimated time SDK in the business party's backend. For this specific implementation scenario, the embodiments of this application can achieve the following: Figure 6 The business party's maintenance guidelines are shown, such as... Figure 7 The service provider shows the process for updating regularly, such as... Figure 8 The service provider's maintenance guidelines are shown.
[0055] In possible implementations Figure 6 The process can be summarized as follows: The business side obtains the estimated time from the estimated time SDK; the estimated time SDK requests the estimated time from the estimated time management service; the estimated time management service queries the Redis cache; the Redis cache returns the cached data to the estimated time management service; the estimated time management service queries the configuration database for configuration data; the configuration database returns the configuration data to the estimated time management service; the estimated time management service updates the cache in the Redis cache; the Redis cache returns the estimated time (i.e., the estimated task time) to the estimated time SDK; the estimated time SDK returns the result to the business side.
[0056] Understandably, the recommended time consumption calculation method for each business unit is simple and effective, requiring only the time from the start to the end of the task, without needing to consider the queuing status of each task execution node within the unit for real-time calculation.
[0057] In possible implementations Figure 7The process can be summarized as follows: the scheduled task triggers an update task to the estimated time management service; the estimated time management service calls the business interface; the business returns the historical task elapsed time to the estimated time management service; the estimated time management service calculates the estimated elapsed time of the new task; the estimated time management service updates the configuration data in the configuration database; and the estimated time management service clears the cache in the Redis cache.
[0058] In possible implementations Figure 8 The process can be summarized as follows: The business-oriented estimated time SDK reports the start of the task; the estimated time SDK reports the start time log to the estimated time management service; the estimated time management service records the start time in the configuration database; the business-oriented estimated time SDK reports the end of the task; the estimated time SDK reports the end time log to the estimated time management service; the estimated time management service records the end time in the configuration database; the scheduled task triggers a scheduled query to the estimated time management service; the estimated time management service queries the configuration database for recent logs; the estimated time management service calculates the estimated time for new tasks; the estimated time management service updates configuration data in the configuration database; and the estimated time management service clears the cache in Redis.
[0059] The processes described in S101-S104 above, based on the estimated time request generated and pushed by the business backend's pre-embedded SDK, determine the target business scenario, query the corresponding configuration data, determine the estimated task time based on the time determination mode and historical task time, and send it back to the business backend to complete the frontend result feedback. This replaces the existing technology's timed polling interaction method, eliminating the need for frequent backend requests, reducing network transmission frequency, and lowering the business backend's network bandwidth consumption. Simultaneously, it eliminates the need for continuous real-time calculations and updates of time consumption by the backend, reducing system computing resource overhead, while ensuring a smooth user experience and effectively overcoming the shortcomings of excessive backend resource consumption in existing technologies.
[0060] like Figure 2 The diagram shown is a second flowchart of a task time estimation method provided in an embodiment of this application, which includes the following steps.
[0061] S201: If the business backend is the first business system, call the corresponding business interface periodically to query the time consumption of multiple historical tasks in the business backend within the target period.
[0062] Specifically, the first business system refers to a business system with complete time recording functionality. The first business system has database tables that record the start and end times of multiple tasks executed by the business party, and provides corresponding business party interfaces to facilitate querying the database tables.
[0063] It is understandable that as business needs change, business parties will proactively and promptly adjust their statements, while this system remains unaffected. For example, a business party providing timbre generation services might expect the estimated timeframe to be from when a user submits materials until they see a pop-up notification indicating the timbre model is complete. However, the business party might adjust its strategy based on their requirements, no longer providing a free sample audio after the user submits materials, but instead directly displaying a pop-up notification that the timbre model is complete. In this case, the business party can adjust its strategy according to their interface (i.e., the interface query criteria).
[0064] In some examples, a pre-created scheduled task can be started to periodically call the corresponding business interface at preset time intervals (e.g., 3 minutes) to access the first business system and query the start and end times of multiple tasks recorded in the database table of the first business system, so as to obtain the time consumption of multiple historical tasks.
[0065] In a possible implementation, the multiple tasks recorded in the database table of the first business system may originate from different user requests.
[0066] In some examples, the target period can be set by technicians according to the actual situation, and the number of historical task times obtained by querying the database table of the first business system can also be set by technicians according to the actual situation. For example, the target period can be set to the most recent 30 minutes, and the number of historical task times can be set to 100. Then, the corresponding business interface can be called periodically to obtain the time consumption of 100 historical tasks in the most recent 30 minutes from the business backend.
[0067] S202: Based on the preset relationship table, determine the time consumption determination mode corresponding to the target business scenario.
[0068] The preset relationship table includes sample time determination modes for different types of business scenarios.
[0069] In some examples, for the first business scenario of short-time task, the corresponding sample time determination mode can be set to calculate the average value. Generally speaking, the processing time of short-time task is less than the preset time threshold.
[0070] In possible implementations, business scenarios belonging to short-time tasks include, but are not limited to: listening to audio, writing lyrics for popular songs, and listening to sound effects. Short-time tasks typically take a short time (e.g., tens of seconds to a few minutes) and are easily affected by temporary factors such as network fluctuations and system load.
[0071] In some examples, for the second business scenario of a long-duration task, the corresponding sample time determination mode can be set to calculate the 90th quantile. Generally speaking, the processing time of a long-duration task is greater than or equal to the preset time threshold.
[0072] In possible implementations, business scenarios belonging to long-duration tasks include, but are not limited to: AI songwriting, MV production, and user voice training.
[0073] S203: Based on the time consumption of multiple historical tasks and combined with the time consumption determination mode, obtain the configuration data corresponding to the target business scenario.
[0074] This involves defining the time consumption and time consumption determination patterns of multiple historical tasks as configuration data corresponding to the target business scenario.
[0075] The processes described in S201-S203 above involve periodically calling the business side's interface to query the historical task execution times of multiple tasks within the target period from the business side's backend. Based on a preset relationship table, the execution time determination pattern corresponding to the target business scenario is determined. Combining the historical task execution times with the execution time determination pattern, the configuration data corresponding to the target business scenario is obtained. This implementation adapts to the operating logic of the first business system, relies on the interface to collect historical task data, and matches the corresponding execution time determination pattern, ensuring the validity and scenario adaptability of the configuration data, and providing data support for reliably determining the estimated task execution time subsequently.
[0076] like Figure 3 The diagram shown is a third flowchart of a task time estimation method provided in an embodiment of this application, which includes the following steps.
[0077] S301: If the business backend is a second business system, record the task log information reported by the SDK in real time.
[0078] The task flow information includes the start and end times of the task currently being executed by the business party.
[0079] It should be noted that the first business system specifically refers to a business system that does not have complete time recording capabilities. The second business system can be considered a lightweight or third-party service-based business system. During task execution, the second business system is closed to the outside world, and external parties cannot query the specific execution status of the tasks. A standardized interface can be provided to the second business system. This standardized interface is deployed in the SDK, allowing the SDK to periodically report the task log information of the second business system through this standardized interface.
[0080] In some examples, the task pipeline information includes the pipeline start time and pipeline end time, but does not involve the specific execution status of the task.
[0081] S302: Periodically query the business unit's historical task flow information within the target period.
[0082] Among them, pre-created scheduled tasks can be started to query the business party's historical task flow information within the target period at preset time intervals (e.g., 3 minutes).
[0083] In some examples, the target period can be set by technicians according to the actual situation, and the number of historical task log information records to be queried locally can also be set by technicians according to the actual situation. For example, the target period can be set to the most recent 30 minutes, and the number of historical task log information records can be set to 100, so that 100 historical task log information records of the business party in the most recent 30 minutes can be queried periodically.
[0084] S303: Determine the time consumption of multiple historical tasks based on the pipeline information of multiple historical tasks.
[0085] Among them, the time difference between the start time and end time of the flow shown in the flow information of multiple historical tasks can be used to calculate the time consumption of the corresponding multiple historical tasks.
[0086] S304: Based on a preset relationship table, determine the time consumption determination mode corresponding to the target business scenario.
[0087] The preset relationship table includes sample time determination modes for different types of business scenarios.
[0088] S305: Based on the time consumption of multiple historical tasks and combined with the time consumption determination mode, obtain the configuration data corresponding to the target business scenario.
[0089] This involves defining the time consumption and time consumption determination patterns of multiple historical tasks as configuration data corresponding to the target business scenario.
[0090] The processes described in S301-S305 above record the task flow information reported by the SDK in real time, periodically query the flow information of multiple historical tasks within the target period, determine the time consumption of multiple historical tasks, determine the time consumption determination mode corresponding to the target business scenario based on a preset relationship table, and obtain the configuration data corresponding to the target business scenario by combining the time consumption of multiple historical tasks with the time consumption determination mode. By generating configuration data based on real historical task data and strictly matching the time consumption determination mode corresponding to the scenario, the scenario adaptability and accuracy of the configuration data are ensured, providing effective data support for accurately calculating the estimated task time consumption.
[0091] like Figure 4 The diagram shown is a fourth flowchart of a task time estimation method provided in an embodiment of this application, which includes the following steps.
[0092] S401: Obtain the estimated time consumption of multiple historical tasks corresponding to the target business scenario.
[0093] The configuration database includes multiple historical task estimated time consumptions corresponding to the target business scenario. Therefore, multiple historical task estimated time consumptions can be directly obtained from the configuration database. The so-called historical task estimated time consumption can be understood as the task estimated time consumption obtained according to a preset period within a historical time.
[0094] S402: Determine the results of multidimensional analysis based on the estimated time consumption of multiple historical tasks.
[0095] The multidimensional analysis results include year-on-year analysis, month-on-month analysis, and trend analysis. Year-on-year analysis is used to quantify the long-term trend of the estimated task time, month-on-month analysis is used to quantify the short-term fluctuations of the estimated task time, and trend analysis is used to quantify the changing trends and anomalies of the estimated task time.
[0096] Optionally, the estimated time for multiple historical tasks includes at least a first time and a second time; the first time includes the estimated time for historical tasks belonging to the same time period as the estimated time for tasks determined in the current period; the second time includes the estimated time for historical tasks corresponding to the previous period.
[0097] Optionally, based on the estimated time consumption of multiple historical tasks, the results of the multidimensional analysis can be found in [reference needed]. Figure 5 The steps are shown.
[0098] S403: Based on year-on-year analysis results, month-on-month analysis results, and trend analysis results, combined with preset alarm threshold conditions, identify abnormal objects and their corresponding degrees of abnormality.
[0099] The alarm threshold conditions corresponding to the year-on-year analysis results, month-on-month analysis results, and trend analysis results can be set by technical personnel according to the actual situation. For example, the alarm threshold condition corresponding to the year-on-year analysis results can be a year-on-year increase of more than 30%, and the alarm threshold condition corresponding to the month-on-month analysis results can be a month-on-month increase of more than 20%, etc.
[0100] It is understood that abnormal objects include any one or more of the year-on-year analysis results, month-on-month analysis results, and trend analysis results that meet the corresponding alarm threshold conditions. If the year-on-year analysis result meets the corresponding alarm threshold conditions, then the abnormal object is the year-on-year analysis result. If both the month-on-month analysis result and the trend analysis result meet the corresponding alarm threshold conditions, then the abnormal object includes both the month-on-month analysis result and the trend analysis result.
[0101] In some examples, the degree of abnormality of an abnormal object can be the value of the abnormal object, or the difference between the value of the abnormal object and the threshold indicated by the corresponding alarm threshold condition. For example, if the abnormal object is the year-on-year analysis result, the value of the abnormal object is 55%, and the threshold indicated by the alarm threshold condition is 30%, then the degree of abnormality can be 25%.
[0102] S404: Determine the corresponding abnormal alarm channel based on the alarm level corresponding to the degree of abnormality.
[0103] The system allows users to query a preset alarm level table to obtain the alarm level corresponding to the degree of anomaly, and combine this with the alarm channel table to find the corresponding abnormal alarm channel. Generally speaking, the alarm level table contains reference values for the degree of anomaly corresponding to different alarm levels, and the alarm channel table contains the alarm channels corresponding to different alarm levels.
[0104] In some examples, different alerting channels include WeChat Work bots, email notifications, SMS notifications, and WeBook notifications. Specifically, WeChat Work bots are used to push alert information in real time for rapid response; email notifications are used to send detailed alert reports, including data analysis and processing suggestions; SMS notifications are used for emergency notifications of critical alerts; and WeBook notifications are used to support customized alert handling processes.
[0105] S405: Publish alarm information for abnormal objects using the abnormal alarm channel according to the preset frequency limit.
[0106] The preset frequency limit is used to control the number of times the same type of alarm information is issued within a unit of time.
[0107] In some examples, preset frequency limits can be set by technicians according to the actual situation, such as sending the same type of alarm message only once per hour to avoid duplicate notifications.
[0108] The processes described in S401-S405 above acquire the estimated time consumption of multiple historical tasks corresponding to the target business scenario, determine multi-dimensional analysis results including year-on-year, month-on-month, and trend analysis results, comprehensively quantify the long-term changes, short-term fluctuations, and anomalies in time consumption, identify abnormal objects and their severity based on preset alarm threshold conditions, determine the abnormal alarm channels according to the alarm level corresponding to the severity of the anomaly, and release alarm information according to preset frequency limits. This process can accurately identify time consumption anomalies, reasonably push alarms in a tiered manner, control the number of alarm releases by relying on frequency limits, reduce redundant alarms, and improve the monitoring and handling efficiency of abnormal task estimated time consumption.
[0109] like Figure 5 The diagram shown is a fifth flowchart of a task time estimation method provided in an embodiment of this application, which includes the following steps.
[0110] S501: Generate year-on-year analysis results based on the comparison between the first time spent and the estimated time spent on the task.
[0111] Among them, the year-on-year analysis results can characterize the most recently updated task estimated time and compare it with the historical task estimated time in the same period last year to identify long-term trend changes. For example, the average time of AI songwriting tasks in the same period this year has increased by 30% compared with last year, which may mean that the algorithm efficiency has decreased or resources are insufficient.
[0112] S502: Generate a month-on-month analysis result based on the comparison between the second time consumption and the estimated time consumption of the task.
[0113] Among them, the month-on-month analysis results can characterize the estimated time of historical tasks determined in the current period, and compare it with the estimated time of historical tasks corresponding to the previous period (such as last week or last month) to promptly identify short-term fluctuations. For example, the estimated time of historical tasks for the audio-visual service this week has increased by 50% compared to last week, which may be due to the recent high system load.
[0114] S503: Utilize time series analysis algorithms to analyze the estimated time consumption of multiple historical tasks in order to obtain trend analysis results.
[0115] Among these methods, time-series algorithms are used to identify trends and abnormal fluctuations in the estimated time consumption of multiple historical tasks. Furthermore, machine learning algorithms can predict future changes in time consumption, enabling proactive capacity planning.
[0116] The processes described in S501-S503 above, based on the comparison of the first and second time consumption periods with the estimated task consumption periods, generate year-on-year and month-on-month analysis results. Time series analysis algorithms are used to analyze the estimated consumption periods of multiple historical tasks, thereby obtaining trend analysis results. This process relies on differentiated data comparison and professional algorithm calculations to standardize the generation of multi-dimensional analysis results, ensuring the accuracy and objectivity of each analysis result, and providing a standardized and effective analytical basis for subsequent anomaly identification and alarm determination.
[0117] like Figure 9 The diagram shown is a schematic representation of the architecture of a task time estimation device provided in an embodiment of this application, which includes the following units.
[0118] The scenario determination unit 100 is used to determine the corresponding target business scenario based on the currently obtained estimated time-consuming request; the estimated time-consuming request is generated and pushed based on the SDK pre-embedded in the business party's backend; the target business scenario represents the business scenario of the business party.
[0119] The configuration query unit 200 is used to query the configuration data corresponding to the target business scenario; the configuration data includes historical task time and time determination mode.
[0120] Optionally, the configuration query unit 200 is specifically used for: if the business backend is a first business system, periodically calling the corresponding business interface to query the historical task consumption time of the business backend within the target period; determining the consumption time determination mode corresponding to the target business scenario based on a preset relationship table; the preset relationship table includes sample consumption time determination modes corresponding to different business scenarios; and obtaining the configuration data corresponding to the target business scenario based on the historical task consumption time and the consumption time determination mode.
[0121] Optionally, the configuration query unit 200 is specifically used for: if the business party's backend is a second business system, recording the task flow information reported by the SDK in real time; the task flow information includes the flow start time and flow end time of the task currently being executed by the business party; periodically querying multiple historical task flow information of the business party within the target period; determining the time consumption of multiple historical tasks based on the multiple historical task flow information; determining the time consumption determination mode corresponding to the target business scenario based on a preset relationship table; the preset relationship table includes sample time consumption determination modes corresponding to different business scenarios; and obtaining the configuration data corresponding to the target business scenario based on the multiple historical task times and the time consumption determination mode.
[0122] The time estimation unit 300 is used to determine the estimated time of a task based on the time determination mode and the historical task time.
[0123] Optionally, the time estimation unit 300 is specifically used for: if the time determination mode is to reuse the most recent historical value, determining the estimated task time based on the target historical task time that occurred latest among the multiple historical task times; if the time determination mode is to calculate the average value, determining the estimated task time based on the average value of the multiple historical task times; if the time determination mode is to calculate the 90th percentile, determining the estimated task time based on the 90th percentile of the multiple historical task times.
[0124] Optionally, the time estimation unit 300 is further configured to: if the time determination mode is to use a prediction model, generate a corresponding historical task time series based on the multiple historical task times; input the historical task time series into the time series prediction model to obtain the estimated task time; the time series prediction model is obtained by fitting the sample task times of the target business scenario using a time series prediction algorithm.
[0125] The result feedback unit 400 is used to send the estimated task time to the business backend, so that the business backend can feed back the corresponding estimated task time to the frontend.
[0126] The anomaly alarm unit 500 is used to: acquire the estimated time consumption of multiple historical tasks corresponding to the target business scenario; determine multi-dimensional analysis results based on the estimated time consumption of multiple historical tasks; the multi-dimensional analysis results include year-on-year analysis results, month-on-month analysis results, and trend analysis results; the year-on-year analysis results are used to quantify the long-term trend changes of the estimated task time consumption, the month-on-month analysis results are used to quantify the short-term fluctuations of the estimated task time consumption, and the trend analysis results are used to quantify the changing trends and anomalies of the estimated task time consumption; based on the year-on-year analysis results, month-on-month analysis results, and trend analysis results, combined with preset alarm threshold conditions, identify abnormal objects and their corresponding degrees of abnormality; determine the corresponding anomaly alarm channel based on the alarm level corresponding to the degree of abnormality; and publish alarm information of the abnormal objects using the anomaly alarm channel according to preset frequency limits; the preset frequency limits are used to control the number of times the same type of alarm information is published within a unit of time.
[0127] Optionally, the estimated time for multiple historical tasks includes a first time and a second time; the first time includes the estimated time for historical tasks belonging to the same time period as the estimated time for tasks determined in the current period; the second time includes the estimated time for historical tasks corresponding to the previous period.
[0128] The anomaly alarm unit 500 is specifically used to: generate year-on-year analysis results based on the comparison between the first time consumption and the estimated time consumption of the task; generate month-on-month analysis results based on the comparison between the second time consumption and the estimated time consumption of the task; and analyze the estimated time consumption of multiple historical tasks using time series analysis algorithms to obtain trend analysis results.
[0129] The device described above determines the target business scenario based on the estimated time request pushed by the business's backend SDK, adapts to different business systems to obtain configuration data, calculates the estimated task time based on multiple time determination modes, and pushes the results. It identifies time-consuming anomalies through multi-dimensional analysis and issues tiered alerts and limits the push frequency. This device avoids the drawbacks of frontend periodic polling, reduces the bandwidth and computing consumption of the business's backend, accurately estimates task time, and achieves standardized monitoring and control of time-consuming anomalies.
[0130] This application also provides a computer-readable storage medium including a stored program, wherein the program executes the task time estimation method provided in this application.
[0131] This application also provides an electronic device, including a processor, a memory, and a bus. The processor and the memory are connected via the bus. The memory is used to store a program, and the processor is used to run the program. During program execution, the task time estimation method provided in this application is executed.
[0132] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.
[0133] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.
Claims
1. A method for estimating task time consumption, characterized in that, include: Based on the currently obtained estimated request time, determine the corresponding target business scenario; The estimated time consumption request is generated and pushed based on the SDK pre-embedded in the business backend; The target business scenario represents the business scenario of the business party; Query the configuration data corresponding to the target business scenario; the configuration data includes historical task duration and duration determination mode; Based on the time consumption determination mode and the historical task time consumption, the estimated task time is determined; The estimated task time is sent to the business backend so that the business backend can feed back the corresponding estimated task time to the frontend.
2. The method according to claim 1, characterized in that, Query the configuration data corresponding to the target business scenario, including: If the business backend is the first business system, the corresponding business interface is called periodically to query the time consumption of multiple historical tasks of the business backend within the target period. Based on a preset relationship table, the time consumption determination mode corresponding to the target business scenario is determined; the preset relationship table includes sample time consumption determination modes corresponding to different types of business scenarios. Based on the time consumption of the multiple historical tasks and the time consumption determination mode, the configuration data corresponding to the target business scenario is obtained.
3. The method according to claim 1, characterized in that, Query the configuration data corresponding to the target business scenario, including: If the backend of the business party is a second business system, the task flow information reported by the SDK is recorded in real time; the task flow information includes the flow start time and flow end time of the task currently being executed by the business party. Periodically query the historical task flow information of the business party within the target period; Based on the aforementioned historical task flow information, the time consumption of multiple historical tasks is determined; Based on a preset relationship table, the time consumption determination mode corresponding to the target business scenario is determined; the preset relationship table includes sample time consumption determination modes corresponding to different types of business scenarios. Based on the time consumption of the multiple historical tasks and the time consumption determination mode, the configuration data corresponding to the target business scenario is obtained.
4. The method according to any one of claims 2 and 3, characterized in that, Based on the time consumption determination mode and the historical task time consumption determination task estimated time, including: If the time consumption determination mode is to reuse the most recent historical value, the time consumption of the target historical task that occurred latest among the multiple historical task times is determined as the estimated task time consumption. If the time consumption determination mode is to calculate the average value, the estimated task time is determined based on the average value of the time consumption of the multiple historical tasks. If the time consumption determination mode is to calculate the 90th percentile, the estimated time consumption of the task is determined based on the 90th percentile of the time consumption of the multiple historical tasks.
5. The method according to claim 4, characterized in that, The method further includes: If the time consumption determination mode is to use a prediction model, a corresponding historical task time consumption time series is generated based on the time consumption of the multiple historical tasks; The historical task time series is input into the time series prediction model to obtain the estimated task time; the time series prediction model is obtained by fitting the sample task time of the target business scenario using a time series prediction algorithm.
6. The method according to claim 1, characterized in that, The method further includes: Obtain the estimated time consumption of multiple historical tasks corresponding to the target business scenario; Based on the estimated time consumption of the multiple historical tasks, multidimensional analysis results are determined; the multidimensional analysis results include year-on-year analysis results, month-on-month analysis results, and trend analysis results; the year-on-year analysis results are used to quantify the long-term trend changes of the estimated task time consumption, the month-on-month analysis results are used to quantify the short-term fluctuations of the estimated task time consumption, and the trend analysis results are used to quantify the changing trends and anomalies of the estimated task time consumption. Based on the year-on-year analysis results, the month-on-month analysis results, and the trend analysis results, combined with preset alarm threshold conditions, abnormal objects and their corresponding degrees of abnormality are identified. Based on the alarm level corresponding to the degree of anomaly, determine the corresponding anomaly alarm channel; According to the preset frequency limit, the alarm information of the abnormal object is published using the abnormal alarm channel; the preset frequency limit is used to control the number of times the same type of alarm information is published within a unit of time.
7. The method according to claim 6, characterized in that, The estimated time for the multiple historical tasks includes a first time and a second time; the first time includes the estimated time for historical tasks belonging to the same time period as the estimated time for tasks determined in the current period; the second time includes the estimated time for historical tasks corresponding to the previous period. Based on the estimated time consumption of the aforementioned historical tasks, the results of the multidimensional analysis are determined, including: The year-on-year analysis results are generated based on the comparison between the first time spent and the estimated time spent on the task. The month-on-month analysis results are generated based on the comparison between the second time consumption and the estimated time consumption of the task. The time series analysis algorithm is used to analyze the estimated time consumption of the multiple historical tasks to obtain the trend analysis results.
8. A task time estimation device, characterized in that, include: The scenario determination unit is used to determine the corresponding target business scenario based on the currently obtained estimated time-consuming requests; The estimated time consumption request is generated and pushed based on the SDK pre-embedded in the business backend; The target business scenario represents the business scenario of the business party; A configuration query unit is used to query the configuration data corresponding to the target business scenario; the configuration data includes historical task time consumption and time consumption determination mode; A time consumption estimation unit is used to determine the estimated time consumption of a task based on the time consumption determination mode and the historical task time consumption. The result feedback unit is used to send the estimated task time to the business backend, so that the business backend can feed back the corresponding estimated task time to the frontend.
9. A storage medium, characterized in that, The storage medium includes a stored program, wherein the program is executed by a processor to perform the task time estimation method according to any one of claims 1-7.
10. An electronic device, characterized in that, include: Processor, memory, and bus; The processor and the memory are connected via the bus; The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the task time estimation method according to any one of claims 1-7.