WO2012031419A1

WO2012031419A1 - Fine-grained performance modeling method for web application and system thereof

Info

Publication number: WO2012031419A1
Application number: PCT/CN2010/078104
Authority: WO
Inventors: 王伟; 黄翔; 张文博; 魏峻; 钟华; 黄涛
Original assignee: 中国科学院软件研究所
Priority date: 2010-09-07
Filing date: 2010-10-26
Publication date: 2012-03-15
Also published as: CN101916321B; CN101916321A

Abstract

A fine-grained performance modeling method for a web application and a system thereof are disclosed. The modeling method comprises: 1) setting an updating period for a middleware platform of the web application system; 2) extracting operating data of the middleware platform of the web application system in one updating period; 3) obtaining performance date of the middleware platform of the web application system according to the operating data; 4) generating and displaying a layered queuing network performance model of the web application system according to the current performance data. The modeling system comprises a status updating module, a log loading module and an analyzing module. The modeling system and method construct performance model automatically based on the operating data monitored by the web application platform and a statistical mode without the participation of humans, and carry out updates along with the changes of the system status. The granularity of the constructed model follows the standard web application component model, can be applied in various web application platforms; thereby the usage of the web application system can be truly reflected.

Description

Web application fine-grained performance modeling method and system thereof

The invention relates to a web application performance modeling technology, in particular to a modeling method and a modeling system for constructing an adaptive web application fine-grained performance model based on a hierarchical queuing network. Background technique

Multi-layered Web applications have become mainstream web applications. A large number of key applications (e-banking, online payment, etc.) are implemented using Web applications, and it is important to guarantee system quality of service (QoS) for a long period of time. At present, it is customary to predict the performance of the system in the future by constructing a performance model, and then use the prediction results as a guide to judge whether the system performance meets the service quality requirements.

The basic principle of performance prediction is to analyze the performance of the system by simulating the situation of real system queuing and resource competition. Inputs typically include data such as user behavior, component associations, and resource consumption. Output performance data includes throughput, response time, and resource utilization.

According to the degree of abstraction of the simulated real system, the prediction method can be divided into two types: coarse granularity and fine granularity. The coarse-grained approach focuses on portraying the behavior of the server, which is to study the resource consumption of the server and server at the macro level. This method is relatively simple to model and is suitable for analyzing the overall performance of multiple servers under clusters. But this approach does not consider how a single software component consumes resources and how components and components are related. Therefore, the prediction results do not reflect the resource consumption of the software components, and thus cannot provide useful data for discovering performance problems on the software structure. The basis of the fine-grained method is the execution structure diagram of the software, that is, the call and resource consumption between important components in the system. So in addition to predicting the performance of individual software components, the fine-grained approach predicts the overall performance of the system.

But because the fine-grained approach requires an understanding of the details of the software, the modeling process is much more complicated than the coarse-grained approach. Because at this time, designers need not only to understand the overall design of the software, but also to understand the user behavior and resource consumption, which leads to the cost of constructing a fine-grained model is very expensive.

There have been some studies aimed at reducing the cost of constructing Web application performance models, either for one of them or for coarse-grained methods, but they are not fully systematically providing capacity planners with a fast and efficient Web-oriented performance. Modeling method.

Wi ll iam and Smith first proposed a software-based performance engineering approach (CU Smith and LG Wi ia iams, Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software. Addison Wesley, 2002) to introduce performance analysis into the software development process. in. Gomaa and Menashe proposed a method based on the "client/server" system model (H. Gomaa and D. Menasce, Performance Engineering of Component-Based Distributed Software Systems, Performance Eng., R. Dumke et al., eds. pp. 40-55, 2001. The method directly uses the class diagram and the collaboration diagram to describe the interaction form between components to generate an extended queuing network (EQN) model. The above method reduces the difficulty of constructing the performance model, but the correct parameters required to obtain the model is still a problem, and the performance model also needs other parameters such as service time and user behavior.

Woodside et al. proposed a method for automatically generating LQN models by inserting and collecting execution trajectory code from a software design environment (M. Woodside, C. Hrischuk, B. Sel ic, and S. Brayarov, Automated Performance Model ing of Software Generated by a Design Environment, Performance Evaluation, vol. 45, pp. 107-123, 2001.). This method inserts code into the source code based on the abstraction level given by the designer, and collects the execution trajectory and resource consumption exhibited by the software under the given test case. However, it is only suitable for development software, and is not suitable for running web applications.

Yoshihira and Jiang proposed a method based on monitoring data to discover stable relationships in systems (Guofei Jiang, Haifeng Chen, Kenj i Yoshihira, Efficient and Scalable Algorithms for Inferring Likely Invariants in Distributed Systems, IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL 19, NO. 11, NOVEMBER (2007) 1508-1523). They collect the stable consumption of the components by collecting the resource consumption of the components in the request processing process, and then analyze the processing power of the system according to the established associated network, find the bottleneck, and then do capacity planning. However, only the scalability of the system can be predicted, and the performance of the system cannot be predicted.

Cherkasova et al. proposed a transaction-based capacity planning method (L. Cherkasova, Kivanc Ozonat, Automated Anomaly Detection and Performance Model ing of Enterprise Appl ications, ACM Transactions on Computer Systems, Vol. 27, No. 3, November 2009. ). Similar to this stone research, they also treat a user's HTTP request as a transaction. However, their method still uses the request as the basic unit. This article focuses on the components, which is more conducive to the discovery of performance problems at the component level. Summary of the invention

In view of the above problems, the present invention designs a system and method for automatically constructing a performance model based on monitoring data according to the characteristics of the Web application system and its platform. In the present invention, the log information that can be collected by the web application platform is based on a statistical method, and the technology of trajectory tracking, service time calculation and user behavior simulation is transparently constructed to enable fine-grained prediction. Performance model for system performance.

The technical basis of the invention is the monitoring technology that the web application platform system can provide, and the acquisition mainly includes three types of log data, one is the execution trajectory of the service (called a call chain); the other is the total utilization of the CPU, specifically refers to a single server. CPU utilization, if the server has multiple cores, the usage of all cores is accumulated; one is the user's use of the system's trajectory. Specific In order to respond to a request from a user (a complete request processing and a response process is called a transaction), the web application invokes a series of components to collaborate to do the work, and the execution flow of the component that performs the work is called the call chain. For example, the Servlet component calls the EJB component, and the EJB component calls the database. The user's use of the system's trajectory (referred to as user behavior) refers to all actions from the user's first login to the application to the last access to the application, generally including multiple requests for different pages of the system. There are many commercial and open source tools to support this type of monitoring, such as Oracle's Weblogic Diagnostics Framework, the open source InfraRED tool (http://infrared.sourceforge.neO, and the stone research paper (Curtis E.) Hrischuk, Murray Woodside. Trace-Based Load Characterization for Generating Performance Software Models. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 1, JANUARY/FEBRUARY 1999), etc. Therefore, the present invention will not address the description of the monitoring technique, specifically Implementation can refer to these methods.

The process of predicting performance using the present invention is completely transparent and automatic to system maintenance personnel, requiring no manual intervention. After the system is started, the performance model is automatically constructed and updated based on the input log information. When predictive results are needed, maintenance personnel only need to call the analysis function to get the future performance of the system. The predicted results include the throughput rate of the system, the response time, the resource utilization of each software component and the total resource utilization, and the resource utilization of each hardware resource.

One of the objectives of the present invention is to provide a method for modeling fine-grained performance of a web application, comprising the following steps:

1) setting the update period of the web application middleware platform;

2) Obtaining the running data of the web application middleware platform in an update cycle;

3) calculating performance data of the web application middleware platform according to the running data;

4) Generate and display a hierarchical queuing network performance model of the web application system based on current performance data.

The web application system running data includes execution trajectory data, total CPU utilization, and trajectory data of the user using the system. Execution trajectory data is the execution flow of a series of components called the call chain for the system to complete the request made by the user.

The performance data includes a derived vector of execution maps, deployment status data, service time, and user behavior pattern maps. Deployment status data refers to the location of each component on the server in the web application. Service time refers to the actual execution time of a functional service (such as a function) that the component provides to the outbound service, without waiting time.

The execution trajectory data is represented by a call chain, wherein the node is a component, the edge is a calling relationship between components, the solid line indicates a synchronization request, the dotted line indicates an asynchronous request, and the number indicates the number of calls.

An execution map of a transaction is obtained by merging a peer node of each call chain of a transaction (ie, the same call chain of the first node), the peer node being that the two nodes α and β satisfy the following conditions :

Two nodes α and β represent the same entry, and

Or the parent node of α and the parent node of β are peer nodes, and the request type of the parent node to α and β is the same; Or α = β and the parent nodes of α and β are empty.

Among them, the user's HTTP request is a transaction.

The component deployment status data is obtained by analyzing the IP address of the server where each component on the execution track is located.

The Kalman filtering method is used to calculate the execution time of each component providing service to obtain the service time.

Kalman filtering provides a general method for estimating the unobservable state X at discrete points in time. The k-th time state can be defined as a linear stochastic difference equation:

3⁄4 = Ίι + + w -i (L a) The total CPU utilization observed at time k is defined as: - ff3⁄4■!■ 3⁄4 (1. b) where A is the state transition matrix from k-1 to k , -i is an optional control parameter, B is a matrix related to control, Mfe is a measurement error, and its covariance matrix is Q _M . ^ is the conversion matrix to, ι3⁄4 is the measurement error, and its covariance matrix is Rk. By mapping the formulas (1. a) and (1. b) as follows, the service time of each component service at time k can be obtained: xk = Xk-i + ^w fc- 1 (2. a)

Where = xl -.. 1 , which represents the service time of each component service at time _k , _a is the total CPU utilization, and t is the throughput rate of each service. According to the CPU utilization rule, there is a formula (2. b), that is, the total CPU utilization is equal to the cumulative sum of the product throughput and the service time product.

The above two formulas are iteratively calculated to obtain the service time.

The method for converting the user's use of the system's trajectory data into a derived vector is:

Formula

3⁄4 =∑S 3⁄4 ^X Vk, _{} i} I = i,... " + Ϊ Convert to matrix form:

V - ί = ν ρ where 1⁄4 is the number of times each transaction was accessed in a request, =ι _; ΐ = (ΐΑ..., 0) Solving the linear equations corresponding to the matrix form formula, and obtaining the derived vector V.

The method for generating the hierarchical queuing network performance model is:

Converting a single execution graph into a preliminary hierarchical queuing network model, where the nodes performing the graph are converted into LQN entries (Entry); the services of the same node are merged into one LQN model task (Task), generating hierarchical queuing of individual services Net model

Second, attach the deployment status data of each component to the model;

Third, add service time to the model;

Fourth, the load is generated according to the derived vector of the user behavior pattern diagram, and the hierarchical queued network model of the single service is combined into a complete hierarchical queued network performance model. An object of the present invention is to provide a fine-grained performance modeling system for a web application system, including:

The status update module sets an update period of the web application middleware platform, and calculates performance data according to the operation data of the web application system in each update period;

a log loading module, extracting running data in each update cycle and loading a status update module;

The analysis module generates and displays a hierarchical queuing network performance model of the web application system according to the current performance data. The status update module includes an execution graph analyzer, a deployment analyzer, a service time analyzer, and a user behavior simplifier. Executing the graph analyzer to calculate the overall execution path of an event by executing the trajectory data calculation web application system; obtaining the execution map;

The deployment analyzer extracts location data of each component in the execution trajectory data on the server, and obtains the component deployment status data;

The service time analyzer calculates the execution time of each component of the web application system to obtain the service time, and the user behavior reducer converts the trajectory data of the user using the system into a derivative vector of the user behavior pattern diagram.

The log load module includes a track information loader, a CPU utilization loader, and a user behavior loader, and the track information loader loads execution track data; the CPU utilization loader loads the total of the system server CPU. Utilization; User Behavior Loader loads the trajectory data used by the user from login to exit.

The above performance modeling methods are periodically updated as the system operates to ensure that the state of the performance model can change as the system changes. When the maintenance personnel expect to predict the future performance of the system, the prediction step can be triggered to obtain future performance models by using performance data such as execution maps and deployment state data in the state storage module. The performance model of this study is based on a hierarchical queuing network (M. Woodside, "The Stochastic Rendezvous Network Model for Performance of Synchronous Cl ient-Server Like Distributed Software", IEEE Transactions on Computers, Vol. 44, No. 1, January 1995, pp. 20-34), the biggest advantage of this model is that it can describe the use of resources hierarchically, in line with the needs of fine-grained performance analysis.

The invention provides a performance modeling system and method for a web application platform, the advantages of which are as follows:

1) Automatically construct a performance model without human intervention;

2) The model structure is based on the operational data and statistical methods monitored by the Web application platform, and can be automatically updated as the system status changes;

3) Model granularity follows the standard Web application component model, using a variety of Web application platforms;

4) The model simplifies the user behavior (ie, load) into a model acceptable to the hierarchical queuing network model, which can truly reflect the use of the Web application system;

5) The performance of the future of the Web application system can provide multiple levels of performance data such as software components, server nodes and clusters. DRAWINGS

FIG. 1 is a flow chart of a performance modeling method in an embodiment of the present invention.

FIG. 2 is a structural block diagram of a performance modeling system according to an embodiment of the present invention.

FIG. 3 is an example of a call chain used in an embodiment of the present invention.

4 is an execution diagram of the call chain of FIG. 3 generated by the method and system of the present invention.

Figure 5 is a diagram of a hierarchical queuing network model generated by the execution map of Figure 4 in an embodiment of the present invention.

Figure 6 is a hierarchical queued network model diagram with the deployment state data appended to Figure 5.

Figure 7 is a diagram of a hierarchical queuing network model after adding service time in Figure 6.

FIG. 8 is a load diagram of a derived vector generation of a user behavior pattern diagram in an embodiment of the present invention.

Figure 9 is a complete hierarchical queued network model diagram of the embodiment. detailed description

The technical solution of the present invention will be described below with reference to the accompanying drawings and specific embodiments.

The present invention is based on a standard component model supported by Web application middleware (such as Servlet, EJB, SQL, etc.), automatically calculates performance data through monitored operational data and statistical methods, and finally generates a performance model. The main monitoring data includes the call chain, the total CPU utilization and the trajectory of the user's use of the system. The invention mainly relates to two modules, one is a state update module for monitoring and processing data, and the other is an analysis module, which can build a performance model by using the detected operational data, and predict the future performance state of the web application, which is user and maintenance. People interacting.

The status update module is mainly responsible for monitoring the execution of the web application, and obtaining the running data by analyzing the log information. Constructs execution diagrams, gets deployment state data, calculates service time, and simplifies user behavior. On the other hand, the analysis module, after receiving the command from the maintenance personnel, constructs a performance model that conforms to the latest state of the system by loading the latest performance data, and then calculates and analyzes the future performance of the system.

The overall method for obtaining performance data and constructing a performance model by using the Web application system middleware platform to monitor operational data;

1) setting the update period of the web application middleware platform;

The specific implementation process of the present invention is shown in FIG. The performance data is the link between data processing and performance analysis. When the running data is processed, it is saved as performance data, and when performance needs to be analyzed, it is extracted from it for analysis.

The specific operational data is the execution trajectory data, the total utilization of the CPU, and the trajectory data of the user using the system. Performance data includes derived vectors for execution graphs, deployment state data, service time, and user behavior pattern diagrams. The acquisition of each performance data is described in detail below in connection with the system of the present invention.

In order to achieve the above process, the system of the present invention should at least include

The analysis module generates and displays a hierarchical queuing network performance model of the web application system according to the current performance data.

However, in order to obtain a better invention effect, the present embodiment employs the overall structure as shown in FIG. The main module has five parts: initial module, log load module, status update module, state storage module and analysis module. Among them, the status update module is the core of the entire algorithm, responsible for the key data required for production forecasting. The small arrows in the figure indicate that data is taken from the direction of the arrow, such as the user behavior simplifier getting data from the user behavior loader. Large arrows indicate the order of execution.

First, the initial module is primarily responsible for determining the web application middleware platform to be monitored. The purpose of determining the pending middleware platform is to facilitate the normal operation of the log load module. Because there are some differences in the different middleware platforms, the monitoring tools on them will have some differences. In order to obtain the required operational data, it is necessary. Make a little adjustment to the specificity. However, the basic principles of these schemes are consistent, and as mentioned above, there are many achievements in the fields of open source, commerce, and research. Therefore, the method of monitoring is not specifically described here. The required monitoring data format is described in the log load module.

Second, the log load module is mainly responsible for loading the operational data monitored by the middleware into the system of the invention, organizing The format required by the cost invention provides data for the status update module. The module includes three sub-modules: Trace Information Loader, CPU Utilization Loader, User Behavior Loader.

The trace information loader loads the data associated with the call chain and organizes it into the format required for the study. Figure 3 shows the different call chain structures for a transaction specifically used by the present invention. A node represents a component, an edge represents a call relationship between components, a solid line represents a synchronization request, a dashed line represents an asynchronous request, and a number represents the number of calls. For example, CO represents the starting component of the transaction, r0 represents the number of user requests, and r0_l represents the number of times the CO component calls the C1 component. For example, 301 in FIG. 3 indicates that the user requests the service provided by the component CO, and the component CO calls the component C1, and the component C1 calls the components C2 and C3 successively; 304 indicates that the user requests the service provided by the component CO, and the component The CO calls component C4 asynchronously, and component C1 calls component Cl again. In addition, the track contains the IP information of the server where each component is located.

The CPU utilization loader is mainly responsible for the total utilization of the server CPU periodically loaded. This study collects in seconds. The format of each record is: time _: [ _V . ~ _Vn ]. Each record begins with the time of recording, followed by a record of the CPU utilization of each core. If it is a traditional single-core CPU, the number of data elements is one, and if it is a multi-core CPU, the number of data elements is the same as the number of cores.

The user behavior loader is primarily responsible for loading the user's trajectory from the login to the exit process. Can be described as a user behavior pattern diagram (D. Menasce, V. Almeida, A Methodology for Workload Characterization of E-commerce Sites, Proceedings of ACM E-Commerce 1999 (pp. 119 - 128), which can be expressed as a matrix P =[p, the matrix of the shoulder of the J. Indicates the probability of a transaction J after a transaction i in a session (a login period of a user), o ≤ W ≤ + i. where, multi-identity session start, event / identification The session is terminated. The transaction corresponds to a service exposed to the user, usually a web page.

Third, the status update module is the key to the present invention and is responsible for statistically analyzing the data directly required for performance modeling from the loaded log information. In addition, the status update module determines the length of the status update period, and then updates the status by the specified period after the determination. The length of the cycle can be determined according to the frequency of system updates, which is shorter than the average update cycle. In general, set the period to 10-30 minutes. The status update module consists of an execution graph analyzer, a deployment analyzer, a service time analyzer, and a user behavior simplifier.

The execution graph parser is responsible for parsing the execution path of a transaction from the call chain (read from the trace information loader) rather than calling a specific call chain one time. Therefore, the execution graph analyzer forms the overall execution path by merging the peer nodes of each call chain of a transaction, that is, the execution graph of a transaction. Because if you simply merge the components in the graph by node, it will lead to structural inconsistency. In the call chain shown in Figure 3, if you just merge by node, the path of C0->C4->C1->C3 will appear, that is, component C0 calls C4, C4 calls Cl, and C1 calls C3. However, the path does not exist, and the cause of the inconsistency is that C4->C1 is not equal to C0->C1, if the merge process If there is no distinction, there will be a path that does not actually exist.

To solve this problem, this paper defines the concept of peer nodes. If the nodes α and β are equal, one condition needs to be met:

α and β represent the same entry, and

Or the parent node of α and the parent node of β are peer nodes, and the parent node has the same request type to α and β; or α = β and the parent nodes of α and β are empty.

The merging of peer nodes is as follows: Use Ε (χ) to represent the peer class of node X. If two peer nodes have α -> β in the call chain, then there is a flaw in the merged transaction execution graph. ( α ) -> Ε ( β ).

Figure 4 depicts the transaction execution diagram of the merged call chain of Figure 3, in which the call relationship of C0->C1->C3 and C0->C4->C1 is preserved, so no inconsistency is caused.

The deployment analyzer primarily analyzes the deployment location of components in the call chain (read from the trace information loader), which server a component is deployed on. This part of the information is still extracted from the trajectory monitoring information, and the deployment information of the component is obtained by analyzing the IP of the physical device where each component on the trajectory is located.

The Service Time Analyzer is primarily used to calculate the component's service time, depending on the CPU utilization loader, the deployment analyzer, and the data generated by the execution graph analyzer. Because the service time of the component is difficult to accurately obtain through monitoring, the service time of the component can only be calculated from other monitorable data. Service time refers to a functional service (such as a function) that the component provides to the outside, the actual execution time, and no waiting time. The present invention uses Kalman filtering to perform calculations (R. E. Kalman, A New Approach to Linear Filtering and Prediction Problems, Transactions of the ASME-Journal of Basic Engineering, I960).

The execution graph and deployment status data are used in the calculation to determine the components on each server and the frequency of calls to these components (that is, the throughput rate, which can be obtained by dividing the number of calls divided by the status update period, in seconds). At the same time, monitoring data for CPU utilization is also used. The calculation of the service time of components on a server is described below.

Kalman filtering provides a general method for estimating the unobservable state X at discrete points in time. The k-th moment state can be defined as a linear stochastic difference equation:

The total utilization rate of the CPU at the kth time is defined as:

3⁄4 = ϋ . . (L b) where A is the state transition matrix from k-1 to k, -i is an optional control parameter, B is the matrix associated with the control, Mfe is the measurement error, and its covariance matrix For Q _M. ^ is the conversion matrix to, ι3⁄4 is the measurement error, its co-party The difference matrix is 3⁄4.

The present invention maps equations (1. a) and (1. b) as follows:

3⁄4 ― 3⁄4-1 + ^w ki (2. a)

3⁄4 =∑ί= ί , ^x t + ^v k (2. b) where = xl -.. 1 , which represents the service time of each component service at time _k , a is the total CPU utilization, and t is the throughput of each service ( The frequency at which the component is called, the throughput rate, is obtained by dividing the number of calls by the status update period, in seconds. According to the CPU utilization rule, there is a formula (2. b), that is, the total CPU utilization is equal to the cumulative sum of the product throughput and the service time product. So H can be defined as follows:

3⁄4 = i ^f 2 - ^f «] (2. _c )

The Kalman algorithm also requires an initial value and Rj. The iterative process is as follows:

1. Update the status of X with _M =0:

2. Update the covariance matrix ^:

3. Calculate the Kalman gain:

4. Fix the state of X: = + (3⁄4― - )

5. Correct the covariance matrix] 3⁄4 _:

3⁄4 = (./― K _k H _k }P _k initial value and 13⁄4 have little effect on Kalman filter calculation and can be set to any reasonable value. This paper sets the initial value to: = ^(1) according to the definition of queuing theory. - 〕 (Wang Wei, Zhang Wenbo, Wei Jun, Zhong Hua, Huang Tao. A resource-sensitive Web application performance diagnosis method, Journal of Software, 2010, Vol. 21, No. 2, pp. 194-208), response time for service i That is, the service time is equal to the response time multiplied by the CPU idle rate; and = rf i3⁄4?(if) ² , ( ² >~d3⁄4 ² ), because the service time of each component service is independent, it is a diagonal matrix.

The three matrices i3⁄4 Q^P 3⁄4 must be determined for each iteration. H _t can be obtained directly by calling the chain information, that is, each service The throughput rate (the total number of times the service is called divided by the length of the sample period in one sample period). The covariance matrix representing the X change in each iteration is usually not available for online systems, and only the range of variation can be estimated. However, if it is too large, the estimation result will be too large. If it is too small, the result will be subtle and the fluctuation of service time will not be reflected. One strategy is to set the diagonal matrix, and the diagonal element is the square of the maximum value of the X change during an iteration.

^3⁄4 = ^άία 8 ξι> ξ2, , where {( ^χ ί - ) is the error of each measurement, that is, the measurement error of the total utilization of the CPU. This paper considers that the measured value of the total utilization of the CPU is small enough to be reliable. Therefore, in the iteration process of 3⁄4=0, the state of the modified X in step 4 is the key to the estimation of the service time. The formula can be simplified to X = Κ _ΰΜ The form of + Κ - corrects the value of X _M using Kalman gain and error e. That is, as new data is continuously collected, service time X can be continuously updated during the iterative calculation to ensure estimation The service time is consistent with the actual service time.

The User Behavior Reducer is primarily responsible for translating the actual user behavior (read from the User Behavior Loader) into a form acceptable to the hierarchical queuing network. In order to simplify the user behavior pattern diagram, the present invention introduces a derivative vector of the user behavior pattern diagram, which describes the basic characteristics of the user behavior pattern diagram, that is, the number of times each transaction is averaged in one session, and the user behavior pattern diagram The number of times a transaction is accessed is equal in probability.

Let V denote the derived vector of the user behavior pattern, indicating the number of times each transaction was accessed in a session. If the number of times of ι3⁄4 is 1, that is, the number of times the transaction starts is 1, then the number of times each transaction is accessed can be defined as the form of formula (3), that is, the number of times each transaction is accessed is equal to the number of times its precursor node is accessed and accessed. The product of the node probabilities.

3⁄4 =∑S? ΐ3⁄4 P^ i = 1, , + 1 ₍₃₎ Equation 3 can be written as a matrix:

I? ~ T = PXP (4) where Ϊ = (1,0., .., ,0), Ρη _÷ 1 = 0 ^ = 0. ..■'"■ + 1 and _Vn+1 =l, because The start and end transactions must exist, and the end of the transaction will not access other transactions. Solving the linear equations corresponding to equation (4), you can get the derived vector V

The status update module periodically executes at the interval of the status update period to update the performance data. After each update, the performance data is saved in the state storage module for analysis by the module.

Fourth, the state storage module is mainly responsible for storing the latest state generated by the state update module, including: execution map, deployment state data, service time, and user behavior, corresponding to the results generated by the corresponding sub-modules of the state update module. Such as user behavior It is the derived vector of the user behavior pattern graph generated by the user behavior simplification module. After receiving the maintenance personnel's command, the analysis module extracts data from the module for prediction.

Finally, the analysis module is responsible for generating performance models based on state information and invoking its tools to analyze future performance. The module consists primarily of a performance model builder, a performance analysis module, and a display module. When the status storage module finds that the performance data exists and is started, the analysis module calls each sub-module to work, and presents the performance analysis result to the maintenance personnel. Otherwise, an acquisition cycle has not been completed at this time, and no operational data is collected, waiting for the maintenance personnel to start the analysis module again.

The performance model constructor is responsible for generating the hierarchical queuing network performance model based on the performance data, and specifically includes four steps: First, generating a single service hierarchical queuing network model according to a single execution graph; Second, attaching deployment state data to determine each component The deployment state; third, the service time is filled in the structure of the performance model according to the service time; fourth, the load is generated according to the derived vector of the user behavior pattern diagram, and the hierarchical queue network of the individual service is combined into one complete The hierarchical queuing network performance model.

After performing the graph analyzer analysis, the execution graph of each transaction is generated in units of transactions. The execution map reflects the overall characteristics of the transaction in terms of statistical characteristics and can be directly converted to a hierarchical queuing network model (LQN). The conversion rule is an entry (Entry) in which the node (component service) in the execution graph is converted to LQN, and the service of the same component is merged into a task (Task) of the LQN model. Figure 4 is an execution diagram obtained by the execution graph analyzer processing the different call chains of a transaction shown in Figure 3 after merging the peer nodes, and converted into an LQN model as shown in Figure 5.

The operation of attaching the deployment state data is relatively straightforward, and it is only necessary to deploy the tasks on the same hardware resource in the same LQN model describing the hardware resources in the model. Figure 6 shows an example of additional deployment state data. If the deployment analyzer analyzes that the CO is deployed on the ServerO server, C1 and C2 are deployed on the Server1 server, and C3 and C4 are deployed on the Serverf server, Figure 5 is converted to the structure shown in Figure 6.

Service time is a key parameter of a hierarchical queuing network. Each component service, that is, each entry in the hierarchical queuing network, has this parameter, indicating that the component itself is actually executing the required time, excluding itself and the wait time for calling other components. The estimation of the service time is done by the service time analyzer. During the calculation process, different services of the same component, that is, different service times of different entries in the LQN model, will be calculated separately. However, the unequal nodes of the same service do not distinguish between them, because it is not necessary to care about the calling relationship between components at this time, and only need to care about the service time of each service. Figure 7 shows an example of an LQN model with service time parameters added. The C1 and C3 tasks in the figure have two entries, but they are two non-equivalent nodes of the same service, so the service time is the same.

The derived vector of the user behavior pattern diagram does not have a loop, so it can be modeled with LQN. Figure 8 shows the LQN template for the derived vector of the user behavior pattern diagram. The task simulates a user, corresponding to the special task of simulating the user in the LQN model, and can generate loads in both open and closed ways (Franks, G., Hubbard, A., Majumdar, S., Petriu, DC, Rol ia, J. , Woodside, C. M: A toolset for Performance Engineering and Software Design of Cl ient-Server Systems. Performance Evaluation, Vol. 24, Nb. 1-2 (1995) 117-135). Each task (from T1 to Tn) is accessed with the value in the derived vector V. These tasks are generated by the LQN model generated by the graph, but there are no transactions for both the 13⁄4 and the 13⁄4+1 because they are just the beginning and end flags. In addition, if the same task is distributed in different transaction execution diagrams, they will eventually be merged into one task, but the entries are not merged, otherwise it will cause inconsistencies in how to call the chain. Each transaction in the figure corresponds to an execution diagram similar to that shown in Figure 8, but the same hardware resources are eventually merged into one.

Figure 9 shows a simple example that describes the style of a complete LQN model. The top-level task ΕΒ represents the user, which issues different types of requests to the application server. Its service time is quite special. The statistics are the average thinking time of the user, not the service time, because the user operation interval is the thinking time, not the actual running time. When the user requests to reach the load balancer, it will be forwarded to the heterogeneous application server in different proportions. After the application server receives the request, it will invoke different database query operations. When the database query is completed, the nested wait is released layer by layer until the user releases the wait and the request ends.

The Performance Analysis Module is a calculator for solving the hierarchical queuing network tool. It can be used by the analysis tool LQNS and the simulation tool LQNSim (M. Woodside and G. Franks, "Tutorial Introduction to Layered Model ing of Software Perf romance", Http : //www. see. carleton. ca/rads/lqns/lqn_documentatior. The input to the tool is a performance model of a hierarchical queuing network model, and the output is the result of performance prediction. The results contain the total response time of the system, Data such as throughput, processor utilization, individual component usage, total execution time, etc. Based on this data, designers can clearly understand the performance of the system under different loads, and then refer to the requirements description of the final system to determine the current Whether the design meets the requirements. Especially in the case of several alternatives, by comparing the prediction results, a relatively optimal solution can be selected.

The display module is mainly responsible for presenting the predicted results to the maintenance personnel, and graphically providing maintenance personnel with different forms to analyze and compare the performance of the system. The chart display is primarily responsible for displaying the predicted performance data in a line graph showing response time, throughput, processor utilization, individual component usage, and total execution time. The abscissa is time, and the ordinate is the above various performance data, and each data is represented by a line graph.

In summary, the present invention automatically constructs a performance model that adapts to system changes for Web applications in a monitoring and statistical manner, thereby predicting future performance of the system. The prediction results can reflect the performance characteristics of different levels and granularities of the system, such as performance data of different levels at different levels, such as clusters, nodes in the cluster, and components on the nodes. It provides quantitative basis for control technologies such as load balancing strategy adjustment, node supply and recovery, bottleneck detection and location, and differentiated service quality assurance.

Claims

Claim

1. A fine-grained performance modeling method for a Web application system, comprising the following steps:

1) setting the update period of the web application middleware platform;

2) extracting the running data of the web application middleware platform in an update cycle;

3) obtaining performance data of the web application middleware platform according to the running data;

2. The fine-grained performance modeling method of a web application system according to claim 1, wherein the running data comprises execution trajectory data, total utilization of the CPU, and trajectory data of the user using the system.

3. The fine-grained performance modeling method of a web application system according to claim 2, wherein the performance data comprises a derivative vector of an execution map, component deployment state data, a service time, and a user behavior pattern diagram.

The fine-grained performance modeling method of the web application system according to claim 3, wherein the execution trajectory data is represented by a call chain, wherein the node is a component, the edge is a calling relationship between components, and the solid line indicates synchronization. Request, the dotted line represents the asynchronous request, and the number indicates the number of calls.

5. The fine-grained performance modeling method for a web application system according to claim 4, wherein an execution map of a transaction is obtained by merging peer nodes of each call chain of a transaction, wherein the peer node refers to two The nodes α and β satisfy the following conditions:

Two nodes α and β represent the same entry, and

The fine-grained performance modeling method for a web application system according to claim 3, wherein the component deployment state data is obtained by analyzing an IP address of a server where each component on the execution track is located.

7. The fine-grained performance modeling method for a web application system according to claim 3, characterized in that the service time is obtained by iteratively calculating using the following two formulas:

Xk — 3⁄4 -ι + ^w ki

Where = ^ ~ x^ , indicating the service time of each component service at the moment, ^ is the total utilization of the CPU, ί is the throughput of each service, wk-i is the measurement error, and the covariance matrix is Qk-i, Measurement error, the covariance matrix is

Rk.

8. The fine-grained performance modeling method for a web application system according to claim 3, wherein the user uses the system The method for converting trajectory data into derived vectors is:

Convert the formula = ■ X 3⁄4 . : + I into a matrix form:

V - ϊ = ν ρ where 1⁄4 is the number of times each transaction is accessed in one request, 3⁄4 =ι _; ΐ = (ΐΑ ..., ο) = ° V = _?i _.i and _{v3⁄4+ corp} ; The linear equations corresponding to the matrix form formula, obtain the derived vector

9. The fine-grained performance modeling method for a web application system according to claim 3, wherein the hierarchical queuing network performance model is generated by: first, converting a single execution graph into a hierarchical queue network of a single service a model, wherein a node performing the graph is converted into an entry of the model; a service of the same node is merged into a task of the model; second, a deployment state data of each component is attached to the model; and third, a service time is added to the model; Fourth, according to the derived vector generation load of the user behavior pattern diagram, the hierarchical service queuing network model of a single service is combined into a complete performance model.

10. A fine-grained performance modeling system for web applications, comprising:

11. The Web application fine-grained performance modeling system of claim 10, wherein the status update module comprises an execution graph analyzer, a deployment analyzer, a service time analyzer, and a user behavior simplifier.

Executing the graph analyzer to calculate the overall execution path of the transaction by using the execution trajectory data calculation web application system; obtaining the execution map;

The deployment analyzer extracts location data of each component in the execution trajectory data on the server, and obtains the component deployment state data; The service time analyzer calculates the execution time of each component of the web application system to provide the service time, and obtains the service time; the user behavior simplifier converts the trajectory data of the user using the system into a derivative vector of the user behavior pattern diagram.

12. The web application fine-grained performance modeling system of claim 10, wherein the log load module comprises a trace information loader, a CPU utilization loader, and a user behavior loader.

The track information loader loads the execution track data;

The CPU utilization loader loads the total utilization of the system server CPU;

The user behavior loader loads the trajectory data of the user using the system from login to exit.