Application startup self-preheating method, device, apparatus and storage medium

Abstract

This application discloses an application startup self-preheating method, apparatus, device, and storage medium, relating to the field of application preheating technology. The method involves acquiring the interface contract data of a target application, parsing the parameter structure information and business constraint rules in the interface contract data; acquiring historical request traffic data of the target application and performing semantic analysis to determine the traffic intent profile of the target application; performing parameter mutation processing on the historical request traffic data according to the business constraint rules and traffic intent profile to generate mutated traffic data for the target application; monitoring the startup status of the target application, and when the startup of the target application is detected, extracting preheating request data from the mutated traffic data according to an orchestration strategy and sending the preheating request data to the target application; receiving the execution result data of the target application based on the preheating request data, and generating an application self-preheating report. The parameter mutation processing expands the coverage of preheating traffic, improving the comprehensiveness of application startup self-preheating.

Description

Technical Field

[0001] This application relates to the field of application startup technology, and in particular to application startup self-preheating methods, apparatus, devices and storage media. Background Technology

[0002] With the widespread adoption of microservice architecture, application systems need to complete a large amount of initialization work during the startup phase, including cache loading, database connection pool establishment, and thread pool warm-up. The quality of these tasks directly affects the service response performance after application startup. Currently, the industry commonly uses manually written warm-up code to solve the application startup warm-up problem. Specifically, developers use their experience to determine which modules need warm-up and write warm-up code for each module individually. For example, they write cache warm-up logic to preload hot data and database connection warm-up logic to establish initial connections. After completing the coding, they manually test to verify the warm-up effect and adjust and optimize the warm-up code based on the test results. However, the above-mentioned method of manually writing warm-up code has obvious limitations in practical applications: because there are many warm-up stages scattered across various service modules, relying entirely on manual identification can easily lead to the omission of key warm-up nodes, resulting in some modules remaining in a cold state after application startup, which in turn causes response delays or even service anomalies, and cannot effectively guarantee the comprehensiveness and stability of the warm-up effect.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide an application startup self-preheating method, apparatus, device, and storage medium, aiming to solve the technical problem of insufficient comprehensiveness of application startup self-preheating.

[0005] To achieve the above objectives, this application proposes an application-based self-preheating method, the method comprising: Obtain the interface contract data of the target application, and parse the parameter structure information and business constraint rules in the interface contract data; Obtain historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application; Based on the business constraint rules and the traffic intent profile, the historical request traffic data is subjected to parameter mutation processing to generate the mutated traffic data of the target application; Monitor the startup status of the target application. When the startup of the target application is detected, extract warm-up request data from the mutated traffic data according to the preset orchestration strategy and send the warm-up request data to the target application. Receive the execution result data of the target application based on the preheating request data, and generate an application self-preheating report based on the execution result data.

[0006] In one embodiment, the parameter structure information includes parameter type declarations and input parameter object structures, and the step of obtaining the interface contract data of the target application includes: The source code of the target application is scanned using static code analysis tools to extract parameter type declarations and business constraint rules from the interface definition files of the source code. The structure of the input parameter object of the interface method is dynamically obtained through runtime reflection mechanism. The parameter type declaration, the structure of the input parameter object and the business constraint rules are integrated to generate interface contract data.

[0007] In one embodiment, the step of performing semantic analysis on the historical request traffic data to determine the traffic intent profile of the target application includes: Extract request parameter values ​​from the historical request traffic data, and identify business scenario identifiers based on the matching results of the parameter values ​​and the preset business semantic dictionary; Based on the business scenario identifier, the historical request traffic data is clustered to generate traffic intent clusters under the corresponding business scenario category; Based on the traffic intent clusters and the corresponding target interface paths, a traffic intent profile of the target application is constructed.

[0008] In one embodiment, the step of performing parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile to generate mutated traffic data for the target application includes: Based on the business constraint rules, the boundary combination data corresponding to the traffic intent clusters of the traffic intent profile are identified; The boundary combination data and the traffic intent cluster are fused to generate the variant traffic data of the target application.

[0009] In one embodiment, the step of extracting warm-up request data from the variable traffic data according to a preset orchestration strategy and sending the warm-up request data to the target application includes: An interface call chain graph is constructed based on distributed tracing data to identify the service dependencies and call order within the target application. The variable traffic data is topologically sorted according to the calling order to determine the service-level preheating priority sequence; Preheating request data is extracted from the variable traffic data in batches according to the preheating priority sequence, and the preheating request data is sent to the target application based on the service dependency relationship.

[0010] In one embodiment, the step of sending the warm-up request data to the target application further includes: Real-time acquisition of resource usage status data of the target application, and calculation of the target deviation value between the resource usage status data and the preset resource threshold; The concurrent sending of the preheating request data is dynamically adjusted based on the target deviation value using a feedback control algorithm.

[0011] In one embodiment, the step of receiving the execution result data of the target application based on the preheating request data, and generating an application self-preheating report based on the execution result data, includes: Extract response time data from the execution result data, perform response trend analysis based on the response time data, and generate preheating effect evaluation data; Based on the degree of deviation between the preheating effect evaluation data and the expected performance target, adjust the generation rules of the boundary combination data and the weight configuration of the preheating priority sequence; Based on the preheating effect evaluation data, the adjusted generation rules, and the weight configuration, the application self-preheating report is generated.

[0012] Furthermore, to achieve the above objectives, this application also proposes an application startup self-preheating device, which includes: The data parsing module is used to obtain the interface contract data of the target application and parse the parameter structure information and business constraint rules in the interface contract data. The profile determination module is used to acquire historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application. The data generation module is used to perform parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile, and generate the mutated traffic data of the target application. The request sending module is used to monitor the startup status of the target application. When the startup of the target application is detected, the module extracts warm-up request data from the mutated traffic data according to the preset orchestration strategy and sends the warm-up request data to the target application. The report generation module is used to receive the execution result data of the target application based on the preheating request data, and generate an application self-preheating report based on the execution result data.

[0013] In addition, to achieve the above objectives, this application also proposes an application startup self-warming device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the application startup self-warming method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the application startup self-warm-up method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the application startup self-warm-up method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes an application startup self-preheating method, apparatus, device, and storage medium. The method involves acquiring interface contract data of a target application, parsing the parameter structure information and business constraint rules within the interface contract data, acquiring historical request traffic data of the target application, performing semantic analysis on the historical request traffic data to determine the traffic intent profile of the target application, performing parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile to generate mutated traffic data of the target application, monitoring the startup status of the target application, and when the startup of the target application is detected, extracting preheating request data from the mutated traffic data according to a preset orchestration strategy and sending the preheating request data to the target application, receiving execution result data of the target application based on the preheating request data, and generating an application self-preheating report based on the execution result data. The parameter mutation processing expands the coverage of preheating traffic, improving the comprehensiveness of application startup self-preheating. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the self-preheating method implementation method of this application is provided in Embodiment 1. Figure 2 A simplified flowchart illustrating the application startup self-warming method provided in this application embodiment; Figure 3This is a schematic diagram of the module structure of the self-heating device applied in an embodiment of this application; Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the application of the self-heating method in this embodiment of the application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: Obtain the interface contract data of the target application, and parse the parameter structure information and business constraint rules in the interface contract data; obtain the historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application; perform parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile to generate mutated traffic data of the target application; monitor the startup status of the target application, and when the startup of the target application is detected, extract preheating request data from the mutated traffic data according to a preset orchestration strategy and send the preheating request data to the target application; receive the execution result data of the target application based on the preheating request data, and generate an application self-preheating report based on the execution result data.

[0024] In this embodiment, for ease of description, the following description will focus on the application-start self-preheating device.

[0025] With the widespread adoption of microservice architecture, application systems need to complete a large amount of initialization work during the startup phase, including cache loading, database connection pool establishment, and thread pool warm-up. The quality of these tasks directly affects the service response performance after application startup. Currently, the industry commonly uses manually written warm-up code to solve the application startup warm-up problem. Specifically, developers use their experience to determine which modules need warm-up and write warm-up code for each module individually. For example, they write cache warm-up logic to preload hot data and database connection warm-up logic to establish initial connections. After completing the coding, they manually test to verify the warm-up effect and adjust and optimize the warm-up code based on the test results. However, the above-mentioned method of manually writing warm-up code has obvious limitations in practical applications: because there are many warm-up stages scattered across various service modules, relying entirely on manual identification can easily lead to the omission of key warm-up nodes, resulting in some modules remaining in a cold state after application startup, which in turn causes response delays or even service anomalies, and cannot effectively guarantee the comprehensiveness and stability of the warm-up effect.

[0026] This application provides a solution that expands the coverage of preheating flow through parameter variation processing, thereby improving the comprehensiveness of application startup self-preheating.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or application startup self-preheating system capable of the above functions. The following description uses an application startup self-preheating system as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide an application startup self-preheating method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the self-preheating method for applying this application.

[0029] In this embodiment, the application startup self-preheating method includes steps S11 to S15: Step S11: Obtain the interface contract data of the target application, and parse the parameter structure information and business constraint rules in the interface contract data.

[0030] It should be noted that interface contract data refers to structured data describing the input and output specifications of an application interface, typically including information such as the interface path, request method, parameter definitions, and return value types; parameter structure information refers to metadata such as the data type, field hierarchy, and nesting relationship of interface request parameters, used to describe the organization of the parameters; business constraint rules refer to the restrictive conditions on the values ​​of interface parameters, including validation rules such as numerical range, string length, enumeration value list, and regular expression format, used to ensure that the parameters meet the business logic requirements.

[0031] Understandably, this step establishes an automated cognitive ability of the target application interface specifications by acquiring and parsing interface contract data. This allows the system to grasp the parameter rules required for warm-up without manual analysis of each interface, thus solving the problem of omissions caused by the large number of interfaces when manually identifying warm-up nodes. This lays the data foundation for subsequent automated traffic generation based on contract constraints.

[0032] Specifically, obtaining interface contract data can be achieved through the following methods: The first method involves parsing the open interface specification documents exposed by the target application (such as Swagger-formatted JSON or YAML files) to extract the interface paths and parameter structure definitions. This method is suitable for applications that provide standard interface documentation. The second method involves scanning the annotation configuration of the target application framework (such as Spring framework's request mapping annotations and request body annotations) to extract interface metadata from the compiled bytecode or source code. This method is suitable for annotation-based web frameworks. The third method involves intercepting the target application's runtime requests and dynamically extracting the object structure of request parameters based on reflection. This method is suitable for legacy systems that do not provide static documentation. During the parsing process, for parameter structure information, nested objects (such as object types in JSON) need to be processed recursively, recording the name, type, and whether each field is required. For business constraint rules, constraint definitions such as minimum and maximum values ​​for numeric types, length limits and format patterns for string types, and lists of optional values ​​for enumeration types need to be extracted to form a structured contract description data stored in the contract database.

[0033] For example, assuming the target application is an e-commerce order service, the system obtains the contract data of the "Submit Order" interface by parsing its Swagger documentation: the parameter structure information includes the root object "Order Creation Request", whose fields include user identifier (string type), product list (array type, elements are order product objects), and total order amount (numeric type); the business constraint rules include that the user identifier must conform to the 32-digit universal unique identifier format, the product list length is one to one hundred, and the total order amount must be greater than zero and retained to two decimal places.

[0034] Step S12: Obtain historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application.

[0035] It should be noted that historical request traffic data refers to the record of requests actually received and processed by the target application during runtime, which typically includes information such as request timestamp, request path, request method, request header, request body parameters, and response status code; semantic analysis refers to natural language processing or rule matching of request parameter content to identify its expressed business meaning; traffic intent profiling refers to the structured description formed by classifying and aggregating historical traffic according to business scenarios, used to characterize the parameter feature distribution of traffic under different business scenarios.

[0036] Understandably, this step, by performing semantic-level parsing and clustering of historical traffic, enables the system to go beyond simple parameter value copying and understand the business intent behind parameter combinations. This solves the problem of not being able to distinguish different business scenarios during manual preheating, which leads to a mismatch between preheating traffic and actual business distribution. It provides scenario-based guidance for generating variant traffic that conforms to real business models.

[0037] Specifically, historical request traffic data can be obtained in the following ways: The first method is to access the target application's access logs (such as gateway access logs or application-specific logs), and extract request information by parsing the log files offline. This method is non-intrusive to the application but has data latency. The second method is to deploy a traffic mirroring component (such as the traffic mirroring function of Envoy or Nginx) at the front end of the target application to copy request traffic to the preheating system in real time. This method is highly time-efficient but requires additional infrastructure deployment. The third method is to integrate a software development kit or probe component into the target application to intercept and report request data. This method has good data integrity but requires application modification. During semantic analysis, key business fields (such as order type, payment method, user level, etc.) are first extracted from the request parameters. Then, rule-based dictionary matching (mapping parameter values ​​to preset business semantic tags) or machine learning-based text classification (intention recognition of string parameter values) is used to identify the business scenario identifier corresponding to each request. Finally, traffic is clustered according to the business scenario identifier. Traffic under the same business scenario forms a traffic intent cluster. Each cluster records the distribution of typical parameter values ​​and parameter correlation rules under that scenario. Multiple intent clusters together constitute a traffic intent profile.

[0038] For example, continuing with the e-commerce order service scenario, the system obtains historical request traffic data through log parsing and performs semantic analysis on the order type field: a value of "1" matches the "regular order" tag in the dictionary, a value of "2" matches the "flash sale order" tag, and a value of "3" matches the "group purchase order" tag. Simultaneously, analyzing the joint distribution of order amount and order type reveals that flash sale orders are concentrated in the range of 99 to 199 yuan, while regular orders have a wider range of amounts. Based on this, the system constructs three traffic intent clusters: flash sale order cluster (characteristics: order type is flash sale, fixed amount range, strict inventory verification), regular order cluster (characteristics: order type is regular, amounts are dispersed), and group purchase order cluster (characteristics: order type is group purchase, product quantity is usually greater than one), forming a traffic intent profile for the order service.

[0039] Step S13: Based on the business constraint rules and the traffic intent profile, perform parameter mutation processing on the historical request traffic data to generate mutated traffic data for the target application.

[0040] It should be noted that parameter mutation processing refers to transforming or replacing parameter values ​​in historical requests to generate new request data while maintaining the request structure and business rationality; mutated traffic data refers to the traffic set generated after parameter mutation processing and used to warm up requests. It retains the business characteristics of historical traffic and expands the coverage of parameter values.

[0041] Understandably, this step combines the hard constraints of contract rules with the soft constraints of intent profiling to intelligently mutate historical traffic, so that the generated preheating traffic can cover boundary conditions while maintaining business rationality. This solves the problems of limited coverage caused by simply copying historical traffic and invalid business requests caused by randomly generated parameters, and achieves a balance between the quality and quantity of preheating traffic.

[0042] Specifically, parameter mutation processing can be implemented in the following ways: The first method is boundary value mutation. For numerical parameters, boundary values ​​(such as slightly greater than the minimum, slightly less than the maximum, or precise boundary values) are selected near the minimum and maximum values ​​defined by the business constraint rules, as well as invalid values ​​that exceed the boundaries (used to verify system fault tolerance). This method is mainly used to discover boundary defects. The second method is equivalence class mutation. The parameter value space is divided into several equivalence classes (such as valid equivalence classes and invalid equivalence classes). Representative values ​​are selected from each equivalence class to replace the original parameters. This method is used to ensure coverage. The third method is intent preservation mutation. Within the same traffic intent cluster, new parameter combinations are generated by random sampling based on the parameter distribution characteristics of the cluster (such as mean, variance, and correlation matrix). This ensures that the mutated traffic still conforms to the typical characteristics of the business scenario. This method is used to maintain business rationality.

[0043] For example, for a cluster of flash sale orders in an e-commerce order service, the system first performs intent-preserving mutation: based on the distribution characteristics of the order amount in this cluster (mean 149 yuan, standard deviation 30 yuan), a new amount value of 152.50 yuan is generated by sampling from a normal distribution; at the same time, the order type remains unchanged as flash sale to ensure consistency of the business scenario. Then, boundary value mutation is performed: for the constraint of the product list array length (one to one hundred), mutation requests with boundary values ​​of one and one hundred are generated; for the constraint of the universally unique identifier format of the user identifier, a new identifier value that meets the format requirements is generated. The final generated mutation traffic data contains multiple requests: typical flash sale order requests (order type flash sale, amount 152.50, product list length five), boundary test requests (order type flash sale, product list length one, amount 99.00), etc., forming a diverse set of preheating traffic.

[0044] Step S14: Monitor the startup status of the target application. When the startup of the target application is detected, extract the warm-up request data from the mutated traffic data according to the preset orchestration strategy and send the warm-up request data to the target application.

[0045] It should be noted that the startup state refers to the lifecycle stage of the target application from initialization to when it can provide services to the outside world, which usually includes the startup, ready, and running states; the orchestration strategy refers to the set of rules that determine the timing, order, and batch of preheating requests, and is used to control the rhythm and scope of the preheating process; the preheating request data refers to the request data extracted from the variability traffic data that is actually used to send to the target application.

[0046] Understandably, this step automatically monitors application startup events and triggers the sending of preheating requests, ensuring that the preheating process is closely integrated with the application lifecycle. This eliminates the need for manual waiting and triggering, thus solving the problems of inaccurate timing of manual preheating and the disconnect between preheating and startup. At the same time, the orchestration strategy ensures the orderly delivery of preheating requests, avoiding system overload caused by centralized sending.

[0047] Specifically, monitoring the startup status can be implemented in the following ways: The first approach is to listen to the process status of the target application or the container health check interface (such as the Kubernetes ready probe endpoint). When the status changes from non-ready to ready, preheating is triggered. This method is suitable for containerized deployment environments. The second approach is to integrate a lifecycle callback interface (such as the application ready event in the Spring framework) into the target application. The application actively notifies the preheating system that it has completed initialization. This method is precise but requires the application to integrate a software development kit. The third approach is to use network probing (such as periodically accessing the application's health interface) to determine whether the application can receive requests based on the response status. This method is non-intrusive but has a detection delay. The orchestration strategy can be implemented in the following ways: The first is a sequential extraction strategy, which extracts mutated traffic data in the order it was generated. This is simple to implement but lacks priority differentiation. The second is a priority extraction strategy, which sorts mutated traffic based on interface importance (e.g., core transaction interfaces take priority, query interfaces take priority over write interfaces) or response history (e.g., interfaces with slow historical responses are warmed up first). This method prioritizes critical paths. The third is a batch extraction strategy, which divides mutated traffic into several batches and sends them one batch at intervals. This method smooths out the warm-up load. These strategies can be combined; for example, sorting by priority first and then sending by batch intervals can balance critical path priority and load smoothing.

[0048] For example, the e-commerce order service is deployed on a Kubernetes cluster. It monitors the application interface of the container orchestration platform to obtain changes in the application instance's state. When the readiness condition of the order service instance becomes true, preheating is triggered. The orchestration strategy uses a combination of "priority and batching": first, core interfaces (such as creating orders and deducting inventory) and non-core interfaces (such as querying logistics) are identified in the mutated traffic. The mutated traffic from core interfaces is extracted first and sent as the first batch, followed by non-core interface traffic after a 30-second interval. Within each batch, ten requests are further grouped into micro-batches, with a 500-millisecond interval between groups. Preheating request data is then orchestrated and sent one by one to the corresponding endpoint of the order service.

[0049] Step S15: Receive the execution result data of the target application based on the preheating request data, and generate an application self-preheating report based on the execution result data.

[0050] It should be noted that the execution result data refers to the response information returned by the target application after processing the warm-up request, including the response status code, response time, response body content, exception stack, etc.; the application self-warm-up report is a documented output that records, analyzes, and summarizes the warm-up process, used to evaluate the warm-up effect and guide subsequent optimization. In this step, the execution result data is the original basis for evaluating the warm-up quality, while the application self-warm-up report is a visual representation of the warm-up process and a carrier of experience accumulation.

[0051] Understandably, this step transforms the preheating process from "black box execution" to "white box observable" by collecting feedback data from the preheating execution and generating structured reports. This solves the problems of difficulty in quantifying and evaluating the effects of manual preheating and difficulty in locating problems. At the same time, it provides data support for the iterative optimization of subsequent preheating strategies and forms a closed-loop management of preheating execution.

[0052] Specifically, receiving execution result data can be implemented in the following ways: The first method is synchronous reception, which involves waiting for a response and recording the result synchronously when sending a preheating request. This method provides complete data, but the sending efficiency is affected by the response time. The second method is asynchronous reception, which involves asynchronously collecting response results through a callback interface or message queue after sending a request. This method has high sending efficiency but requires an additional mechanism to ensure that the results are not lost. Statistical indicators such as request sending volume, success rate, and average execution time are summarized to form a brief execution summary. Failed requests are classified and attributed (e.g., connection timeout, business anomaly, parameter error), and slow call chain analysis is performed on requests with abnormally long execution times to locate performance bottleneck interfaces. The preheating effect of this operation is compared with historical preheating data or benchmark performance indicators to evaluate the preheating improvement trend and form a hierarchical report structure for the application's self-preheating.

[0053] For example, the preheating system receives execution results asynchronously: when sending a request, it records the sending timestamp and request identifier; after the target application completes processing, it sends the response status, time taken, and request identifier back to the message queue; the system message queue matches the request identifier to complete the result data. The generated application self-preheating report includes: an overview page (200 requests sent, 198 successful, success rate 99%, average time taken 120 milliseconds), a details page (two failed request attributions: one connection timeout due to the target application's thread pool not being fully initialized, and one parameter validation failure due to mutations exceeding the enumeration range of the new version), and a comparison page (average time taken has decreased by 15% compared to the previous preheating, but the time taken for the inventory interface fluctuates significantly, which should be monitored). The report is stored in a structured format and pushed to the operations and maintenance platform for display.

[0054] This embodiment achieves a complete closed loop from automatic interface contract parsing, historical traffic semantic understanding, intelligent mutation generation, automated preheating delivery to effect evaluation feedback through the above-described scheme. Compared with the method of manually writing preheating code, this scheme eliminates the risk of subjective omissions in manual identification through a systematic data-driven process, expands the breadth and depth of preheating coverage through semantic understanding and parameter mutation, ensures the timeliness and stability of preheating execution through automated orchestration and monitoring, and finally realizes the observability and optimizability of the preheating process through report generation, significantly improving the comprehensiveness, efficiency and reliability of application startup preheating.

[0055] Based on the above implementation scheme, in one feasible implementation, the parameter structure information includes parameter type declaration and input parameter object structure, and the step of obtaining the interface contract data of the target application includes S21~S22: Step S21: Scan the source code of the target application using a static code analysis tool to extract parameter type declarations and business constraint rules from the interface definition file of the source code.

[0056] It should be noted that static code analysis tools refer to programs that parse the structure of source code using techniques such as lexical analysis, syntax analysis, and semantic analysis without executing the code, such as abstract syntax tree parsers and bytecode analysis tools; interface definition files refer to source code files that contain interface specification descriptions, such as controller classes, interface definition language files, and graph query language pattern files in Java; parameter type declarations refer to parameter data types explicitly defined in the source code, such as basic types (integer, string), composite types (list, mapping), and custom object types; business constraint rules refer to parameter validation rules expressed through source code annotations or configurations, such as constraints defined by annotations like non-null constraints, size constraints, and format pattern constraints.

[0057] Understandably, this step uses static code analysis to extract interface specifications from the source code level, enabling the system to acquire contract data before application deployment without waiting for the application to run. This solves the problem that runtime reflection cannot obtain contracts for applications that have not been deployed. At the same time, annotation constraints in the source code provide richer business rule information than at runtime, providing precise legal boundaries for subsequent parameter mutations.

[0058] Specifically, static code analysis can be implemented in the following ways: The first approach is based on abstract syntax tree (AST) parsing. Tools like JavaParser are used to parse the source code and generate an AST, traversing the nodes to identify class declarations, method declarations, and parameter declarations, extracting type and annotation information. This method provides complete information but requires different parsers for different languages. The second approach is based on bytecode analysis. Tools like ASM directly parse the compiled class files, extracting method signatures and annotation metadata from the bytecode. This method requires only the compiled artifacts and is suitable for closed-source component analysis. The third approach is based on annotation processors. During the application compilation phase, standard processor mechanisms intercept and record interface definition information. This method is integrated with the compilation process but requires modification of the build process. When extracting parameter type declarations, generic type erasure needs to be handled, restoring generic type parameters (such as a list of strings instead of the original list) through signature attributes. When extracting business constraint rules, annotation attribute values ​​need to be parsed, converting size constraints into numerical range constraints and format pattern constraints into regular expression constraints, forming a structured rule description.

[0059] Step S22: Dynamically obtain the input parameter object structure of the interface method through runtime reflection mechanism, integrate the parameter type declaration, the input parameter object structure and the business constraint rules to generate interface contract data.

[0060] It's important to note that runtime reflection refers to the ability to dynamically obtain metadata information about classes, methods, and fields during program execution by reflecting application interfaces (such as the reflection package in Java). The parameter object structure refers to the detailed structural information of the parameter object, including its field composition, field types, and nesting levels. Compared to parameter type declarations, the object structure focuses more on the internal expansion of composite types. Integration refers to merging the type declarations and constraint rules obtained from static analysis with the detailed object structure obtained from dynamic reflection, eliminating information conflicts and filling in missing content to form a complete interface contract description. In this step, runtime reflection is used to obtain dynamic characteristics that are difficult to handle through static analysis (such as runtime generic information and dynamic proxy class structures), the parameter object structure is used to refine the internal details of the parameters, and the integration operation is used to generate unified and complete contract data.

[0061] Understandably, this step supplements and verifies the static analysis results through runtime reflection, so that the contract data has both the comprehensiveness of static analysis (obtaining metadata such as annotations) and the accuracy of runtime reflection (obtaining the actual loaded class structure). This solves the problem of structural omissions that pure static analysis may cause due to macro definitions, conditional compilation, and dynamically generated code, as well as the problem that pure runtime reflection cannot obtain information about undeployed applications. By complementing each other, highly complete interface contract data is generated.

[0062] Specifically, runtime reflection can be implemented in the following ways: The first implementation is class loader reflection, which loads the target class through the class loading method, obtains the method list using the method to obtain the list of declared methods, obtains the parameter types using the method to obtain the parameter types and the method to obtain the generic parameter types (the latter retains generic information), and recursively obtains the object field structure using the method to obtain the list of declared fields. This method is suitable for standard class loading scenarios. The second implementation is framework bean reflection, which utilizes the bean definition and MethodParameter class of the Spring framework to obtain framework-level information such as the parameter resolver configuration and type converter of the controller method. This method is suitable for Spring ecosystem applications and can obtain framework-specific parameter binding rules. The third implementation is probe instrumentation, which modifies the bytecode and inserts probes during class loading through the Java Instrumentation mechanism to record the actual runtime parameter object structure. This method can capture the structure of dynamically generated classes but is highly complex. During the integration process, the parameter types obtained from static analysis and runtime reflection are compared first, with the actual loaded type at runtime taking precedence (to resolve generic erasure and type aliasing issues in static analysis). Then, constraint rules are merged, and annotation constraints obtained from static analysis are cross-validated with constraint validator configurations obtained from the validator application interface at runtime. Finally, composite types are recursively expanded, and the field structure of nested objects is flattened into field descriptions with paths, forming a complete contract data graph.

[0063] This embodiment achieves multi-source acquisition and fusion generation of interface contract data through the above-described scheme. Compared with a single acquisition method, this scheme, through the complementary integration of static analysis and runtime reflection, not only ensures the integrity and accuracy of contract data, but also covers different stages before and after application deployment. It provides a reliable rule basis for subsequent traffic variation and preheating execution, and significantly improves the automation level and applicability of contract acquisition.

[0064] Based on the above implementation scheme, in one feasible implementation, the step of performing semantic analysis on the historical request traffic data to determine the traffic intent profile of the target application includes S31~S33: Step S31: Extract the request parameter values ​​from the historical request traffic data, and identify the business scenario identifier based on the matching results of the parameter values ​​and the preset business semantic dictionary.

[0065] It should be noted that request parameter values ​​refer to the specific parameter data content carried in historical requests, such as Uniform Resource Locator (URL) query parameters, form fields, and request body field values; the preset business semantic dictionary refers to a predefined set of rules that maps technical parameter values ​​to business semantic tags, typically including keyword matching rules, regular expression patterns, and enumeration mapping tables; and business scenario identifiers refer to classification tags used to distinguish different business scenarios, such as flash sales, corporate procurement, and refund / after-sales service, used to characterize the business purpose behind the request.

[0066] Understandably, this step maps technical parameter values ​​to business scenario labels, enabling the system to understand the business meaning behind the request data. This solves the problem that traditional traffic processing only focuses on technical features (such as interface paths and response times) while ignoring the business context, and provides a classification basis for subsequent refined clustering based on business scenarios.

[0067] Specifically, parameter value extraction can be implemented in the following ways: The first approach is location-based extraction, which extracts values ​​based on the parameter's position in the request (e.g., the path segment of the Uniform Resource Locator, or the path of a field in the request body). This method is suitable for requests with fixed structures. The second approach is type-based extraction, which iterates through all fields in the request body, identifies field names with specific business meanings (e.g., keywords containing order type, business code, etc.), and extracts their values. This method is suitable for scenarios with standardized field naming. Semantic dictionary matching can be implemented in the following ways: The first approach is exact matching, which establishes a direct mapping table from parameter values ​​to scenario identifiers (e.g., order type value 1 maps to "normal order"), suitable for enumerated parameters. The second approach is pattern matching, which uses regular expressions to match the format features of parameter values ​​(e.g., order numbers starting with a specific prefix map to "flash sale order"), suitable for scenarios where coding rules reflect business types. The third approach is fuzzy matching, which uses text similarity algorithms (e.g., edit distance, cosine similarity) to match parameter values ​​with keywords in the dictionary, suitable for descriptive text parameters. The above implementation methods can be used in combination. For example, first try exact matching, then switch to pattern matching if no match is found, and finally use fuzzy matching if the system still cannot recognize the target, thus forming a multi-level recognition strategy.

[0068] Step S32: Cluster the historical request traffic data according to the business scenario identifier to generate traffic intent clusters under the corresponding business scenario category.

[0069] It should be noted that clustering refers to the process of grouping data objects with the same or similar characteristics into the same group; traffic intent clusters refer to a set of historical requests with similar parameter feature distributions under a specific business scenario, and the requests within the cluster reflect the typical behavior patterns of that scenario; business scenario categories refer to the classification system of business scenario identifiers, which can form a hierarchical structure (such as the first-level scenario "transaction" which includes the second-level scenarios "place an order", "payment", and "refund").

[0070] Understandably, this step, by categorizing and aggregating scattered historical requests according to business scenarios, enables the system to extract typical characteristics of various scenarios from massive traffic, thereby solving the problem of historical traffic being disorganized and unable to be directly used to guide preheating. It forms traffic organization units with business semantics, providing a data foundation for the subsequent construction of structured traffic intent profiles.

[0071] Specifically, clustering can be implemented in the following ways: The first approach is direct grouping based on identifiers, grouping requests with identical business scenario identifiers into the same cluster. This method is simple and efficient but coarse-grained and cannot distinguish sub-patterns within the same scenario. The second approach is clustering based on feature similarity. Under the same scenario identifier, clustering algorithms are used to further subdivide the clusters based on the distribution characteristics of parameter values ​​(such as the range of numerical parameters or the frequent itemsets of categorical parameters) to identify different behavioral sub-patterns within the same scenario (such as the "successful purchase" sub-cluster and the "insufficient inventory" sub-cluster in the "flash sale order" scenario). This method is fine-grained but requires setting clustering parameters. The third approach is clustering based on sequence patterns. This method considers the temporal variation characteristics of request parameters (such as the increasing sequence of the number of items in the shopping cart) and uses sequence clustering algorithms to identify process-oriented scenarios. This method is suitable for multi-step business processes. When generating a traffic intent cluster, the cluster's metadata needs to be recorded: the business scenario identifier, the number of requests within the cluster, the typical value distribution of each parameter (mean, variance, mode), and the correlation rules between parameters (such as whether two fields often appear at the same time), forming a description of the traffic behavior characteristics in that scenario.

[0072] Step S33: Based on the traffic intent cluster and the corresponding target interface path, construct the traffic intent profile of the target application.

[0073] It should be noted that the target interface path refers to the specific application interface endpoint address that handles requests for a specific business scenario, such as " / interface version / order" or " / interface version / payment". The traffic intent profile refers to a panoramic view formed by aggregating all traffic intent clusters under the interface path, describing the distribution of business scenarios supported by the interface and the behavioral characteristics of each scenario.

[0074] Understandably, this step integrates traffic intent clusters with interface paths, enabling the system to establish a three-dimensional cognitive model of "interface-scenario-behavior." This solves the problem of traditional traffic analysis lacking interface dimension aggregation and being unable to intuitively perceive the coverage of interface services, providing a precise basis for traffic selection for subsequent scenario-based preheating of specific interfaces.

[0075] Specifically, traffic intent profiling can be implemented in the following ways: The first approach is a flat profiling, where the interface path is used as the key to directly mount a list of all traffic intent clusters under that interface, forming a simple key-value pair structure. This method is simple to implement but lacks description of relationships between scenarios. The second approach is a hierarchical profiling, which organizes traffic intent clusters hierarchically according to business scenario categories (e.g., first layering by "transaction" → "order scenario" → "flash sale sub-scenario," then mounting specific clusters), forming a tree structure. This method reflects the hierarchical relationship of business scenarios. The third approach is a relational profiling, which, in addition to recording cluster information, explicitly records the relationships between different clusters (e.g., mutual exclusion, sequential, and transformation relationships), forming a graph structure. This method can support complex business flow analysis. During the profiling process, it is necessary to calculate the weight indicators of each traffic intent cluster (e.g., percentage of requests within the cluster, average response time, error rate) to assess the importance and health of the scenario; simultaneously, the timeliness information of the cluster (e.g., most recent occurrence time) is recorded to identify expired scenarios.

[0076] This embodiment achieves the transformation from historical traffic data to structured traffic intent profiles through the above-described scheme. Compared with the method of directly copying historical traffic, this scheme enables the system to understand the business intent behind the traffic and organize the traffic according to the scenario through semantic recognition, cluster analysis and profile construction. This provides accurate scenario-based guidance for the subsequent generation of variant traffic that conforms to the business model, and significantly improves the business rationality and comprehensiveness of the pre-warming traffic.

[0077] Based on the above implementation scheme, in one feasible implementation, the step of performing parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile to generate the mutated traffic data of the target application includes S41~S42: Step S41: Identify the boundary combination data corresponding to the traffic intent cluster of the traffic intent profile based on the business constraint rules.

[0078] It should be noted that boundary combination data refers to the combination of parameter values ​​generated based on the boundary conditions defined in the business constraint rules (such as the minimum / maximum value of the numerical range, the upper / lower limit of the string length, the extreme value of the number of array elements, etc.), which is used to test the system's processing capability under extreme conditions.

[0079] Understandably, this step systematically extracts boundary conditions from business constraint rules and generates combined data, enabling mutated traffic to cover extreme scenarios of parameter values. This solves the problem that simply copying historical traffic is insufficient to cover boundary conditions, which may lead to performance issues or processing anomalies in the system under extreme requests after warm-up. It provides a boundary test data foundation for generating high-coverage mutated traffic in the future.

[0080] Specifically, the following implementation methods can be used to identify boundary combination data: The first implementation method is single-parameter boundary extraction. For each independent parameter, boundary values ​​are generated according to constraint rules (such as minimum value minus one, minimum value, maximum value, maximum value plus one for numerical parameters, and empty string, single character, maximum length, maximum length plus one for string parameters). This method is simple but only covers single-dimensional boundaries. The second implementation method is combined boundary generation. For multiple parameters with constraint relationships, boundary combinations that meet the constraint conditions are generated (such as the combination in the "pagination query" interface where the product of the pagination size and the pagination page number does not exceed the maximum return limit). This method can cover multi-parameter linked boundaries. The third implementation method is scenario-based boundary mapping. Combining the typical characteristics of traffic intent clusters, boundary values ​​are mapped to values ​​that conform to the semantics of the scenario (such as the boundary value of the "high-value order" scenario should be mapped to the upper limit of the amount rather than an arbitrary large number). This method ensures the business rationality of boundary testing.

[0081] Step S42: The boundary combination data and the traffic intent cluster are fused to generate the variable traffic data of the target application.

[0082] It should be noted that fusion processing refers to merging, replacing, or recombining boundary combination data with the original request data in the traffic intent cluster to generate mutated requests that retain both business scenario characteristics and boundary testing elements; mutated traffic data is a set of traffic output after fusion processing used to warm up requests, which has both business rationality and boundary coverage.

[0083] Understandably, this step integrates boundary combination data with the original traffic intent cluster, so that the generated variant traffic has both the real business characteristics of historical traffic and the comprehensive coverage capability of boundary testing. This solves the problems of insufficient coverage by simply using historical traffic and lack of business rationality by simply using boundary values, and achieves a balance between the quality and quantity of preheating traffic.

[0084] Specifically, the fusion process can be implemented in the following ways: The first method is parameter replacement fusion, which selects a typical request from the traffic intent cluster as a template, replaces specific parameter values ​​with boundary values ​​from the boundary combination data, and keeps other parameters unchanged or randomly generated according to the cluster distribution. This method is simple and direct but may disrupt the constraints between parameters. The second method is structural reorganization fusion, which parses the parameter structure of requests in the traffic intent cluster and embeds the boundary combination data as a substructure (e.g., applying the boundary array length to the product list field, and generating sub-elements conforming to business rules based on the new length). This method maintains consistency between parameters. The third method is weighted sampling fusion, which samples multiple requests from the traffic intent cluster and mixes them with the boundary combination data in a certain ratio (e.g., 7:3). This ensures that the main traffic conforms to the business distribution while also ensuring that boundary scenarios are fully tested. During the fusion process, the legality of the generated requests needs to be verified, and invalid requests that violate hard constraints are ensured through business constraint rule verification.

[0085] This embodiment achieves parameter mutation processing that integrates boundary condition identification and traffic intent through the above-described scheme. Compared with simply copying historical traffic or randomly generating parameters, this scheme, through systematic boundary extraction and intelligent fusion processing, ensures that the mutated traffic covers both the boundary conditions of parameter values ​​and maintains the true characteristics of the business scenario. This significantly improves the test coverage and business rationality of the preheating traffic, providing high-quality traffic input for subsequent preheating execution.

[0086] Based on the above implementation scheme, in one feasible implementation, the step of extracting warm-up request data from the variable traffic data according to a preset orchestration strategy and sending the warm-up request data to the target application includes S51~S53: Step S51: Construct an interface call chain graph based on distributed tracing data to identify the service dependencies and call order within the target application.

[0087] It should be noted that distributed tracing data refers to cross-service call records collected by distributed tracing systems (such as Zipkin, Jaeger, and SkyWalking) in a microservice architecture, including information such as tracing identifier, span identifier, service name, interface name, call time, and call result; the interface call chain graph refers to the service call relationship described in the form of a graph structure, where nodes represent service instances, edges represent call relationships, and the call interfaces and frequencies are marked on the edges; service dependency relationship refers to the call and called relationship between services, such as service A calling service B, then A depends on B; and the call order refers to the order in which each service is called in a complete business request.

[0088] Understandably, this step involves analyzing distributed tracing data to construct a service call graph, enabling the system to automatically discover the dependency structure within the target application without requiring manual analysis of service relationships. This solves the problem of difficulty in accurately grasping the large number of services, complex and dynamically changing dependencies in a microservice architecture, and provides a topological basis for subsequent orchestration and warm-up according to dependency order.

[0089] Specifically, the following implementation methods can be used to construct an interface call chain graph: The first method is offline batch processing, which periodically pulls historical tracing data from a distributed tracing system (such as Elasticsearch), parses the parent-child relationships (parent identifier association) between spans, constructs a complete call tree, and aggregates identical call paths to generate a topology graph. This method is suitable for full-scale analysis but suffers from data latency. The second method is real-time stream processing, which consumes span data reported in real-time by the tracing system through a message queue (such as Kafka) and uses a stream computing engine (such as Flink) to construct and update the call relationship graph in real time. This method is highly time-efficient but consumes significant computational resources. The third method is sampling construction, which samples the tracing data (e.g., at a 1% sampling rate) to construct an approximate topology, reducing data processing volume while maintaining topology accuracy. This method is suitable for ultra-large-scale clusters. When identifying dependencies, it is necessary to distinguish between strong dependencies (synchronous calls, failure of which will cause upstream failure) and weak dependencies (asynchronous calls or degraded availability), marking them on the graph edges. When identifying the call order, it is necessary to analyze the timestamps in the tracing to determine the startup call order of each service in the same request.

[0090] Step S52: Sort the mutated traffic data according to the calling order to determine the service-level preheating priority sequence.

[0091] It should be noted that topological sorting refers to the linear sorting of nodes in a directed acyclic graph, such that for each directed edge (start point, end point), the start point of a node is always placed before the end point in the sorting; the service-level warm-up priority sequence refers to a list of warm-up execution orders determined according to service dependencies, with dependent services warmed up first and services that depend on others warmed up later; the mutated traffic data is the set of warm-up traffic categorized by interface generated in claims 1-4. In this step, the call order is the constraint of topological sorting, the mutated traffic data is the object of sorting (organized by service dimension), and the service-level warm-up priority sequence is the execution plan output by the sorting.

[0092] Understandably, this step applies the topological sorting algorithm from graph theory to service dependencies, ensuring that the preheating execution order conforms to the principle of "basic before upper layer". This solves the problem of preheating failure or timeout of dependent services due to the unreadiness of the dependent services when sending preheating requests indiscriminately, thus ensuring the effective delivery of preheating requests and maximizing the preheating effect.

[0093] Specifically, topology sorting can be implemented in the following ways: The first method is a depth-first search algorithm, which performs a depth-first traversal of the call chain graph, records the completion timestamps of nodes, and the topology order is obtained by reversing the completion times. This method is simple to implement but cannot directly detect circular dependencies. The second method is hierarchical sorting, which layers services according to their dependency depth (depth zero is a service with no dependencies, depth one is a service that only depends on services at depth zero, and so on). Services at the same layer can be warmed up in parallel, which facilitates the implementation of batch concurrency. When processing variable traffic data, requests should first be grouped by target service, and then the service groups should be arranged according to topology order to form a priority sequence of "service A request group → service B request group →...".

[0094] Step S53: Extract preheating request data from the variable traffic data in batches according to the preheating priority sequence, and send the preheating request data to the target application based on the service dependency relationship.

[0095] It should be noted that batch extraction refers to extracting the preheating requests for the corresponding services from the variability traffic data layer by layer according to the preheating priority sequence, rather than extracting all requests at once; sending based on service dependencies refers to controlling the target service and retry strategy for sending requests based on the strength and type of dependencies.

[0096] Understandably, this step extracts and sends preheating requests in batches according to topological order, so that the preheating process matches the service startup order, thereby solving the problem of dependent services not being ready due to centralized sending. At the same time, the layered control achieves smooth application of preheating load, avoiding resource contention caused by preheating all services at the same time.

[0097] Specifically, batch extraction and transmission can be implemented in the following ways: The first approach is strict layering, where each layer is preheated sequentially according to the topology. The next layer is only started after all services in the previous layer have completed preheating (through health checks or timeout confirmation). This method ensures sufficient preheating but is time-consuming. The second approach is pipeline overlap, where the next layer's preheating starts immediately after the previous layer's preheating is complete (while maintaining the transmission order). This utilizes overlapping network input / output waiting times, shortening the total time but potentially reducing the sufficiency of single-layer preheating. The third approach is dependency-aware retries. When a preheating request to a service fails, the reason for the failure is analyzed. If the failure is due to a dependent service not being ready, a retry is delayed; if the failure is due to the service itself, the error is recorded. This method enhances fault tolerance. During transmission, requests for services with strong dependencies are prioritized for delivery (e.g., synchronously waiting for a response), while requests for services with weak dependencies can be sent asynchronously (e.g., placed in a message queue), reflecting the different strategies for dependency relationships.

[0098] This embodiment achieves layered preheating orchestration based on service dependency awareness through the above scheme. Compared with the method of sending preheating requests indiscriminately, this scheme automatically discovers the dependency topology through distributed tracking data, determines the execution order through topology sorting, and ensures the readiness of dependencies through batch sending. This significantly improves the success rate of preheating requests and the controllability of the preheating process, and is particularly suitable for scenarios with complex inter-service dependencies in microservice architecture.

[0099] Based on the above implementation scheme, in one feasible implementation, the step of sending the preheating request data to the target application further includes S61~S62: Step S61: Obtain the resource occupancy status data of the target application in real time, and calculate the target deviation value between the resource occupancy status data and the preset resource threshold.

[0100] It should be noted that resource usage status data refers to indicators of the usage of various system resources during the operation of the target application, including CPU utilization, memory usage, thread pool activity, database connection pool utilization, network input / output throughput, etc.; preset resource thresholds refer to the upper or lower limits set for the safe use of various resources, used to determine whether the resources are in a healthy state; target deviation value refers to the difference or ratio between resource usage status data and preset resource thresholds, used to quantify the degree of resource sufficiency, with positive values ​​indicating sufficient resources and negative values ​​(or exceeding the threshold) indicating resource sufficiency.

[0101] Understandably, this step enables the system to quantitatively perceive the load pressure level of the target application by collecting resource status in real time and calculating the deviation from the threshold. This solves the problem that the preheating process cannot perceive the carrying capacity of the preheated system, which may lead to excessive preheating and system overload. It provides a data-driven decision-making basis for the subsequent dynamic adjustment of preheating concurrency.

[0102] Specifically, real-time acquisition of resource occupancy status data can be achieved through the following methods: The first method involves periodically pulling (pull mode) or receiving push (push mode) indicator data through a monitoring system application interface (such as the Prometheus indicator endpoint). This method provides comprehensive data but suffers from collection interval delays. The second method involves embedding probes within the target application to directly read and acquire resource data, reporting it with low latency via User Datagram Protocol (UDP) or shared memory. This method offers high timeliness but requires application integration. The third method involves using bypass observation to indirectly infer resource status by analyzing the target application's log output (such as garbage collection logs and slow query logs). This method is non-intrusive but has lower inference accuracy. When calculating the target deviation value, for resources with upper limits such as the CPU and memory, the deviation value equals a preset threshold minus the current occupancy rate (negative values ​​indicate overload); for resources with usage rates such as connection pools, the deviation value equals the current usage rate minus a preset threshold (positive values ​​indicate strain). When fusing multiple indicators, a weighted average or the tightest constraint (minimum value strategy) can be used to form a comprehensive deviation value.

[0103] Step S62: Based on the target deviation value, a feedback control algorithm is used to dynamically adjust the sending concurrency of the preheating request data.

[0104] It should be noted that feedback control algorithms refer to algorithms that dynamically adjust the control input based on the deviation between the system output and the expected value to stabilize the system in the target state, such as proportional-integral-derivative control, on-off control, fuzzy control, etc.; transmission concurrency refers to the number of preheating requests sent simultaneously per unit time, used to control the intensity of the preheating load; dynamic adjustment means continuously changing the concurrency configuration based on real-time feedback, rather than a fixed preset value.

[0105] Understandably, this step applies feedback control theory to the preheating concurrency adjustment, enabling the preheating load to adapt to the real-time carrying capacity of the target application. This solves the problem that a fixed concurrency cannot adapt to changes in system state (such as low concurrency required when resources are scarce at the beginning of startup, and increased concurrency when resources are sufficient after stabilization), and achieves a dynamic balance between safety and efficiency in the preheating process.

[0106] Specifically, the feedback control algorithm can be implemented in the following ways: The first implementation is on / off control. When the target deviation value is greater than zero (resources are sufficient), the concurrency is increased to a preset upper limit; when the target deviation value is less than zero (resources are scarce), the concurrency is reduced to a preset lower limit or paused. This method is simple to implement but the adjustment process is prone to large fluctuations. The second implementation is proportional control. The concurrency adjustment is proportional to the target deviation value (e.g., the adjustment amount equals the proportional coefficient multiplied by the deviation value). The larger the deviation, the more aggressive the adjustment. This method has a fast response but has steady-state errors. When dynamically adjusting the concurrency, upper and lower limit protection needs to be set (e.g., the minimum concurrency is one to ensure uninterrupted warm-up, and the maximum concurrency is one hundred to prevent excessive aggression), and the adjustment range per instance should be limited (e.g., each adjustment should not exceed 20%) to avoid violent fluctuations.

[0107] This embodiment achieves dynamic adjustment of preheating concurrency based on feedback control through the above scheme. Compared with the preheating method with fixed concurrency, this scheme enables the preheating load to adapt to the real-time status of the target application through real-time resource awareness and algorithmic adjustment, which significantly improves the safety and resource utilization efficiency of the preheating process and avoids the problems of system overload caused by excessive preheating or inefficiency caused by insufficient preheating.

[0108] Based on the above implementation scheme, in one feasible implementation, the step of receiving the execution result data of the target application based on the preheating request data and generating an application self-preheating report based on the execution result data includes S71~S73: Step S71: Extract the response time data from the execution result data, perform response trend analysis based on the response time data, and generate preheating effect evaluation data.

[0109] It should be noted that response time data refers to the time spent by the target application in processing the warm-up request, which is usually the total time from sending the request to receiving the response. It can be further divided into network transmission time, server processing time, dependent service call time, etc. Response trend analysis refers to time series analysis of the time data of multiple requests to identify the trend of time change with the warm-up process (such as decreasing, stabilizing, or fluctuating). Warm-up effect evaluation data refers to the result of quantitative evaluation of the quality of the warm-up process, including whether the warm-up is effective (whether the time has been reduced), the adequacy of the warm-up (whether a steady state has been reached), and anomaly identification (whether there is performance degradation).

[0110] Understandably, this step enables the system to quantitatively evaluate the effectiveness of the preheating process by performing trend analysis on response time. This solves the problem of lack of effect evaluation after preheating and the inability to determine whether the preheating has achieved the expected goals, thus providing a data foundation for subsequent strategy optimization and report generation.

[0111] Specifically, response trend analysis can be implemented in the following ways: The first approach is linear regression analysis, which involves linearly fitting the average time consumption at each time point during the preheating process and calculating the slope to determine the trend (a negative slope indicates effective preheating and a decrease in time consumption). This method is simple to calculate. The second approach is segmented steady-state detection, which divides the preheating process into several windows and calculates the mean and variance of time consumption for each window. When the mean change of multiple consecutive windows is less than a threshold and the variance is stable, it is determined that the preheating steady state has been reached. This method can identify the preheating completion point. The third approach is comparative analysis, which matches the current preheating process's time consumption trend with the trend patterns of historical successful preheating cases to identify abnormal deviations (such as a continuous increase in time consumption, which may indicate system degradation). This method can discover potential problems. When generating preheating effect evaluation data, multiple indicators need to be considered: preheating effectiveness (the percentage decrease in final time consumption compared to the initial time consumption), preheating speed (the number of requests or time required to reach steady state), and stability (the range of time consumption fluctuations in the steady-state stage).

[0112] Step S72: Based on the degree of deviation between the preheating effect evaluation data and the expected performance target, adjust the generation rules of the boundary combination data and the weight configuration of the preheating priority sequence.

[0113] It should be noted that the expected performance target refers to the pre-set preheating effect standard, such as the target response time, maximum allowable time, and preheating completion time limit; the deviation refers to the gap between the preheating effect evaluation data and the expected performance target, which can be quantified as an absolute difference or a relative proportion.

[0114] Understandably, this step compares the preheating effect with the expected target and automatically adjusts the parameters of the mutation generation and orchestration strategy based on the deviation, enabling the preheating system to have self-optimization capabilities. This solves the problems that fixed strategies cannot adapt to application evolution and that strategies are difficult to reuse between different applications, thus achieving continuous improvement and personalized adaptation of the preheating strategy.

[0115] Specifically, the adjustment strategy can be implemented in the following ways: The first approach is threshold-triggered adjustment. When the deviation exceeds a preset threshold (e.g., the actual time taken is 50% higher than the target), rule adjustment is triggered, increasing the proportion of extreme boundaries in the boundary combination (to identify performance bottlenecks) or increasing the preheating priority weight of critical services (to prioritize the core path). This approach responds to clear deviations but may over-adjust. The second approach is incremental fine-tuning. Regardless of the deviation size, after each preheating, parameters are fine-tuned in the direction of optimization by a fixed step size (e.g., ±5%). (If the effect is better than the target, the boundary proportion is reduced to reduce invalid tests; if it is worse than the target, the priority weight is increased to strengthen the preheating.) This approach is stable but converges slowly.

[0116] Step S73: Based on the preheating effect evaluation data, the adjusted generation rules and weight configuration, generate the application self-preheating report.

[0117] It should be noted that the application self-preheating report refers to the documented output of recording, analyzing, summarizing and optimizing suggestions for a single preheating process. It is a visual presentation of preheating execution and a carrier of experience accumulation.

[0118] Understandably, this step generates a structured report by integrating preheating effect evaluation and strategy adjustment records, transforming the preheating process from "black box execution" to "white box observability." This solves the problems of difficulty in tracing preheating effects and accumulating optimization experience, providing decision support for operations and maintenance personnel and accumulating evolutionary knowledge for the system itself.

[0119] Specifically, generating application self-warming reports can be implemented in the following ways: The first approach is a fixed template report, with predefined report sections (overview, details, analysis, recommendations). Data is populated into the template to generate a standardized report. This method is standardized but lacks flexibility. The second approach is dynamically generated reports, adding or removing sections based on key events during the warm-up process (such as abnormal interruptions or strategy adjustments) to highlight important information. This method has high information density but inconsistent structure. The third approach is a comparative report, comparing this warm-up with historical data from the same period, similar applications, and benchmark cases from multiple dimensions to highlight differences and improvement trends. This method facilitates the evaluation of relative performance. The report content should include: an execution summary (time, target application, total requests, success rate), performance evaluation (time consumption trend graph, steady-state indicators, rating), strategy adjustment records (adjustment items, reasons for adjustment, adjustment magnitude), optimization suggestions (specific suggestions for non-compliance items), and a raw data appendix (for in-depth analysis).

[0120] This embodiment achieves closed-loop management of preheating from effect evaluation to strategy optimization to report generation through the above-described scheme. Compared with the method of simply performing preheating without feedback, this scheme enables the preheating system to have the ability to continuously learn and evolve through data-driven effect analysis and strategy self-adjustment. This significantly improves the adaptability of the preheating strategy and the observability of the preheating process, and provides intelligent support for long-term operation and maintenance.

[0121] For example, to aid in understanding the implementation process of the application startup self-preheating method obtained in this embodiment combined with the above embodiment one, the application startup self-preheating method is applied to an application startup self-preheating system, which includes three layers: a business application layer, an automatic preheating platform, and a data storage layer. Please refer to... Figure 2 , Figure 2 A simplified flowchart of an application startup self-preheating method is provided, specifically: At the business application layer, business applications integrate with the preheating system by accessing a software development kit (SDK). This SSD includes multiple functional extensions such as a probe component, a sampling strategy module, a traffic identification module, a performance monitoring module, an automatic preheating module, and a global context module. Each extension interacts with the business application through standardized interfaces, enabling non-intrusive access to traffic collection, strategy execution, and preheating control. In the middle layer, the automatic preheating platform provides core functions including preheating strategy configuration, traffic sampling, traffic preheating, and preheating effect monitoring. The preheating strategy configuration module allows developers to define preheating interfaces and sampling rules; the traffic sampling module collects and stores historical request traffic; the traffic preheating module sends preheating requests when the application starts; and the preheating effect monitoring module tracks the preheating execution status in real time. The front-end interface module provides a preheating strategy configuration interface and a preheating effect display interface for developers and operations personnel to perform visual operations and monitoring. At the lowest data storage layer, multiple Elasticsearch (ES, distributed search engine) storage nodes are used to store traffic sampling data, preheating strategy data, and monitoring log data respectively. Meanwhile, a relational database, MySQL, is used to store configuration metadata and business-related information. This layered storage architecture meets the requirements for high-concurrency writes and flexible queries. Through data flow and collaboration between layers, the entire system achieves a complete closed loop from traffic collection, strategy management, preheating execution to effect monitoring, supporting automated preheating and continuous optimization during application startup.

[0122] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the application of the self-warming method. Any simple modifications based on this technical concept are within the protection scope of this application.

[0123] This application also provides an application-start self-preheating device; please refer to [reference needed]. Figure 3 The application start-up self-preheating device includes: The data parsing module 301 is used to obtain the interface contract data of the target application and parse the parameter structure information and business constraint rules in the interface contract data. The profile determination module 302 is used to obtain historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application. The data generation module 303 is used to perform parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile, and generate the mutated traffic data of the target application. The request sending module 304 is used to monitor the startup status of the target application. When the startup of the target application is detected, it extracts warm-up request data from the mutated traffic data according to a preset orchestration strategy and sends the warm-up request data to the target application. The report generation module 305 is used to receive the execution result data of the target application based on the preheating request data, and generate an application self-preheating report based on the execution result data.

[0124] The application startup self-preheating device provided in this application, employing the application startup self-preheating method in the above embodiments, can solve the technical problem of insufficient comprehensiveness of application startup self-preheating. Compared with the prior art, the beneficial effects of the application startup self-preheating device provided in this application are the same as the beneficial effects of the application startup self-preheating method provided in the above embodiments, and other technical features in the application startup self-preheating device are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0125] This application provides an application startup self-warming device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the application startup self-warming method in the above embodiment 1.

[0126] The following is for reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing the application startup self-warming device in the embodiments of this application. The application startup self-warming device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The application startup self-heating device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0127] like Figure 4As shown, the application startup self-warming device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the application startup self-warming device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the application to initiate self-heating devices to communicate wirelessly or wiredly with other devices to exchange data. While the figures show application-initiated self-heating devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0128] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0129] The application startup self-preheating device provided in this application, employing the application startup self-preheating method described in the above embodiments, can solve the technical problem of insufficient comprehensiveness in application startup self-preheating. Compared with the prior art, the beneficial effects of the application startup self-preheating device provided in this application are the same as those of the application startup self-preheating method described in the above embodiments, and other technical features of this application startup self-preheating device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0130] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0131] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0132] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the application startup self-warming method in the above embodiments.

[0133] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0134] The aforementioned computer-readable storage medium may be included in the application startup self-warming device; or it may exist independently and not assembled into the application startup self-warming device.

[0135] The aforementioned computer-readable storage medium carries one or more programs. When one or more of these programs are executed by the application-initiated self-warming device, the application initiates the self-warming device to: acquire the interface contract data of the target application, and parse the parameter structure information and business constraint rules in the interface contract data; acquire the historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application; perform parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile to generate mutated traffic data of the target application; monitor the startup status of the target application, and when the startup of the target application is detected, extract warming request data from the mutated traffic data according to a preset orchestration strategy and send the warming request data to the target application; receive the execution result data of the target application based on the warming request data, and generate an application self-warming report based on the execution result data.

[0136] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0137] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0138] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0139] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described application startup self-warm-up method, thereby solving the technical problem of insufficient comprehensiveness of application startup self-warm-up. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the application startup self-warm-up method provided in the above embodiments, and will not be repeated here.

[0140] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the application startup self-warm-up method described above.

[0141] The computer program product provided in this application can solve the technical problem of insufficient comprehensiveness of application startup self-warming. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the application startup self-warming method provided in the above embodiments, and will not be repeated here.

[0142] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An application startup self-preheating method, characterized in that, The application startup self-preheating method includes: Obtain the interface contract data of the target application, and parse the parameter structure information and business constraint rules in the interface contract data; Obtain historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application; Based on the business constraint rules and the traffic intent profile, the historical request traffic data is subjected to parameter mutation processing to generate the mutated traffic data of the target application; Monitor the startup status of the target application. When the startup of the target application is detected, extract warm-up request data from the mutated traffic data according to the preset orchestration strategy and send the warm-up request data to the target application. Receive the execution result data of the target application based on the preheating request data, and generate an application self-preheating report based on the execution result data.

2. The application startup self-preheating method as described in claim 1, characterized in that, The parameter structure information includes parameter type declarations and input parameter object structures. The step of obtaining the interface contract data of the target application includes: The source code of the target application is scanned using static code analysis tools to extract parameter type declarations and business constraint rules from the interface definition files of the source code. The structure of the input parameter object of the interface method is dynamically obtained through runtime reflection mechanism. The parameter type declaration, the structure of the input parameter object and the business constraint rules are integrated to generate interface contract data.

3. The application startup self-preheating method as described in claim 1, characterized in that, The step of performing semantic analysis on the historical request traffic data to determine the traffic intent profile of the target application includes: Extract request parameter values ​​from the historical request traffic data, and identify business scenario identifiers based on the matching results of the parameter values ​​and the preset business semantic dictionary; Based on the business scenario identifier, the historical request traffic data is clustered to generate traffic intent clusters under the corresponding business scenario category; Based on the traffic intent clusters and the corresponding target interface paths, a traffic intent profile of the target application is constructed.

4. The application startup self-preheating method as described in claim 3, characterized in that, The step of performing parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile to generate mutated traffic data for the target application includes: Based on the business constraint rules, the boundary combination data corresponding to the traffic intent clusters of the traffic intent profile are identified; The boundary combination data and the traffic intent cluster are fused to generate the variant traffic data of the target application.

5. The application startup self-preheating method as described in claim 1, characterized in that, The step of extracting warm-up request data from the variable traffic data according to a preset orchestration strategy and sending the warm-up request data to the target application includes: An interface call chain graph is constructed based on distributed tracing data to identify the service dependencies and call order within the target application. The variable traffic data is topologically sorted according to the calling order to determine the service-level preheating priority sequence; Preheating request data is extracted from the variable traffic data in batches according to the preheating priority sequence, and the preheating request data is sent to the target application based on the service dependency relationship.

6. The application startup self-preheating method as described in claim 1, characterized in that, The step of sending the warm-up request data to the target application further includes: Real-time acquisition of resource usage status data of the target application, and calculation of the target deviation value between the resource usage status data and the preset resource threshold; The concurrent sending of the preheating request data is dynamically adjusted based on the target deviation value using a feedback control algorithm.

7. The application startup self-preheating method as described in claim 4, characterized in that, The step of receiving the execution result data of the target application based on the preheating request data, and generating an application self-preheating report based on the execution result data, includes: Extract response time data from the execution result data, perform response trend analysis based on the response time data, and generate preheating effect evaluation data; Based on the degree of deviation between the preheating effect evaluation data and the expected performance target, adjust the generation rules of the boundary combination data and the weight configuration of the preheating priority sequence; Based on the preheating effect evaluation data, the adjusted generation rules, and the weight configuration, the application self-preheating report is generated.

8. An application-based self-preheating device, characterized in that, The application-start self-preheating device includes: The data parsing module is used to obtain the interface contract data of the target application and parse the parameter structure information and business constraint rules in the interface contract data. The profile determination module is used to acquire historical request traffic data of the target application, perform semantic analysis on the historical request traffic data, and determine the traffic intent profile of the target application. The data generation module is used to perform parameter mutation processing on the historical request traffic data according to the business constraint rules and the traffic intent profile, and generate the mutated traffic data of the target application. The request sending module is used to monitor the startup status of the target application. When the startup of the target application is detected, the module extracts warm-up request data from the mutated traffic data according to the preset orchestration strategy and sends the warm-up request data to the target application. The report generation module is used to receive the execution result data of the target application based on the preheating request data, and generate an application self-preheating report based on the execution result data.

9. An application-start self-preheating device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the application startup self-warm-up method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the application startup self-warm-up method as described in any one of claims 1 to 7.

Images