Java system preheating method and device based on analog message

Abstract

The invention provides a Java system preheating method and device based on a simulation message. The method comprises the following steps: acquiring a preset configuration file of a Java application; under the condition that the Java application automatically enters a preheating mode after being started, a database layer of the Java application is set to be in an automatic rollback mode, and the automatic rollback mode is a mode that a transaction manager does not carry out submission operation and carries out rollback operation at the end position of a transaction; calling the corresponding simulation transaction message for preheating according to the optimal transaction calling times corresponding to each simulation transaction message in the configuration file until all simulation transaction messages are called; and setting the database layer to be in a normal submission mode, and prompting that the Java application is successfully started. The problem that in the prior art, preheating can only be achieved by depending on the application node access cluster and depending on the gray release capacity of a distributed system, and consequently manpower and physical resource cost is too high is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of system preheating, and in particular, to a Java system preheating method based on simulated messages, a Java system preheating device based on simulated messages, a computer-readable storage medium, and a computer program product. Background Art

[0002] In a banking business system developed in the Java language, the problem of the timeout of the first transaction after the system starts is usually encountered. A timeout transaction is generally considered to have an unclear transaction status and needs to be further retried or cancelled. For customers, there will be risks such as capital risks and uncertain risks of transaction success or failure. The timeout of the first transaction is related to the operating mechanism of the underlying JVM virtual machine of the Java application. There is a gradual preheating process from the start of the Java application to the optimal throughput.

[0003] Currently, there are three common solutions in the industry, as Figure 1 shown. The first is to manually identify hot code and preheat this code by running unit tests and preloading. By means of log analysis and other methods, high-frequency code is manually identified according to preset system keywords and historical compilation logs, and the methods or functions to be preheated are determined, such as some common utility classes, PO entity classes, SQL statements, etc., and unit tests are developed for these codes. When the application starts, obtain the unit test cases corresponding to the methods or functions to be preheated and run these unit tests to trigger JIT (Just-In-Time) compilation to achieve the purpose of preheating. This method requires manual identification of hot code, and the identification results may not be comprehensive and accurate, and it also requires a deep understanding of the operating principle of the JIT compiler of the JVM. The second is through flow control. Based on the gray release of the distributed system, the upgrade and online of server nodes are executed batch by batch. After the application starts and accesses the cluster, a small amount of traffic is forwarded to the node to be preheated, and the preheating is completed through the form of real transaction calls. After the preheating is completed, this node is officially online and receives normal transaction traffic. This method cannot solve the problem of the timeout of the first transaction. When there are few transactions in the production environment, the preheating process may take a long time. The third is to build a shadow database. After starting, it first receives preheating transactions, and the data generated by the preheating transactions is stored in the shadow database. A shadow database is built by imitating the production database. The shadow database is similar to a test database. After the application starts, transaction calls are first initiated through stress testing, and the data generated by the transactions is submitted to the shadow database. After the preheating is completed, the database is switched to the real production database. This method requires modifying and distinguishing SQL types to determine whether the SQL request belongs to the real production database or the shadow database, and a shadow database is introduced in the production environment. It does not really effectively isolate production data and test data, which is likely to cause hidden dangers of misoperation. Summary of the Invention

[0004] The main purpose of this application is to provide a Java system preheating method based on simulated messages, a Java system preheating device based on simulated messages, a computer-readable storage medium, and a computer program product, so as to at least solve the problem in the prior art that it depends on the access of application nodes to the cluster and the gray release capabilities of distributed systems to preheat, resulting in too high human and physical resource costs.

[0005] To achieve the above object, according to one aspect of the present application, a Java system preheating method based on simulated messages is provided, including: obtaining a configuration file preset in the Java application, where the configuration file at least includes a plurality of simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages, and the simulated transaction messages are messages of simulated transactions constructed according to real transactions; when the Java application automatically enters the preheating mode after startup, setting the database layer of the Java application to the automatic rollback mode, where the automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction; calling the corresponding simulated transaction messages for preheating according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called; setting the database layer to the normal commit mode and prompting that the Java application starts successfully, where the normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end position of the transaction.

[0006] Optionally, before obtaining the configuration file preset in the Java application, the method further includes: analyzing the historical transaction call situation to identify all high-frequency transactions; generating the corresponding simulated transaction messages according to all the high-frequency transactions; determining the optimal transaction call times corresponding to the simulated transaction messages; writing all the simulated transaction messages and the corresponding optimal transaction call times into the configuration file of the Java application in the form of key-value pairs, and the configuration file is packaged and released together with the Java application.

[0007] Optionally, determining the optimal transaction call times corresponding to the simulated transaction messages includes: setting an initial transaction call times; a preheating step of performing preliminary preheating according to the initial transaction call times until the preheating of the Java application is completed, and obtaining the first transaction time consumption corresponding to the initial transaction call times; a judgment step of judging whether the first transaction time consumption converges; an increasing step of, when the first transaction time consumption does not converge, increasing the initial transaction call times and repeating the preheating step, the judgment step, and the increasing step at least once; when the first transaction time consumption converges, determining the initial transaction call times as the optimal transaction call times.

[0008] Optionally, call the corresponding simulated transaction message for warm-up according to the best transaction call times corresponding to each of the simulated transaction messages in the configuration file until all the simulated transaction messages are called. The process includes: loading the configuration file and sequentially reading all the simulated transaction messages; initiating a transaction simulation operation according to the best transaction call times of the simulated transaction messages to call the corresponding simulated transaction messages until all the simulated transaction messages are called.

[0009] Optionally, set the database layer of the Java application to the automatic rollback mode, including: setting the database layer of the Java application to the automatic rollback mode in the form of a flag bit.

[0010] Optionally, after calling the simulated transaction messages for warm-up according to the best transaction call times in the configuration file until all the simulated transaction messages are called, the method further includes: controlling the Java application to automatically exit the warm-up mode.

[0011] Optionally, after prompting that the Java application has been successfully started, the method further includes: controlling the Java application to provide services externally.

[0012] According to another aspect of the present application, there is provided a Java system warm-up device based on simulated messages. The device includes: an acquisition unit that acquires a configuration file preset in a Java application, where the configuration file at least includes a plurality of simulated transaction messages and the best transaction call times corresponding to each of the simulated transaction messages, and the simulated transaction messages are messages of simulated transactions constructed according to real transactions; a first setting unit configured to set the database layer of the Java application to the automatic rollback mode when the Java application automatically enters the warm-up mode after startup, where the automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction; a warm-up unit configured to call the corresponding simulated transaction messages for warm-up according to the best transaction call times corresponding to each of the simulated transaction messages in the configuration file until all the simulated transaction messages are called; a second setting unit configured to set the database layer to the normal commit mode and prompt that the Java application has been successfully started, where the normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end position of the transaction.

[0013] According to still another aspect of the present application, there is provided a computer-readable storage medium, where the computer-readable storage medium includes a stored program, and when the program runs, it controls the device where the computer-readable storage medium is located to execute any one of the above methods.

[0014] According to another aspect of the present application, there is provided a computer program product including computer instructions which, when executed by a processor, implement any of the above methods.

[0015] Applying the technical solution of the present application to the Java system warm-up method based on simulated messages, first, obtain the configuration file preset in the Java application. The above configuration file includes at least multiple simulated transaction messages and the corresponding optimal transaction call times for each of the above simulated transaction messages. The above simulated transaction messages are messages of simulated transactions constructed according to real transactions. Then, when the above Java application automatically enters the warm-up mode after startup, set the database layer of the above Java application to the automatic rollback mode. The above automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction. After that, call the corresponding above simulated transaction messages for warm-up according to the above optimal transaction call times corresponding to each of the above simulated transaction messages in the above configuration file until all the above simulated transaction messages are called. Finally, set the above database layer to the normal commit mode and prompt that the above Java application starts successfully. The above normal commit mode is a mode in which the above transaction manager performs the above commit operation and does not perform the above rollback operation at the end position of the transaction. The present application identifies key high-frequency transactions through analysis, simulates the real calls of these transactions, and pre-sets the simulated transaction messages into the configuration file in the application. When the application starts, the warm-up module inside loads the simulated transaction messages and initiates transaction calls. No real data submission is made at the database layer. After the warm-up is completed, the database is switched to the normal commit mode, and the service is provided externally only after the application starts successfully. The present application solves the problem in the prior art that it depends on the access of application nodes to the cluster and the capabilities such as the gray release of the distributed system to warm up, resulting in too high human and physical resource costs. Description of the Drawings

[0016] Figure 1 Shows three common system warm-up schemes in the prior art;

[0017] Figure 2 Shows the hardware structure block diagram of a mobile terminal for implementing the Java system warm-up method based on simulated messages according to an embodiment of the present application;

[0018] Figure 3 Shows the flowchart of a Java system warm-up method based on simulated messages according to an embodiment of the present application;

[0019] Figure 4 Shows the overall flowchart of a specific Java system warm-up according to an embodiment of the present application;

[0020] Figure 5Shows a schematic diagram of selecting the optimal number of trading calls provided according to an embodiment of the present application;

[0021] Figure 6 Shows a structural block diagram of a Java system warm-up device based on simulated messages provided according to an embodiment of the present application.

[0022] Among them, the above-mentioned drawings include the following reference numerals:

[0023] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed implementation manners

[0024] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the drawings and in combination with the embodiments.

[0025] In order to enable those skilled in the art to better understand the solutions of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so as to describe the embodiments of the present application here. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units does not have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0027] For the convenience of description, some nouns or terms related to the embodiments of the present application are described below:

[0028] JVM: Java Virtual Machine, a virtual machine that can execute Java bytecode and is implemented with a stack structure machine. It was first developed and implemented by Sun Microsystems and is part of the Java platform, capable of executing software programs written in the Java language.

[0029] JIT: Just-In-Time Compiler, the just-in-time compiler of the JVM virtual machine.

[0030] Distributed system: A distributed system is a collection of computer programs that utilize computing resources across multiple independent computing nodes to achieve a common goal. It is also known as distributed computing or a distributed database and relies on different nodes to communicate and synchronize via a common network. These nodes typically represent independent physical hardware devices but can also represent separate software processes or other recursively encapsulated systems. Distributed systems are designed to eliminate system bottlenecks or single points of failure.

[0031] ORM: Object Relational Mapping, a programming technique used to implement the conversion between data of different type systems in object-oriented programming languages. When operating on data, it is based on object-oriented thinking to write classes, objects, and call corresponding methods, etc. ORM will convert / map them into native SQL and then hand it over to the database for execution.

[0032] PO: Persistant Object, a persistent object. A PO corresponds to a record in the database. The data structure of a PO corresponds to the structure of a table in the database, and a record in the table is a PO object.

[0033] As introduced in the background art, in the prior art, system warm-up is usually achieved by manually identifying hot code, flow control methods, and building a shadow database. Manually identifying hot code usually cannot be accurate and effective; the method of initiating warm-up by executing unit tests is an abnormal link call and cannot simulate the scenario of real transaction requests. It is difficult to achieve the best performance state after warm-up. Since the flow control method uses real transaction requests for warm-up, this solution will still encounter the problem of slow first transactions and needs to consider increasing the maximum timeout to prevent transaction timeouts. Building a shadow database introduces an additional shadow database in the production environment and does not truly isolate production data from test data, which is prone to hidden dangers of incorrect operations; building a shadow database requires additional hardware resources and is not conducive to reducing capital costs. To solve the problem in the prior art that warm-up depends on the access of application nodes to the cluster and the gray release capabilities of distributed systems, resulting in high human and physical resource costs, the embodiments of this application provide a Java system warm-up method based on simulated messages, a Java system warm-up device based on simulated messages, a computer-readable storage medium, and a computer program product.

[0034] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention.

[0035] The method embodiments provided in the embodiments of the present application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 2 is a hardware structure block diagram of a mobile terminal for a Java system warm-up method based on simulated messages according to an embodiment of the present invention. As Figure 2 shown, the mobile terminal may include one or more ( Figure 2 only one is shown in the figure) processors 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Among them, the above-mentioned mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 2 the structure shown is only schematic and does not limit the structure of the above-mentioned mobile terminal. For example, the mobile terminal may further include more or fewer components than Figure 2 shown in the figure, or have a different configuration from Figure 2 shown in the figure.

[0036] The memory 104 can be used to store computer programs. For example, software programs and modules of application software, such as the computer program corresponding to the Java system warm-up method based on simulated messages in the embodiments of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implements the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely disposed relative to the processor 102, and these remote memories may be connected to the mobile terminal through a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wireless network provided by a communication provider of the mobile terminal. In one instance, the transmission device 106 includes a network adapter (abbreviated as NIC), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (abbreviated as RF) module, which is used to communicate with the Internet wirelessly.

[0037] In this embodiment, a method for preheating a Java system based on simulated messages running on a mobile terminal, a computer terminal, or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0038] Figure 3 It is a flowchart of a method for preheating a Java system based on simulated messages according to an embodiment of the present application. As Figure 3 shown, the method includes the following steps:

[0039] Step S201, obtain a configuration file preset in the Java application. The configuration file at least includes a plurality of simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages. The simulated transaction messages are messages of simulated transactions constructed according to real transactions.

[0040] Specifically, through requirement analysis and analysis of the transaction call situation of the old system, key high-frequency transactions are pre-identified to obtain simulated transaction messages and the corresponding optimal call times, and these simulated transaction messages are stored in the form of a configuration file. In this step, the Java application reads the preset configuration file at the initial stage of startup. The configuration file contains a plurality of simulated transaction messages and their corresponding optimal transaction call times. The simulated transaction messages are constructed based on real transaction messages in history to simulate real transaction scenarios, and the optimal transaction call times are determined through pre-tests to be the call times that can make the JVM reach a better performance state during the preheating stage.

[0041] Through the configuration file, the application can know which transactions need to be preheated and how many times each transaction should be called, thus avoiding the complexity and inaccuracy of manually identifying hot code. Ensure that the application can call the hot code of the JVM through simulated transactions at the initial stage of startup, so that the JIT just-in-time compiler can optimize and compile these codes in advance, thereby reducing the response time of the first transaction after startup and improving the initial performance of the application.

[0042] Step S202, when the above Java application automatically enters the preheating mode after startup, set the database layer of the above Java application to the automatic rollback mode. The automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end of the transaction.

[0043] Specifically, as Figure 4As shown, after the Java application starts, it automatically enters the warm-up mode, and the ORM layer (i.e., the above-mentioned database layer) sets the database to the auto-rollback mode. In the auto-rollback mode, the transaction manager does not perform the commit operation, and all database operations during the warm-up phase will be automatically rolled back at the end of the transaction, so that no trace of real data will be left in the production database.

[0044] During the warm-up phase, the auto-rollback mode ensures that the application can simulate transactions without affecting the production database, avoiding the risk of production data being contaminated by test data. The application can perform efficient performance warm-up without disturbing the data integrity of the production environment. This reduces the potential for misoperations and, at the same time, does not require additional shadow database resources, saving costs.

[0045] Step S203: Call the corresponding simulated transaction message for warm-up according to the above-mentioned best transaction call times corresponding to each of the above-mentioned simulated transaction messages in the above-mentioned configuration file until all of the above-mentioned simulated transaction messages have been called.

[0046] Specifically, the warm-up module calls the corresponding simulated transaction message for warm-up operations according to the best call times of each simulated transaction message in the configuration file until all the preset simulated transaction messages have been called. The warm-up module is an in-built module of the application and does not depend on the capabilities such as cluster communication, recovery and publishing. It is embedded into the application startup process through annotations such as Spring's PostConstruct. Calling the simulated transaction message according to the best call times can ensure that the JIT compiler of the JVM fully optimizes the hot code in the application, while controlling the time consumption of the warm-up process and avoiding resource waste caused by over-warm-up.

[0047] Step S204: Set the above-mentioned database layer to the normal commit mode and prompt that the above-mentioned Java application has started successfully. The normal commit mode is a mode in which the above-mentioned transaction manager performs the above-mentioned commit operation and does not perform the above-mentioned rollback operation at the end position of the transaction.

[0048] Specifically, when all the simulated transaction calls in the warm-up phase are completed, the warm-up module will notify the database layer to exit the auto-rollback mode and switch to the normal commit mode. At this time, the application can officially provide services externally, and the transaction data will be correctly committed to the production database. This ensures that after the warm-up is completed, the application can process real transactions correctly and without error, all transaction data is saved, there will be no data loss or inconsistency, and at the same time, system exceptions that may be caused by the remaining transactions in the warm-up phase are avoided.

[0049] The above embodiments enable the present invention to have the following advantages: (1) The present invention can reduce the capital risk caused by transaction timeouts and improve the customer experience problems caused by slow transaction responses. (2) The preheating method of the present invention is simpler and easier to use, which can reduce labor costs. The present invention initiates preheating by simulating real transaction scenarios, and only needs to construct transaction messages according to the scenarios; the data submission method is transformed at the ORM database layer, and the upper-layer applications do not need to be aware of it. Compared with the common industry method of manually identifying hot code and high-frequency SQL, the method proposed by the present invention is more general. Developers do not need to understand the details of JIT just-in-time compilation optimization, and do not need to sort out and identify hot code, reducing labor costs. (3) The present invention can reduce capital costs. Compared with the traditional method of building a shadow database for stress testing, it can reduce the consumption of physical resources such as hardware, thus reducing costs.

[0050] In this embodiment, first, obtain the configuration file preset in the Java application. The above configuration file includes at least a plurality of simulated transaction messages and the corresponding optimal transaction call times for each of the above simulated transaction messages. The above simulated transaction messages are the messages of simulated transactions constructed according to real transactions; then, when the above Java application automatically enters the preheating mode after startup, set the database layer of the above Java application to the automatic rollback mode. The above automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction; after that, call the corresponding above simulated transaction message for preheating according to the above optimal transaction call times corresponding to each of the above simulated transaction messages in the above configuration file until all the above simulated transaction messages are called; finally, set the above database layer to the normal commit mode and prompt that the above Java application starts successfully. The above normal commit mode is a mode in which the above transaction manager performs the above commit operation and does not perform the above rollback operation at the end position of the transaction. This application analyzes and identifies key high-frequency transactions, simulates the real calls of these transactions, and pre-sets the simulated transaction messages into the configuration file in the application. When the application starts, the preheating module loads the simulated transaction messages internally and initiates transaction calls. No real data submission is performed at the database layer. After preheating is completed, the database is switched to the normal commit mode, and the application provides services externally only after it starts successfully. This application solves the problem in the prior art that it relies on the ability of application nodes to access the cluster and the gray release of the distributed system to preheat, resulting in too high labor and physical resource costs.

[0051] In order to enable those skilled in the art to understand the technical solution of the present application more clearly, the implementation process of the Java system preheating method based on simulated messages of the present application will be described in detail below with specific embodiments.

[0052] To improve the preheating efficiency and ensure that the performance of high-frequency trading reaches the optimal level after the application starts, in an optional implementation manner, before the above step S201, the method further includes:

[0053] Step S301: Analyze the historical trading call situations to identify all high-frequency trades;

[0054] Step S302: Generate the corresponding simulated trading messages according to all the above high-frequency trades;

[0055] Step S303: Determine the optimal trading call times corresponding to each of the above simulated trading messages;

[0056] Step S304: Write all the above simulated trading messages and the corresponding optimal trading call times into the above configuration file of the above Java application in the form of key-value pairs, and the above configuration file is packaged and released together with the above Java application.

[0057] In the above embodiments, it is first necessary to collect historical transaction data and analyze it. This includes, but is not limited to, viewing transaction logs, performance monitoring data, and historical transaction records, with the focus on identifying transaction types that are frequently called during actual operation. These high-frequency transactions usually have more stringent requirements for system performance and response time, so they are the key objects to be focused on during the warm-up stage. Accurately identifying high-frequency transactions that need to be warmed up ensures that the performance of these transactions can be optimized specifically during the warm-up stage. By warming up high-frequency transactions, the response time of the first transaction after startup can be significantly reduced, enhancing the user experience and at the same time reducing potential business risks caused by slow first transactions. Once high-frequency transactions are identified, next, construct simulated transaction messages for each high-frequency transaction. This usually involves a deep understanding of the transaction process and familiarity with the formats of transaction requests and response messages. The simulated transaction messages should simulate the inputs and outputs of real transactions as much as possible, including but not limited to transaction parameters, data structures, and business logics that may be involved. By constructing simulated transaction messages, a real transaction environment can be simulated during the startup stage, thereby triggering the JVM to optimize the relevant code. Enabling the JVM to quickly identify and compile and optimize the hot code in high-frequency transactions, improving the warm-up efficiency and ensuring that the performance of high-frequency transactions reaches the optimal level after the application starts. To determine the optimal number of calls for each simulated transaction message, a series of experiments and tests are required. Usually, start with a relatively low number of warm-up calls and gradually increase it until the transaction response time stabilizes. This stable point is the optimal number of transaction calls, aiming to ensure that the JIT compiler of the JVM can fully optimize the code, while not causing too long startup time due to excessive warm-up. Determine a number of calls that can fully warm up while controlling the startup time to achieve a balance between performance optimization and efficiency. Reduce the overall time consumption during the startup stage, and at the same time ensure that the application can immediately process high-frequency transactions after startup, enhancing the availability and user experience of the application. Store all the generated simulated transaction messages and their respective optimal number of calls in the configuration file of the Java application. The configuration file is packaged with the application and is used for subsequent reading by the warm-up module. These configuration files will contain a series of key-value pairs (in the form of key-value), where the key is the transaction code or identifier, and the value is the optimal number of calls for that transaction. The configuration file must be correctly packaged so that it can be read when the application starts.

[0058] In order to ensure that the application can immediately enter the optimal performance state after each startup, while avoiding the problem of too long startup time caused by excessive warm-up, in an optional implementation manner, step S303 includes:

[0059] Step S3031, set the initial number of transaction calls;

[0060] Step S3032, preheating step: Preheat according to the above-mentioned initial transaction call count until the preheating of the above Java application is completed, and obtain the elapsed time of the first transaction corresponding to the above initial transaction call count.

[0061] Step S3033, judgment step: Judge whether the elapsed time of the above first transaction converges.

[0062] Step S3034, increment step: In the case where the elapsed time of the above first transaction does not converge, increment the above initial transaction call count, and repeat the above preheating step, the above judgment step, and the above increment step at least once.

[0063] Step S3035: In the case where the elapsed time of the above first transaction converges, determine the above initial transaction call count as the above optimal transaction call count.

[0064] In the above embodiment, the call count corresponding to the transaction should be as small as possible to avoid increasing the overall elapsed time in the startup phase. Therefore, a reasonable value of the optimal transaction call count is given after verification through the test environment during the transaction development phase (before the application starts). This process dynamically adjusts the preheating times of the simulated transaction to reach a balance point that can effectively preheat the system without excessively increasing the startup time. As Figure 5 shown, first set a relatively small initial value (such as 5 times). After the preheating is completed, test the elapsed time of the first transaction. After obtaining the elapsed time data of the first transaction, enter the judgment step to evaluate whether the elapsed time tends to be stable. This is usually done by comparing the current elapsed time with the elapsed times after the previous preheating to determine whether the elapsed time curve converges, that is, whether the elapsed time tends to a stable value and no longer has significant changes. Judge whether the preheating process has enabled the JVM to reach a state of stable performance. This can avoid unnecessary increases in the preheating times and ensure that the preheating process indeed has a significant optimization effect on the elapsed time of the first transaction. If it is found in the judgment step that the elapsed time of the first transaction does not converge, that is, the elapsed time still has large fluctuations or room for decrease, then the initial transaction call count will be increased, and the preheating step and the judgment step will be repeated until the elapsed time curve converges. When the first elapsed time tends to be stable, it is the reasonable value of the transaction call count for the preheating phase. Determine an exact optimal transaction call count to optimize the response time of the first transaction after the application starts. Ensure that the application can immediately enter the optimal performance state every time it starts, provide fast-response transaction processing, improve the overall system performance and user experience, and at the same time avoid the problem of too long startup time caused by excessive preheating. As shown in Table 1, the optimal call count for the transaction is 9 times.

[0065] Table 1

[0066]

[0067] To ensure that the application reaches a good performance state at startup and avoid the problem of slow first transaction, in an optional implementation manner, the above step S203 includes:

[0068] Step S2031, load the above configuration file and read all the above simulation transaction messages in sequence;

[0069] Step S2032, initiate a transaction simulation operation according to the above best transaction call times of the above simulation transaction messages to call the corresponding above simulation transaction messages until all the above simulation transaction messages are called.

[0070] In the above embodiment, after the Java application starts and enters the warm-up mode, the warm-up module will automatically load the previously prepared configuration file. The configuration file contains simulation transaction messages and their corresponding best transaction call times. The warm-up module will read them one by one in the order of the transaction messages in the configuration file, which ensures that the warm-up process proceeds in an orderly manner according to the pre-set plan. Load the configuration file, parse the key-value pairs in it, and obtain the identifiers of the simulation transaction messages and the best transaction call times. Process the information of each transaction message one by one in the order of the transaction messages in the configuration file. Ensure that the warm-up module can correctly read the configuration information, know which transaction messages should be warmed up, and how many times each message should be called, so as to perform the warm-up purposefully. Through the orderly reading of the configuration file, the warm-up process can be accurately controlled, avoiding the problems of insufficient warm-up or over-warm-up that may be caused by random warm-up, and improving the efficiency and pertinence of warm-up. For each simulation transaction message read from the configuration file, the warm-up module calls the business logic of the corresponding transaction according to the value of the best call times. The execution of the simulation transaction includes, but is not limited to, calling the ORM layer, accessing the database, executing business logic, etc., but all database operations will be automatically rolled back at the end of the transaction and will not affect the production database. Repeat the above operations until all the configured simulation transaction messages are called according to their best transaction call times. Realize the warm-up of the JVM virtual machine to ensure that the JIT just-in-time compiler can fully optimize and compile the hot code of high-frequency transactions to reach the best performance state. Through the call of the simulation transaction message, the JVM can recognize which are the hot codes at the initial stage of the application startup and quickly optimize them. This can significantly reduce the response time of the first transaction after the application starts, thereby improving the overall performance and user experience of the application. Through the above steps, the warm-up module can automatically and orderly execute the warm-up operation, ensure that the application reaches a good performance state at startup, avoid the problem of slow first transaction, and at the same time protect the production database from the influence of the warm-up process. This method not only simplifies the warm-up process, reduces the labor cost, but also improves the availability and response speed of the application, and is an effective means to solve the Java application startup performance problem.

[0071] In order to reduce the implementation cost and complexity of the warm-up solution, in an optional implementation manner, the above step S202 includes:

[0072] Step S2021, set the database layer of the above Java application to the above automatic rollback mode in the form of a flag bit.

[0073] In the above embodiment, in a Java application, database operations are usually performed through an ORM (Object Relational Mapping) layer. The ORM layer is closely associated with the transaction manager and is responsible for handling database read and write operations. In order to achieve automatic rollback during the warm-up phase, a global variable or configuration property needs to be defined in the Java application as a flag bit for the rollback mode. This flag bit is set to 0 (it can also be other specific values, such as "false") during the warm-up phase to identify that the database operations of the current application should be in the automatic rollback mode. When the warm-up module starts, it notifies the transaction manager to enter the rollback mode by setting the above flag bit to 0. After receiving the signal of this flag bit, the transaction manager will no longer perform the commit operation of the transaction, but will automatically perform the rollback operation at the end of the transaction. Through the automatic rollback mode, all database operations generated during the warm-up process will not have an actual impact on the production database, ensuring the security and integrity of the production data. Through the above implementation process, while ensuring the security of the production data, the present invention effectively warms up the Java application, improves the performance after the application starts, provides a faster transaction response speed for customers, simplifies the warm-up process, and reduces the implementation cost and complexity of the warm-up solution.

[0074] In order to avoid unnecessary resource waste, in an optional implementation manner, after the above step S203, the method further includes:

[0075] Step S401, control the above Java application to automatically exit the above warm-up mode.

[0076] In the above embodiment, the warm-up module continuously monitors the warm-up process. Once all configured simulated transaction messages are called according to their optimal transaction call times, the warm-up module will trigger a warm-up completion signal, which is usually a change in the internal state. The warm-up module updates the internal state of the Java application, indicating that the warm-up mode has ended and the application is ready to enter the normal service state. Once the Java application exits the warm-up mode, the warm-up module will trigger a start success notification. This can be a log message, a status code, or a message sent over the network to an external monitoring system, indicating that the application has been warmed up and is ready to receive real transaction requests.

[0077] When the preheating is completed, the application automatically exits the preheating mode, which can avoid unnecessary resource waste, such as the consumption of CPU and memory resources on invalid transactions. The application can quickly process real transactions from the very beginning of startup, greatly shortening the time for customers to wait for the response of the first transaction. After exiting the preheating mode, the system can concentrate resources on processing real business instead of consuming them on meaningless rollback operations, thus improving the overall resource utilization rate. The application can smoothly transition from the preheating state to the normal service state, reducing system exceptions that may be caused by improper switching of the preheating mode and ensuring the security of the production database at the same time.

[0078] To ensure the efficiency and security of transaction processing, in an optional implementation manner, after the above step S204, the method further includes:

[0079] Step S501, controlling the above Java application to provide services externally.

[0080] In the above embodiment, after the preheating is completed, it indicates that the application has switched from the preheating mode to the normal service mode and the application has started successfully. At this time, the application can provide services externally. The specific measures also include: The Java application will open a network port for listening to external requests. This usually means that the network listening service of the application will switch from the closed state to the open state and start receiving and processing requests from the client. The preheating module will notify the health check service or external monitoring system of the application, indicating that the application is ready to receive external requests, so that it can be discovered and called by the load balancer or the client. This is usually a change in the status code, a record of log information, or a status update request sent through the network. After the application status is updated and the listening port is opened, the application enters the service startup phase. At this time, all necessary components such as the business logic module, service interface, and database connection of the application have been initialized, and the application can respond to external requests and execute transaction processing. Through the above steps, after the preheating is completed, the Java application can provide services externally in the best state, ensuring the efficiency and security of transaction processing and improving the stability of the application and the satisfaction of users at the same time.

[0081] It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from here.

[0082] The embodiment of the present application also provides a Java system warm-up device based on simulated messages. It should be noted that the Java system warm-up device based on simulated messages in the embodiment of the present application can be used to execute the method for warming up a Java system based on simulated messages provided by the embodiment of the present application. This device is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0083] The following introduces the Java system warm-up device based on simulated messages provided by the embodiment of the present application.

[0084] Figure 6 is a structural block diagram of the Java system warm-up device based on simulated messages according to the embodiment of the present application. As Figure 6 shown, the device includes:

[0085] An acquisition unit 10, configured to acquire a configuration file preset in a Java application. The configuration file at least includes a plurality of simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages. The simulated transaction messages are messages of simulated transactions constructed based on real transactions.

[0086] Specifically, through requirement analysis and analysis of the transaction call situation of the old system, key high-frequency transactions are pre-identified to obtain simulated transaction messages and the corresponding optimal call times, and these simulated transaction messages are stored in the form of a configuration file. In this step, the Java application reads the preset configuration file at the initial startup. The configuration file contains a plurality of simulated transaction messages and their corresponding optimal transaction call times. The simulated transaction messages are constructed based on real transaction messages in history to simulate real transaction scenarios, and the optimal transaction call times are determined through pre-tests to be the call times that can make the JVM reach a better performance state during the warm-up stage.

[0087] Through the configuration file, the application can know which transactions need to be warmed up and how many times each transaction should be called, thus avoiding the complexity and inaccuracy of manually identifying hot code. Ensure that the application can call the hot code of the JVM through simulated transactions at the initial startup, so that the JIT just-in-time compiler can optimize and compile these codes in advance, thereby reducing the response time of the first transaction after startup and improving the initial performance of the application.

[0088] The first setting unit 20 is used to set the database layer of the Java application to the automatic rollback mode when the Java application automatically enters the warm-up mode after startup. The automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end of the transaction.

[0089] Specifically, as Figure 3 shown, after the Java application starts up and automatically enters the warm-up mode, the ORM layer (i.e., the above-mentioned database layer) sets the database to the automatic rollback mode. In the automatic rollback mode, the transaction manager does not execute the commit operation, and all database operations in the warm-up stage will be automatically rolled back at the end of the transaction, so that no trace of real data will be left in the production database.

[0090] In the warm-up stage, the automatic rollback mode ensures that the application can simulate transactions without affecting the production database, avoiding the risk of production data being contaminated by test data. The application can perform efficient performance warm-up without disturbing the data integrity of the production environment. This reduces the hidden danger of misoperation, and at the same time does not require additional shadow database resources, saving costs.

[0091] The warm-up unit 30 is used to call the corresponding simulation transaction message for warm-up according to the above-mentioned optimal transaction call times corresponding to each of the above-mentioned simulation transaction messages in the configuration file until all of the above-mentioned simulation transaction messages are called.

[0092] Specifically, the warm-up module calls the corresponding simulation transaction message for warm-up operation according to the optimal call times of each simulation transaction message in the configuration file until all the preset simulation transaction messages are called. The warm-up module is an in-built module of the application and does not depend on the capabilities of cluster communication, recovery and publishing, etc. It is embedded in the application startup process through annotation methods such as Spring's PostConstruct. Calling the simulation transaction message according to the optimal call times can ensure that the JIT compiler of the JVM fully optimizes the hot code in the application, while controlling the time-consuming of the warm-up process and avoiding resource waste caused by over-warm-up.

[0093] The second setting unit 40 is used to set the database layer to the normal commit mode and prompt that the Java application starts successfully. The normal commit mode is a mode in which the transaction manager performs the above-mentioned commit operation and does not perform the above-mentioned rollback operation at the end of the transaction.

[0094] Specifically, when all the simulated transactions in the warm-up phase are called, the warm-up module will notify the database layer to exit the automatic rollback mode and switch to the normal commit mode. At this time, the application can officially provide services externally, and the transaction data will be correctly committed to the production database. This ensures that after the warm-up is completed, the application can process real transactions correctly without any errors, all transaction data is saved, and there will be no data loss or inconsistency. At the same time, it also avoids system exceptions that may be caused by the legacy transactions in the warm-up phase.

[0095] In this embodiment, an acquisition unit acquires a configuration file preset in the Java application. The configuration file at least includes multiple simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages. The simulated transaction messages are the messages of simulated transactions constructed based on real transactions; a first setting unit is used to set the database layer of the Java application to the automatic rollback mode when the Java application automatically enters the warm-up mode after startup. The automatic rollback mode is a mode in which the transaction manager does not perform commit operations and performs rollback operations at the end position of the transaction; a warm-up unit is used to call the corresponding simulated transaction messages for warm-up according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called; a second setting unit is used to set the database layer to the normal commit mode and prompt that the Java application starts successfully. The normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end position of the transaction. This application analyzes and identifies key high-frequency transactions, simulates the real calls of these transactions, and preset the simulated transaction messages into the configuration file in the application. When the application starts, the warm-up module loads the simulated transaction messages internally and initiates transaction calls. No real data submission is made at the database layer. After the warm-up is completed, the database switches to the normal commit mode, and the application provides services externally only after it starts successfully. This application solves the problem in the prior art that the cost of human and physical resources is too high due to the dependence on the access of application nodes to the cluster and the gray release capabilities of distributed systems for warm-up.

[0096] In order to improve the warm-up efficiency and ensure that the performance of high-frequency transactions reaches the optimum after the application starts, in an optional embodiment, the device further includes:

[0097] An identification unit is used to analyze the historical transaction call situation before acquiring the configuration file preset in the Java application, and identify all high-frequency transactions;

[0098] A generation unit is used to generate the corresponding simulated transaction messages according to all the high-frequency transactions;

[0099] A determination unit is used to determine the corresponding optimal transaction call times for each of the simulated transaction messages;

[0100] A writing unit, configured to write all the above-mentioned simulated transaction messages and the corresponding above-mentioned optimal transaction call times into the above-mentioned configuration file of the above-mentioned Java application in the form of key-value pairs, and the above-mentioned configuration file is packaged and released together with the above-mentioned Java application.

[0101] In the above embodiment, it is first necessary to collect historical transaction data and analyze it. This includes, but is not limited to, viewing transaction logs, performance monitoring data, and historical transaction records, with the focus on identifying transaction types that are frequently called during actual operation. These high-frequency transactions usually have more stringent requirements for system performance and response time, so they are the key objects to be focused on during the warm-up stage. Accurately identifying high-frequency transactions that need to be warmed up ensures that the performance of these transactions can be optimized specifically during the warm-up stage. By warming up high-frequency transactions, the response time of the first transaction after startup can be significantly reduced, the user experience can be improved, and at the same time, potential business risks caused by slow first transactions can be reduced. Once high-frequency transactions are identified, next, construct simulated transaction messages for each high-frequency transaction. This usually involves a deep understanding of the transaction process and familiarity with the formats of transaction requests and response messages. The simulated transaction messages should simulate the input and output of real transactions as much as possible, including but not limited to transaction parameters, data structures, and business logics that may be involved. By constructing simulated transaction messages, a real transaction environment can be simulated during the startup stage, thereby triggering the JVM to optimize the relevant code. Enabling the JVM to quickly identify and compile and optimize the hot code in high-frequency transactions, improving the warm-up efficiency, and ensuring that the performance of high-frequency transactions reaches the optimal level after the application starts. To determine the optimal call times for each simulated transaction message, a series of experiments and tests need to be carried out. Usually, start from a relatively low warm-up times and gradually increase until the transaction response time tends to be stable. This stable point is the optimal transaction call times, aiming to ensure that the JIT compiler of the JVM can fully optimize the code, and at the same time, it will not cause too long startup time due to excessive warm-up. Determine a call times that can fully warm up and control the startup time to achieve a balance between performance optimization and efficiency. Reduce the overall time consumption during the startup stage, and at the same time ensure that the application can immediately process high-frequency transactions after startup, improving the availability and user experience of the application. Store all the generated simulated transaction messages and their respective optimal call times into the configuration file of the Java application. The configuration file is packaged together with the application and is used for subsequent reading by the warm-up module. These configuration files will contain a series of key-value pairs (in the form of key-value), where the key is the transaction code or identifier, and the value is the optimal call times of the transaction. The configuration file must be correctly packaged so that it can be read when the application starts.

[0102] To ensure that the application can enter the optimal performance state immediately after each startup, while avoiding the problem of excessive startup time caused by over-preheating, in an optional implementation manner, the determination unit includes:

[0103] A setting module for setting the initial number of transaction calls;

[0104] A preheating module for performing a preheating step, preheating according to the above initial number of transaction calls until the preheating of the above Java application is completed, and obtaining the time consumption of the first transaction corresponding to the above initial number of transaction calls;

[0105] A judgment module for performing a judgment step to judge whether the time consumption of the first transaction converges;

[0106] An increasing module for performing an increasing step. In the case where the time consumption of the first transaction does not converge, increase the above initial number of transaction calls, and repeat the above preheating step, the above judgment step, and the above increasing step at least once;

[0107] A determination module for determining the above initial number of transaction calls as the above optimal number of transaction calls in the case where the time consumption of the first transaction converges.

[0108] In the above embodiment, the number of calls corresponding to the transaction should be as small as possible to avoid increasing the overall startup time. Therefore, a reasonable value of the optimal number of transaction calls is given after verification through a test environment during the transaction development stage (before the application starts). This process dynamically adjusts the number of preheating times of the simulated transaction to reach a balance point that can effectively preheat the system without excessively increasing the startup time, as Figure 5As shown, first set a relatively small initial value (such as 5 times). After the warm-up is completed, measure the time taken for the first transaction. After obtaining the data on the time taken for the first transaction, enter the judgment step to evaluate whether the time consumption tends to be stable. This is usually done by comparing the current time consumption with the time consumption after the previous warm-ups to determine whether the time consumption curve converges, that is, whether the time consumption tends to a stable value and there are no significant changes. Determine whether the warm-up process has enabled the JVM to reach a state of stable performance. This can avoid unnecessary increases in the number of warm-up times while ensuring that the warm-up process does have a significant optimization effect on the time taken for the first transaction. If it is found in the judgment step that the time taken for the first transaction does not converge, that is, the time consumption still has large fluctuations or room for decrease, then increase the number of initial transaction calls and repeat the warm-up step and the judgment step until the time consumption curve converges. When the time taken for the first transaction tends to be stable, it is the reasonable value for the number of transaction calls in the warm-up phase. Determine an exact optimal number of transaction calls to optimize the response time of the first transaction after the application starts. Ensure that the application can immediately enter the optimal performance state every time it starts, provide fast-response transaction processing, improve the overall system performance and user experience, and at the same time avoid the problem of too long start-up time caused by excessive warm-up. As shown in Table 1, the optimal number of transaction calls is 9 times.

[0109] Table 1

[0110]

[0111] In order to ensure that the application reaches a good performance state at startup and avoid the problem of slow first transaction, in an optional implementation manner, the above warm-up unit includes:

[0112] A loading module for loading the above configuration file and sequentially reading all the above simulation transaction messages;

[0113] A calling module for initiating a transaction simulation operation according to the above optimal number of transaction calls of the above simulation transaction messages to call the corresponding above simulation transaction messages until all the above simulation transaction messages are called.

[0114] In the above embodiments, after the Java application starts and enters the warm-up mode, the warm-up module will automatically load the previously prepared configuration file. The configuration file contains simulated transaction messages and their corresponding optimal transaction call counts. The warm-up module reads them one by one in the order of the transaction messages in the configuration file, which ensures that the warm-up process proceeds orderly according to the pre-set plan. Load the configuration file, parse the key-value pairs in it, and obtain the identifiers of the simulated transaction messages and the optimal transaction call counts. Process the information of each transaction message one by one in the order of the transaction messages in the configuration file. Ensure that the warm-up module can correctly read the configuration information, know which transaction messages should be warmed up, and how many times each message should be called, so as to perform the warm-up purposefully. Through the orderly reading of the configuration file, the warm-up process can be precisely controlled, avoiding the problems of insufficient warm-up or over-warm-up that may be caused by random warm-up, and improving the efficiency and pertinence of warm-up. For each simulated transaction message read from the configuration file, the warm-up module calls the business logic of the corresponding transaction according to the value of the optimal call count. The execution of the simulated transaction includes, but is not limited to, calling the ORM layer, accessing the database, executing business logic, etc., but all database operations will be automatically rolled back at the end position of the transaction and will not affect the production database. Repeat the above operations until all the configured simulated transaction messages are called according to their optimal transaction call counts. Realize the warm-up of the JVM virtual machine to ensure that the JIT just-in-time compiler can fully optimize and compile the hot code of high-frequency transactions to reach the best performance state. Through the call of the simulated transaction message, the JVM can recognize which are the hot codes at the initial stage of the application startup and quickly optimize them. This can significantly reduce the response time of the first transaction after the application starts, thereby improving the overall performance and user experience of the application. Through the above steps, the warm-up module can automatically and orderly execute the warm-up operation, ensure that the application reaches a good performance state at startup, avoid the problem of slow first transaction, and at the same time protect the production database from the influence of the warm-up process. This method not only simplifies the warm-up process, reduces the labor cost, but also improves the availability and response speed of the application, and is an effective means to solve the Java application startup performance problem.

[0115] In order to reduce the implementation cost and complexity of the warm-up solution, in an optional implementation manner, the above first setting unit includes:

[0116] A setting module for setting the database layer of the above Java application to the above automatic rollback mode in the form of a flag bit.

[0117] In the above embodiments, in a Java application, database operations are usually performed through an ORM (Object Relational Mapping) layer. The ORM layer is closely associated with the transaction manager and is responsible for handling database read and write operations. To achieve automatic rollback during the warm-up phase, a global variable or configuration property needs to be defined in the Java application as a flag for the rollback mode. This flag is set to 0 (or other specific values, such as "false") during the warm-up phase to indicate that the database operations of the current application should be in the automatic rollback mode. When the warm-up module starts, it notifies the transaction manager to enter the rollback mode by setting the above flag to 0. After receiving the signal of this flag, the transaction manager will no longer perform the commit operation of the transaction, but will automatically perform the rollback operation at the end of the transaction. Through the automatic rollback mode, all database operations generated during the warm-up process will not have an actual impact on the production database, ensuring the security and integrity of the production data. Through the above implementation process, while ensuring the security of production data, the present invention realizes the effective warm-up of the Java application, improves the performance after the application starts, provides a faster transaction response speed for customers, simplifies the warm-up process, and reduces the implementation cost and complexity of the warm-up solution.

[0118] To avoid unnecessary resource waste, in an alternative embodiment, the apparatus further includes:

[0119] A first control unit, configured to, after invoking the above simulation transaction messages for warm-up according to the above optimal transaction invocation times in the above configuration file until all the above simulation transaction messages are invoked, control the above Java application to automatically exit the above warm-up mode.

[0120] In the above embodiments, the warm-up module continuously monitors the warm-up process. Once all the configured simulation transaction messages are invoked according to their optimal transaction invocation times, the warm-up module triggers a warm-up completion signal, which is usually a change in the internal state. The warm-up module updates the internal state of the Java application, indicating that the warm-up mode has ended and the application is ready to enter the normal service state. Once the Java application exits the warm-up mode, the warm-up module triggers a start success notification. This can be a log message, a status code, or a message sent over the network to an external monitoring system, indicating that the application has been warmed up and is ready to receive real transaction requests.

[0121] When the preheating is completed, the application automatically exits the preheating mode, which can avoid unnecessary resource waste, such as the consumption of CPU and memory resources on invalid transactions. The application can quickly process real transactions from the very beginning of startup, greatly shortening the time for customers to wait for the response of the first transaction. After exiting the preheating mode, the system can concentrate resources on processing real business instead of wasting them on meaningless rollback operations, thus improving the overall resource utilization rate. The application can smoothly transition from the preheating state to the normal service state, reducing system exceptions that may be caused by improper switching of the preheating mode and ensuring the security of the production database at the same time.

[0122] To ensure the efficiency and security of transaction processing, in an optional implementation, the device further includes:

[0123] A second control unit, configured to control the above-mentioned Java application to provide services externally after prompting that the above-mentioned Java application has started successfully.

[0124] In the above embodiment, after the preheating is completed, it indicates that the application has switched from the preheating mode to the normal service mode and the application has started successfully. At this time, the application can provide services externally. Specific measures also include: The Java application will open a network port for listening to external requests. This usually means that the network listening service of the application will switch from the closed state to the open state and start receiving and processing requests from clients. The preheating module will notify the health check service or external monitoring system of the application, indicating that the application is ready to receive external requests, so that it can be discovered and called by the load balancer or the client. This is usually a change in the status code, a record of log information, or a status update request sent over the network. After the application status is updated and the listening port is opened, the application enters the service startup phase. At this time, all necessary components such as the business logic module, service interface, and database connection of the application have been initialized, and the application can respond to external requests and execute transaction processing. Through the above steps, after the preheating of the Java application is completed, it can provide services externally in the best state, ensuring the efficiency and security of transaction processing, and improving the stability of the application and the satisfaction of users at the same time.

[0125] The above-mentioned Java system preheating device based on simulated messages includes a processor and a memory. The above-mentioned acquisition unit, first setting unit, preheating unit, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to implement corresponding functions. The above-mentioned modules are all located in the same processor; or, the above-mentioned each module is located in different processors in any combination form.

[0126] The processor contains a kernel, which retrieves the corresponding program units from the memory. One or more kernels can be set, and by adjusting the kernel parameters, the problems of high human and physical resource costs caused by relying on application nodes to access the cluster and the gray release capabilities of distributed systems for preheating in the prior art can be solved.

[0127] The memory may include non - permanent memory in a computer - readable medium, in the form of random access memory (RAM) and / or non - volatile memory, such as read - only memory (ROM) or flash RAM. The memory includes at least one storage chip.

[0128] An embodiment of the present invention provides a computer - readable storage medium. The above - mentioned computer - readable storage medium includes a stored program. When the above - mentioned program runs, it controls the device where the computer - readable storage medium is located to execute the above - mentioned Java system preheating method based on simulated messages.

[0129] Specifically, the Java system preheating method based on simulated messages includes:

[0130] Step S201, obtain the configuration file preset in the Java application. The above - mentioned configuration file includes at least a plurality of simulated transaction messages and the corresponding optimal transaction call times for each of the above - mentioned simulated transaction messages. The above - mentioned simulated transaction messages are messages of simulated transactions constructed according to real transactions;

[0131] Step S202, when the above - mentioned Java application automatically enters the preheating mode after startup, set the database layer of the above - mentioned Java application to the automatic rollback mode. The above - mentioned automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction;

[0132] Step S203, call the corresponding above - mentioned simulated transaction messages for preheating according to the above - mentioned optimal transaction call times corresponding to each of the above - mentioned simulated transaction messages in the above - mentioned configuration file until all the above - mentioned simulated transaction messages are called;

[0133] Step S204, set the above - mentioned database layer to the normal commit mode and prompt that the above - mentioned Java application starts successfully. The above - mentioned normal commit mode is a mode in which the above - mentioned transaction manager performs the above - mentioned commit operation and does not perform the above - mentioned rollback operation at the end position of the transaction.

[0134] An embodiment of the present invention provides a processor. The above - mentioned processor is used to run a program. When the above - mentioned program runs, it executes the above - mentioned Java system preheating method based on simulated messages.

[0135] Specifically, the Java system preheating method based on simulated messages includes:

[0136] Step S201: Obtain the configuration file preset in the Java application. The configuration file includes at least multiple simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages. The simulated transaction messages are the messages of simulated transactions constructed based on real transactions.

[0137] Step S202: When the Java application automatically enters the warm-up mode after startup, set the database layer of the Java application to the automatic rollback mode. The automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end of the transaction.

[0138] Step S203: Call the corresponding simulated transaction messages for warm-up according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called.

[0139] Step S204: Set the database layer to the normal commit mode and prompt that the Java application has started successfully. The normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end of the transaction.

[0140] An embodiment of the present invention provides a Java system. The Java system includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements at least the following steps:

[0141] Step S201: Obtain the configuration file preset in the Java application. The configuration file includes at least multiple simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages. The simulated transaction messages are the messages of simulated transactions constructed based on real transactions.

[0142] Step S202: When the Java application automatically enters the warm-up mode after startup, set the database layer of the Java application to the automatic rollback mode. The automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end of the transaction.

[0143] Step S203: Call the corresponding simulated transaction messages for warm-up according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called.

[0144] Step S204: Set the database layer to the normal commit mode and prompt that the Java application has started successfully. The normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end of the transaction.

[0145] The present application also provides a computer program product which, when executed on a data processing device, is adapted to execute a program initialized with at least the following method steps:

[0146] Step S201: Obtain a configuration file pre-set in the Java application. The configuration file at least includes a plurality of simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages. The simulated transaction messages are messages of simulated transactions constructed according to real transactions;

[0147] Step S202: When the Java application automatically enters the warm-up mode after startup, set the database layer of the Java application to the automatic rollback mode. The automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction;

[0148] Step S203: Call the corresponding simulated transaction messages for warm-up according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called;

[0149] Step S204: Set the database layer to the normal commit mode and prompt that the Java application has started successfully. The normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end position of the transaction.

[0150] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present invention can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order from here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to implement. In this way, the present invention is not limited to any specific combination of hardware and software.

[0151] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0152] This application is described with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of flows and / or blocks in the flowchart and / or block diagram can also be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in one or more flows Figure 1 or more flows and / or blocks Figure 1 or means for implementing the functions specified in one or more blocks.

[0153] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means implement the functions specified in one or more flows Figure 1 or more flows and / or blocks Figure 1 or means for implementing the functions specified in one or more blocks.

[0154] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flows Figure 1 or more flows and / or blocks Figure 1 or means for implementing the functions specified in one or more blocks.

[0155] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

[0156] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0157] A computer-readable medium includes both permanent and non-permanent, removable and non-removable media and can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic tape disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0158] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising the element.

[0159] From the above description, it can be seen that the above embodiments of the present application achieve the following technical effects:

[0160] 1), The Java system warm-up method based on simulated messages in this application. First, obtain the configuration file pre-set in the Java application. The above configuration file includes at least multiple simulated transaction messages and the corresponding optimal transaction call times for each of the above simulated transaction messages. The above simulated transaction messages are the messages of simulated transactions constructed according to real transactions. Then, when the above Java application automatically enters the warm-up mode after startup, set the database layer of the above Java application to the automatic rollback mode. The above automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction. After that, call the corresponding above simulated transaction messages for warm-up according to the above optimal transaction call times corresponding to each of the above simulated transaction messages in the configuration file until all the above simulated transaction messages are called. Finally, set the above database layer to the normal commit mode and prompt that the above Java application starts successfully. The above normal commit mode is a mode in which the above transaction manager performs the above commit operation and does not perform the above rollback operation at the end position of the transaction. This application analyzes and identifies key high-frequency transactions, simulates the real calls of these transactions, and pre-sets the simulated transaction messages in the configuration file within the application. When the application starts, the warm-up module loads the simulated transaction messages internally and initiates transaction calls. No real data submission is made at the database layer. After warm-up is completed, the database is switched to the normal commit mode, and the application provides services externally only after it starts successfully. This application solves the problem in the prior art that it depends on the access of application nodes to the cluster and the capabilities such as the gray release of the distributed system to warm up, resulting in too high human and physical resource costs.

[0161] 2) The Java system warm-up device based on simulated messages of the present application, the acquisition unit acquires the configuration file preset by the Java application. The configuration file at least includes a plurality of simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages. The simulated transaction messages are the messages of simulated transactions constructed according to real transactions; the first setting unit is used to set the database layer of the Java application to the automatic rollback mode when the Java application automatically enters the warm-up mode after startup. The automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction; the warm-up unit is used to call the corresponding simulated transaction messages for warm-up according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called; the second setting unit is used to set the database layer to the normal commit mode and prompt that the Java application starts successfully. The normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end position of the transaction. The present application identifies key high-frequency transactions through analysis, simulates the real calls of these transactions, and preset the simulated transaction messages into the configuration file in the application. When the application starts, the warm-up module loads the simulated transaction messages internally and initiates transaction calls. No real data submission is made at the database layer. After the warm-up is completed, the database is switched to the normal commit mode, and the application provides services externally only after it starts successfully. The present application solves the problem in the prior art that it relies on the ability of application nodes to access the cluster and the gray release of the distributed system to warm up, resulting in too high human and physical resource costs.

[0162] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A Java system preheating method based on simulated messages, characterized in that, Including: Obtain a configuration file preset in the Java application, where the configuration file includes at least multiple simulated transaction messages and the corresponding optimal transaction call times for each of the simulated transaction messages, and the simulated transaction messages are messages of simulated transactions constructed based on real transactions; When the Java application automatically enters the warm-up mode after startup, set the database layer of the Java application to the automatic rollback mode, where the automatic rollback mode is a mode in which the transaction manager does not perform a commit operation and performs a rollback operation at the end position of the transaction; Call the corresponding simulated transaction message for warm-up according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called; Set the database layer to the normal commit mode and prompt that the Java application has started successfully, where the normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end position of the transaction.

2. The method according to claim 1, characterized in that, Before obtaining the configuration file preset in the Java application, the method further includes: Analyze the historical transaction call situation to identify all high-frequency transactions; Generate the corresponding simulated transaction messages according to all the high-frequency transactions; Determine the optimal transaction call times corresponding to the simulated transaction messages; Write all the simulated transaction messages and the corresponding optimal transaction call times into the configuration file of the Java application in the form of key-value pairs, and the configuration file is packaged and released together with the Java application.

3. The method according to claim 2, wherein Determining the optimal transaction call times corresponding to the simulated transaction messages includes: Set an initial transaction call time; A warm-up step, perform warm-up according to the initial transaction call time until the warm-up of the Java application is completed, and obtain the first transaction time-consuming corresponding to the initial transaction call time; A judgment step, judge whether the first transaction time-consuming converges; An increment step, in the case where the first transaction time-consuming does not converge, increment the initial transaction call time, and repeat the warm-up step, the judgment step, and the increment step at least once; In the case where the first transaction time-consuming converges, determine the initial transaction call time as the optimal transaction call time.

4. The method according to claim 1, characterized in that, Calling the corresponding simulated transaction message for warm-up according to the optimal transaction call times corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages are called, includes: Load the configuration file and read all the simulated transaction messages in sequence; Initiate a transaction simulation operation according to the optimal transaction call times of the simulated transaction messages to call the corresponding simulated transaction messages until all the simulated transaction messages are called.

5. The method according to claim 1, wherein Setting the database layer of the Java application to the automatic rollback mode includes: Set the database layer of the Java application to the automatic rollback mode in the form of a flag bit.

6. The method according to claim 1, wherein After invoking the simulated transaction messages for warm-up according to the number of times of the best transaction invocations in the configuration file until all the simulated transaction messages have been invoked, the method further includes: Controlling the Java application to automatically exit the warm-up mode.

7. The method according to claim 1, characterized in that, After prompting that the Java application has been successfully started, the method further includes: Controlling the Java application to provide services externally.

8. A Java system preheating device based on simulation messages, characterized in that, The apparatus includes: An acquisition unit that acquires a configuration file preset in a Java application, where the configuration file at least includes a plurality of simulated transaction messages and the corresponding number of times of the best transaction invocations for each of the simulated transaction messages, and the simulated transaction messages are messages of simulated transactions constructed according to real transactions; A first setting unit, configured to set the database layer of the Java application to an automatic rollback mode when the Java application automatically enters a warm-up mode after startup, where the automatic rollback mode is a mode in which a transaction manager does not perform a commit operation and performs a rollback operation at the end position of a transaction; A warm-up unit, configured to invoke the corresponding simulated transaction messages for warm-up according to the number of times of the best transaction invocations corresponding to the simulated transaction messages in the configuration file until all the simulated transaction messages have been invoked; A second setting unit, configured to set the database layer to a normal commit mode and prompt that the Java application has been successfully started, where the normal commit mode is a mode in which the transaction manager performs the commit operation and does not perform the rollback operation at the end position of the transaction.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, where, when the program runs, it controls the device where the computer-readable storage medium is located to execute the method according to any one of claims 1 to 7.

10. A computer program product comprising computer instructions, characterized in that, The computer instructions, when executed by a processor, implement the method according to any one of claims 1 to 7.

Images