KR100906440B1 - Web application performance monitoring device and its method through linkage of web application server transaction and database management system session - Google Patents

Abstract

The present invention relates to a technique for integrating and monitoring the performance from the WAS to the DBMS. Web application performance monitoring apparatus through the connection of the WAS transaction and DBMS session according to the present invention, a web application server transaction and a specific database management system in a web infrastructure including one or more web application server and one or more database management system Is a device that monitors the performance information associated with matching sessions. When a specific transaction is executed in a web application server, it collects the SID of the database management system to which the session is connected and the performance information of the web application server, and collects the DBMS performance information collection agent. WAS performance information collecting agent for transmitting in real time; DBMS performance information that receives SID transmitted from WAS performance information collection agent and web application server performance information, and collects performance information of database management system linked with web application server performance information through SID and sends it to repository. Collecting agent; And the performance information of the interconnected web application server and the database management system performance information transmitted from the DBMS performance information collection agent, and the associated performance information between the transaction of the specific web application server and the session of the specific database management system. It is configured to include a repository to display on an integrated screen.

Description

Apparatus for monitoring a performance of WEB applications by connecting WAS transaction with DBMS session and method

The present invention relates to an apparatus and method for monitoring web application performance, and more particularly, to monitor performance of a web application server (hereinafter referred to as a WAS) and a database management system (hereinafter referred to as a DBMS) alone. It is not about technology but about technology to integrate and monitor the performance from WAS to DBMS.

Through the spread and generalization of the Internet in the late 1990s, various information services were implemented in the form of web applications with high flexibility and user accessibility. As a result, the IT infrastructure system was changed from client / server structure to web-based structure. The web infrastructure is basically composed of WEB-WAS-DBMS and can be more complicated.

WAS provides functions as middleware that supports interworking with DBMS that manages user applications and business data implemented on the web, system security and stability, and functions to speed up configuration and service of various web infrastructures. WAS is mostly Java-based and accepts the Java Platform Enterprise Edition (J2EE) standard, but there are also non-JAVA families that are based on .Net or Citrix. J2EE, which accounts for most of WAS, is a standardized environment for running Java applications (representative web).

A DBMS is a program that allows multiple users to write or access data in a database. Using DB (Structure Query Language) as a user and program interface, users can access requirements data. Examples include Oracle's Oracle DBMS, IBM's DB2, and Microsoft's SQL Server.

Meanwhile, the IT infrastructure environment no longer serves as an infrastructure but is directly related to the company's survival and sales, and the level of service required by customers is increasing. As a result, efforts are being made to secure the availability of IT services that emphasize system non-stoppage and integrity. In addition to WAS and DBMS, which are the unit systems that make up the web application system, to realize real-time business implementation, Increasingly, the need for integrated and real-time fault and performance management on the work between WAS and DBMS is increasing.

As the online transaction processing (OLTP) environment, which handles large amounts of transactions in real time under the increasingly large and complex web-based system, is spreading, efforts to effectively monitor the performance of the WAS and the DBMS that manages the data are being implemented. It is going on.

In the conventional technology of monitoring the performance of a WAS (eg J2EE), an agent collecting performance information is installed in a WAS to be monitored, and the performance information is recorded by using a UDP (User Datagram Protocol) port on a dedicated server that records the performance information. Client of user PC monitors performance information in real time by communicating with performance recording server through TCP (Transmission Control Protocol) port. The collected performance information includes the number of concurrent users, active service list, active JDBC connection / allocation / execution status, response time, throughput, SQL statement, etc. You can set up to quickly recognize the occurrence of performance problems. In addition, in case of a problem exceeding a threshold value among information collected in real time, the transaction quantity data of the WAS is collected to enable analysis of the cause of exceeding the threshold value.

However, this technique can be used only when the threshold value is exceeded and the performance information is secured only when there is a problem. And the information of SQL statement executed in DBMS is confirmed, but if the confirmed SQL statement is delayed in DBMS, the cause and solution cannot be traced. In addition, as the web-based system is complicated by the many-to-many environment where the connection between the WAS and the DBMS is not one-to-one, when the performance problem occurs in a specific WAS, it is difficult to intuitively check which DBMS the problem has occurred. have.

Conventional technology for monitoring the performance of a DBMS (eg Oracle DBMS) installs an agent that collects various performance information generated from the DBMS on a server where the DBMS is installed and stores the performance information by communicating with the user PC through the TCP port. , Monitor. The collected performance information includes performance data (Performance Statistics data and Waiting Event data), Active session information and response time of database generated by Oracle's DBMS. Overall system level, user session level It is provided in real time at the SQL statement level. Real-time performance data is provided so that users can set thresholds to quickly identify occurrences of performance issues. In addition, by collecting the information collected in real time in the form of a file or information collection database, it is possible to check and analyze the performance of the past DBMS through the log file recorded. Thus, a database tuner, a database administrator (DBA) and expert consultant, can provide a performance improvement solution for the DBMS.

However, this technique can be expected to improve performance in the DBMS, but it is not a problem of the DBMS itself, that is, it is difficult to identify the cause of the performance delay and improve the performance of the application as a whole, and the DBMS is in an inaccessible hang state. There is a limitation in that monitoring is difficult.

Real-time monitoring, rapid response to failures and performance delays, and identification of root causes are essential to ensure stable operation and service level of web applications.

The conventional technology has a limitation in that integrated monitoring between WAS and DBMS, which is a major component of the base system for executing a web application, and tracking of failures and performance delays are difficult.

As a result, in an environment between WAS and DBMS composed of many-to-many, it is not possible to intuitively grasp the DBMS related to the problem WAS.

In addition, if the SQL statement monitored from the WAS perspective becomes a problem in the DBMS, the root cause of the problem in the DBMS cannot be traced.

In addition, if the performance of the application is delayed even though the application is not identified from the DBMS point of view, the root cause cannot be tracked as to what problem is occurring in the WAS in front of the DBMS.

In addition, since the threshold value is set among the information collected in real time and the WAS transaction quantity data is dumped and secured in case of a problem, it cannot be used when the threshold value is not set or the overall trend of the past is to be analyzed.

In addition, it is difficult to collect monitoring information in a hang state where the DBMS cannot be accessed.

The present invention solves the above-mentioned problems and escapes the form of monitoring and accessing the WAS and DBMS, respectively, which affects the stable operation of the web application, and monitors the WAS and the DBMS in conjunction with each other. The purpose of the present invention is to provide an apparatus and method for monitoring application performance through linkage of WAS transactions and DBMS sessions that can cope with and identify the root cause.

Another object of the present invention is to provide an apparatus and method for monitoring application performance through linkage between a WAS transaction and a DBMS session, which can easily monitor and reproduce the performance of a web application of the nearest past time point including the present.

In addition, an object of the present invention is to provide an apparatus and method for monitoring application performance through linkage of WAS transactions and DBMS sessions that can provide overall integrated monitoring in a WAS and DBMS environment composed of many-to-many.

In addition, an object of the present invention is to provide an apparatus and method for performance monitoring through linkage of a WMS transaction and a DBMS session that can identify the cause of a failure even when the DBMS cannot be accessed.

In order to achieve the above object, the web application performance monitoring apparatus through the connection of the WAS transaction and the DBMS session according to the present invention, a web application specific web application structure comprising one or more web application server and one or more database management system A device for monitoring performance information associated with a transaction of a server and a session of a specific database management system, the device being installed and operated in a web application server system together with the web application server, and performing a specific transaction in the web application server. Collects the session identifier (SID) of the database management system that has made a session connection and the performance information of the web application server, and is a real-time agent for collecting DBMS performance information of the database management system that has made the session connection. Song WAS performance information collection agent that; It is installed and operated in a database management system server with the database management system, and receives the session identifier (SID) and the performance information of the web application server transmitted from the WAS performance information collection agent, and receives the session identifier (SID) A DBMS performance information collection agent for collecting performance information of the database management system associated with the performance information of the web application server and transmitting the performance information to a repository; And the performance information of the web application server and the performance information of the database management system, which are interconnected from the DBMS performance information collection agent, and store a transaction of a specific web application server and a session of a specific database management system according to a user's request. It consists of a repository that displays the associated performance information between them in one integrated screen.

In order to achieve the above object, a web application performance monitoring method by linking a WAS transaction and a DBMS session according to the present invention includes a specific web application in a web infrastructure including one or more web application servers and one or more database management systems. A method of monitoring performance information associated with a match between a server transaction and a session of a specific database management system. (A) When a specific transaction is executed in a web application server, a WAS performance information collecting agent installed in the web application server system performs a session. Collecting and storing a session identifier (SID) of a connected database management system; (b) collecting, by the WAS capability information collecting agent, performance information of the web application server and transmitting the capability information together with a session identifier (SID) to a database management system in which the session is connected; (c) The DBMS performance information collecting agent installed in the database management system server receives the session identifier (SID) and the performance information of the web application server transmitted from the WAS performance information collecting agent, and through the session identifier (SID) Collecting performance information of the database management system associated with the performance information of the web application server and transmitting the collected performance information to a repository; (d) storing, by the repository, performance information of the web application server and the performance information of the database management system interrelated with each other transmitted from the DBMS performance information collection agent; And (e) the repository displaying the associated performance information between the transaction of the specific web application server and the session of the specific database management system in one integrated screen at the request of the user.

According to the present invention, since one of the numerous transactions of the WAS and the sessions of the DBMS is connected to which session, the information is collected and stored in the repository as an associative structure from the information gathering stage where the transaction proceeds. Overcoming the limitations of the prior art, it is possible to accurately monitor the linkage information between the WAS and the DBMS at a glance without going through manual matching by the user.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

As shown in FIG. 1, the apparatus for monitoring web application performance by linking a WAS transaction and a DBMS session according to the present invention includes at least one web application server (WAS) 12_1 and 12_n and at least one database management system (DBMS). It is implemented in a web-based structure comprising (22_1, 22_n). Hereinafter, the information processing system in which the web application server (WAS) 12_1 and 12_n is installed and operated will be referred to as the web application server (WAS) system 10_1 and 10_n, and the database management system (DBMS) 22_1 and 22_n may be referred to. The information processing system installed and operated is called database management system (DBMS) server 20_1, 20_n. Web application performance monitoring device through the connection of the WAS transaction and DBMS session according to the present invention is WAS performance information collection agent (14_1, 14_n) installed and operated in the web application server (WAS) system (10_1, 10_n), database management DBMS performance information collecting agent (24_1, 24_n) installed and operated in the system (DBMS) server (20_1, 20_n) and the repository (Repository) 30 implemented as a separate information processing system is implemented. Since the WAS 12_1 and 12_n can have many-to-many connections with the DBMSs 22_1 and 22_n in the web-based structure as shown in FIG. 1, the WAS performance information collecting agent 14_1 corresponding to each WAS 12_1 and 12_n. , 14_n may be connected to the DBMS performance information collecting agents 24_1 and 24_n corresponding to the respective DBMSs 22_1 and 22_n.

The WAS performance information collecting agent 14_1 collects and stores a session identifier (SID) of a database management system (DBMS) 22_1 that has made a session connection when a specific transaction is performed in the web application server (WAS) 12_1, The collected session identifier (SID) is transmitted in real time to the DBMS performance information collecting agent 24_1 of the database management system (DBMS) 22_1 where a session connection is made together with the performance information collected by the web application server 12_1. In this case, the WAS performance information collecting agent 14_1 and the DBMS performance information collecting agent 24_1 may exchange data using user datagram protocol (UDP) communication.

The DBMS performance information collecting agent 24_1 receives the session identifier (SID) and the performance information of the web application server transmitted from the WAS performance information collecting agent 14_1, and performs the performance of the web application server through the session identifier (SID). Collect performance information of the database management system associated with the information. The DBMS performance information collection agent 24_1 transmits the performance information of the associated web application server and the performance information of the database management system to the repository 30 through the session identifier SID.

The repository 30 stores the performance information of the interconnected web application server and the performance information of the database management system transmitted from the DBMS performance information collection agent 24_1, and according to the request of the user, the specific web application servers 12_1 and 12_n. Performance information associated between the transaction of the and the session of the specific database management system (22_1, 22_n) is displayed on one integrated screen.

Meanwhile, among the performance information of the web application server collected by the WAS performance information collecting agent 14_1, information that is not related to the database management system, the WAS performance information collecting agent 14_1 does not go directly through the DBMS performance information collecting agent 24_1. It is preferable to transmit to the repository 30 to be stored. In addition, among the performance information of the database management system collected by the DBMS performance information collecting agent 24_1, information not related to the web application server is also linked by the DBMS performance information collecting agent 24_1 through the session identifier (SID). It is preferable to transmit the data to the repository 30 directly without any process.

Hereinafter, a preferred embodiment of the present invention implemented for a WAS (hereinafter simply referred to as a WAS) and an Oracle DBMS (hereinafter simply referred to as a DBMS) adopting the Java Platform Enterprise Edition (J2EE) standard based on Java. It will be described in detail.

Generally, the process of executing transaction by accessing DBMS in WAS is as follows.

getConnection Step: Gets a connection object to receive a request from a client and connect to a DBMS.

Prepare Step: Parse an SQL statement using the PrepareStatement statement.

-Execute Step: Execute SQL statement using ExecuteQuery statement.

Open ResultSet Step: Get the result executed in ExecuteQuery into result set.

Fetch Step: Patch the executed result.

-ResultSet close Step: Close the result set when data processing is completed.

Statement close Step: Close the parsed SQL statement.

-Connection close Step: Return the connection object to the connection pool when the operation is finished and no further work is done in the DBMS.

This process can be implemented as follows.

public class DBTest {

     public static void main (String [] args) throws Exception {

        Class.forName ("jdbc driver ...");

        Connection conn = ... getConnection () ...; => GetConnection Step

        query = ("select ..."); => SQL Text

        pre = conn.prepareStatement (query); => Prepare Step

        rs = pre.executeQuery (); => Execute Step, Open ResultSet Step

        while (rs.next) => Fetch Step

        {

          System.out.println (rs.getString (...));

        }

        rs.close (); => ResultSet close Step

        pre.close (); => Statement close Step

        conn.close (); => Connection close Step

     }

   }

In FIG. 2, the web application server system 50, the database management system server 60, and the repository 70 are respectively the web application server systems 10_1 and 10_n, the database management system servers 20_1 and 20_n, and the repository (FIG. 1). 30), the WAS 53 and the monitored DBMS 61 correspond to the WAS 12_1, 12_n and DBMS 22_1, 22_n of FIG. 1, respectively, and the jspd daemon 56 and the rts daemon 62. Corresponds to the WAS performance information collecting agents 14_1 and 14_n and the DBMS performance information collecting agents 24_1 and 24_n, respectively.

A JVM (Java Virtual Machine) 52, which is a virtual machine that enables a program written in a Java language to be executed on an operating system (OS) 51 operating in the web application server system 50, operates, and the JVM A WAS 53 having a Java DataBase Connectivity (JDBC) 54 and a Java Server Page (JSP) / Servlet 55 and a jspd daemon 56 are installed and operated on the 52. Here, JDBC 54 is an interface that allows a Java program to access a DBMS and execute SQL statements. JSP / Servlet 55 calls a Java program to show the content and appearance of a dynamic web page to the user. The language and program to give.

The jspd daemon 56 is implemented as a daemon program, and functionally includes a SID Gather 56a, a WAS Gather 56b, and a Data Transfer 56c. It is composed. The rts daemon 62 is also implemented as a daemon program, and functionally includes an SID receiver 62a, a data gatherer 62b, and a data transfer 62c. do. The repository 70 functionally includes a data handling manager 71, a storage database 72, and a display service manager 73.

Referring to FIG. 3, the web application performance monitoring method through linking a WAS transaction and a DBMS session according to the present invention includes collecting and storing SIDs of the DBMS 61 associated with a transaction of the WAS 53 (S100 to S130). And transmitting the SID collected by the WAS 53 to the database management system server 60 in real time (S140, S160, S180, S200, S220), and performing a transaction of the WAS 53 with the received SID. And 1: 1 matching with (S150, S170, S190, S210, S230), and storing the WAS information and the DBMS information connected by the SID in the repository 70 in a linked form (S260). The user monitors the information through the integrated monitoring screen (S270).

On the other hand, when the WAS information collector (WAS Gather) 56b of the jspd daemon 56 collects WAS information of a transaction that is not related to the DBMS 61 (for example, displaying a greeting on a web page) (S240), jspd The data transfer unit 56c of the daemon 56 transmits and stores the collected WAS-specific information directly to the repository 70 without transmitting the collected WAS-specific information to the rts daemon 62 (S260). In addition, when the data collector 62b of the rts daemon 62 collects DBMS execution information (for example, executing an SQL statement through telnet) not related to the WAS 53 (S250), the rts daemon ( 62 is directly transmitted to the repository 70 regardless of the jspd daemon 56 to be stored (S260).

1. Collecting and storing SIDs of DBMSs associated with WAS transactions

This step occurs in the first getConnection Step of the transaction.

 In order to reduce the overhead of creating a session when connecting to the DBMS 61, the WAS 53 creates a connection object in a connection pool and connects to the DBMS 61 through a client request. When the task is performed in the DBMS 61 and completed, the connection object is returned to the connection pool.

In a preferred embodiment of the present invention, in order to extract the SID of the DBMS 61 associated with the transaction, the map structure of the connection object used when a session connection is made to the DBMS 61 in the connection pool of the WAS 53 is optional. A variable (exem_sid) is set to store the SID of the DBMS 61 in this variable, and has a value of SID until the WAS 53 is terminated. However, when the WAS 53 starts and connects to the DBMS 61 for the first time, the weaving technique of java (generalized technique of inserting code for extracting information in each process of a transaction) is described. Perform the SQL statement to extract the next SID by using (S100 to S120), through which the SID of the session is stored in the exem_sid variable (S130). This step is performed by the SID Gather 56a of the jspd daemon 56.

SID extraction SQL statement 1: select sid from v $ mystat where rownum = 1;

(If you create and provide a view in case you don't have permission to view v $ mystat, use that view.)

SID extraction SQL statement 2: select userenv ('sid') from dual;

SID extraction SQL statement 3: select sid from v $ session where sid = (select userenv ('sessionid') from dual);

2. Transmitting SID collected from WAS to DBMS server in real time

 The jspd daemon 56 obtains the SID of the DBMS 61 associated with the transaction executed in the WAS 53 through the SID collection step, and immediately before the Prepare Step in which the SQL statement parsing is performed, proceeds with the User Datagram Protocol (UDP). The session identifier (SID) collected through communication, and WAS performance information such as SQL text, cursor id, and was transaction id are transmitted to the rts daemon 62 of the DBMS server 60 (S140). In addition to the received information, the rts daemon 62 may request additional information (eg, Client IP, Class Method, Transaction Name, etc.) from the jspd daemon 56 for linkage with DBMS data.

When the jspd daemon 56 of the WAS system 50 sends information to the rts daemon 62 of the DBMS server 60 through UDP communication in the course of performing a transaction, and representative information is as follows.

       Representative Information

Prepare-> SID, SQL Text, Cursor ID, WAS Transaction ID, etc.

(S140)

Execute-> SID, Cursor ID, START TIME, WAS Transaction ID, etc.

(S160)

Execute End-> SID, Cursor ID, END TIME, WAS Transaction ID, etc.

(S180)

Fetch-> SID, Cursor ID, START TIME, WAS Transaction ID, etc.

(S200)

Fetch End-> SID, Cursor ID, END TIME, WAS Transaction ID, etc.

(S220)

Representative information is described in Table 1.

Item Contents SID DB session identifier SQL Text SQL statement Cursor ID Execution Pointer Identifier when SQL statement is executed in DB WAS Transaction ID WAS transaction identifier START TIME Start time of each step END TIME End time of each step

3. Matching the session of WAS 1: 1 with the DB session by using the received SID

The rts daemon 62 transfers the information received from the jspd daemon 56 to the performance information of the DBMS collected by the rts daemon 62 (Performance Statistics data, Waiting Event data, Active session information, Responses). Time, etc.) (S150, S170, S190, S210, and S230).

(1) Prepare

 Just before the Prepare Step proceeds, the jspd daemon 56, which collects SID, SQL Text, Cursor ID, and WAS Transaction ID information, collected from getConnection, is prepared by the DBMS server 60 via UDP communication. Send it to the rts daemon 62, which is collecting data. In addition to the received information, the rts daemon 62 may request additional information (eg, Client IP, Class Method, Transaction Name, etc.) from the jspd daemon 56 for linkage with DB data. After the information is transmitted, the Prepare Step proceeds, and the rts daemon 62 transfers the received information to the performance information of the DBMS (Performance Statistics data, Waiting Event data, Active session information, Response Time, etc.). It matches with (S150). Through this, the transaction information of the WAS 53 and the performance information of the session of the DBMS 61 may be collected in an associated form.

When a transaction related to WAS 53 and DBMS 61 is executed (for example, member search is executed on a web page), the jspd daemon 56 extracts WAS performance information and SID of DBMS 61 for each execution process as above. The rts daemon 62 matches the session of the DBMS 61 associated with the received WAS transaction 1: 1, and transmits the WAS performance information and the DBMS performance information to the repository 70 in association with each other. Save it.

(2) Execute

 When the prepare step is processed and the SQL statement is parsed, the jspd daemon 56, which collects the performance information of the WAS, immediately before the Execute Step is executed, executes the SID and Cursor ID, START TIME, and WAS Transaction. The ID and the like are transmitted to the rts daemon 62 collecting data from the DBMS server 60. In addition to the received information, the rts daemon 62 may request additional information (eg, Client IP, Class Method, Transaction Name, etc.) from the jspd daemon 56 for linkage with DBMS performance information. After the information is transmitted, Execute Step proceeds, and the rts daemon 62 sends the received execution start information to the performance information of the DBMS (Performance Statistics data, Waiting Event data, Active session information, Response time). Etc.) (S170). Through this, performance information related to parsing an SQL statement and starting execution of SQL can be collected in a form in which a transaction of the WAS 53 and a DBMS 61 session are linked.

When a transaction related to WAS 53 and DBMS 61 is executed (for example, member search is executed on a web page), the jspd daemon 56 extracts WAS performance information and SID of DBMS 61 for each execution process as above. The rts daemon 62 matches the session of the DBMS 61 associated with the received WAS transaction 1: 1, and transmits the WAS performance information and the DBMS performance information to the repository 70 in association with each other. Save it.

(3) Execute End

 When the execution of the SQL statement proceeds and ends, the jspd daemon 56 collecting information of the WAS 53 collects data from the DBMS server 60 by UDP communication of the SID, Cursor ID, END TIME, and WAS Transaction ID. To the rts daemon (62). In addition to the received information, the rts daemon 62 may request additional information (eg, Client IP, Class Method, Transaction Name, etc.) from the jspd daemon 56 for linkage with DBMS performance information. After the information is sent, just before the Fetch Step of the transaction proceeds, the jspd daemon 56 collects the information again, and the rts daemon 62 sends the received execution termination information to the performance information of the DBMS (Performance Statistics data and Wait event data, active session information, response time, etc.) (S190). Through this, performance information related to the termination of execution of the SQL statement can be collected in a form in which the transaction of the WAS 53 and the DBMS 61 session are linked.

When a transaction related to WAS 53 and DBMS 61 is executed (for example, member search is executed on a web page), the jspd daemon 56 extracts WAS performance information and SID of DBMS 61 for each execution process as above. The rts daemon 62 matches the session of the DBMS 61 associated with the received WAS transaction 1: 1, and transmits the WAS performance information and the DBMS performance information to the repository 70 in association with each other. Save it.

(4) Fetch

 After transmitting and saving information at Execute End, the jspd daemon (56), which collects the performance information of WAS, immediately before the Fetch Step, where SQL statements are patched, proceeds with SID and Cursor ID, START TIME, and WAS Transaction ID through UDP communication. To the rts daemon 62 collecting data from the DBMS server 60. In addition to the received information, the rts daemon 62 may request additional information (eg, Client IP, Class Method, Transaction Name, etc.) from the jspd daemon 56 for linkage with DBMS performance information. After the information is transmitted, the Fetch Step proceeds, and the rts daemon 62 sends the received Fetch start information to the performance information of the DBMS (Performance Statistics data, Waiting Event data, Active session information, Response time). Etc.) (S210). Through this, performance information related to Fetch start of SQL statements can be collected in a form in which a transaction of WAS 53 and a DBMS 61 session are linked.

When a transaction related to WAS 53 and DBMS 61 is executed (for example, member search is executed on a web page), the jspd daemon 56 extracts WAS performance information and SID of DBMS 61 for each execution process as above. The rts daemon 62 matches the session of the DBMS 61 associated with the received WAS transaction 1: 1, and transmits the WAS performance information and the DBMS performance information to the repository 70 in association with each other. Save it.

(5) Fetch End

 When the Fetch of the SQL statement proceeds and ends, the jspd daemon 56 collecting information of the WAS 53 collects data from the DBMS server 60 by UDP communication of the SID, Cursor ID, END TIME, and WAS Transaction ID. To the rts daemon (62). In addition to the received information, the rts daemon 62 may request additional information (eg, Client IP, Class Method, Transaction Name, etc.) from the jspd daemon 56 for linkage with DBMS performance information. After the information is transmitted, the result set close step is performed, and the rts daemon 62 sends the received Fetch progress and termination information to the performance information of the DBMS (Performance Statistics data, Waiting Event data, Active session). Information, response time, etc.) (S230). Through this, performance information related to the completion of the Fetch process of the SQL statement may be collected in a form in which the transaction of the WAS 53 and the DBMS 61 session are linked.

When a transaction related to WAS 53 and DBMS 61 is executed (for example, member search is executed on a web page), the jspd daemon 56 extracts WAS performance information and SID of DBMS 61 for each execution process as above. The rts daemon 62 matches the session of the DBMS 61 associated with the received WAS transaction 1: 1, and transmits the WAS performance information and the DBMS performance information to the repository 70 in association with each other. Save it.

4. Saving WAS performance information and DBMS performance information linked by SID in the repository in relevant format

The information related between the WAS 53 and the DBMS 61 in the course of the transaction is the rts daemon 62 in which the jspd daemon 56 collecting the performance information of the WAS 53 is collecting data from the DBMS server 60. ), The rts daemon 62 matches the transmitted information with the DBMS performance information collected therein, and transmits the information to the repository 70, and the data processing manager 71 of the repository 70 The transmitted information is stored in a storage DB (Repository Database) 72 in an organic structure (for example, a structure as shown in FIG. 4) in which WAS performance information and DBMS performance information are 1: 1 matched (S260). ).

The information to be stored is the performance information collected by the WAS 53 (the number of concurrent users connected, the Active service list, the active JDBC connection / allocation / performance status, response time, work throughput, etc.) and the DBMS 61. Collected various performance information (performance data of database generated by Oracle DBMS (Performance Statistics data, Waiting Event data, Active session information, response time, etc.), each WAS system 50 and Resource usage such as CPU utilization, heap size, etc. of the DBMS server 60 are stored in an organic relational structure.

The contents of each item shown in FIG. 4 are described in Table 2.

Item Contents ACTIVE_CLASS_METHOD Active Class Methods in WAS CLASS_METHOD_INFO Full class method information in WAS ACTIVE TXN Active Transactions in WAS TXN_NAME Transaction Name in WAS TXN_SUMMARY Transaction performance summary for WAS WAS_INFO General information of WAS CONNECTION_POOL_INFO Connection pool information for WAS and DB connection WAS_STAT Performance data of WAS SQL_STAT SQL performance data SQL_TEXT SQL statement BIND_SQL SQL Statements Using Bind Variables DB_INFO General information of DB DB_STAT DB performance data DB_WAIT DB Event Event Data DB_OS_STAT OS performance data of DB server

5. Steps for monitoring the user through the integrated monitoring screen

The performance information of the WAS and the DB stored in a mutually related form through the SID makes it easy to know which path the transaction executed in the WAS 53 is returned from the DBMS server 60 to return. It is possible to connect and analyze the DBMS, which has been pointed out as a limitation of real-time monitoring, fault monitoring, and performance analysis. It is possible to easily determine whether it has been performed, so that most problems occurring across the WAS 53 and the DBMS 61 can be tracked and solved in a short time. In order to monitor the performance information associated with the WAS 53 and the DBMS 61 at a glance, the following SQL statement is executed by the display service manager 73 of the repository 70 (S270). .

-SQL statement to extract 1: 1 matching WAS transaction and DBMS session information

SELECT time,

       was_id,

       tid,

       (select t.txn_name

         from xapm_txn_name t

         where t.txn_id = s.txn_id

       ) txn_name,

       client_ip,

       start_time,

       (time-start_time) * 86400 elapse_time,

       pool_id,

       sid,

       state,

       (select t.sql_text

         from xapm_sql_text t

         where t.sql_id = s.sql_id1

       ) sql_text_1,

       (select t.sql_text

         from xapm_sql_text t

         where t.sql_id = s.sql_id2

       ) sql_text_2,

       (select t.sql_text

         from xapm_sql_text t

         where t.sql_id = s.sql_id3

       ) sql_text_3,

       (select t.sql_text

         from xapm_sql_text t

         where t.sql_id = s.sql_id4

       ) sql_text_4,

       (select t.sql_text

         from xapm_sql_text t

         where t.sql_id = s.sql_id5

       ) sql_text_5,

       sql_exec_count,

       fetch_count,

       prepare_count,

       (select c.class_name + '.' + c.method_name

         from xapm_class_method c

         where c.method_id = s.current_method_id

       ) class_method,

       current_crc,

       cpu_time,

       mem_usage,

       logical_reads,

       physical_reads,

       wait_info

FROM xapm_active_txn s

WHERE (time, was_id) IN (SELECT max (time), was_id

                             FROM xapm_active_txn

                             GROUP by was_id

                           )

In the prior art, since the transaction information of the WAS and the DBMS session execution information are not linked to each other and collected, the WAS monitoring illustrated in FIG. 5 and the DBMS monitoring illustrated in FIG. 6 should be separately performed. In addition, to check which session of the DBMS is associated with a specific transaction of the WAS, after each piece of information is collected, the user has to check and directly match a number of transactions and a number of sessions. There is a limitation that it is difficult to be sure that the information is correctly matched by an environment in which multiple transactions and multiple sessions are executed simultaneously.

Table 3 below describes only the information of the WAS itself corresponding to FIG. 5, and Table 4 describes information only of the DBMS itself corresponding to FIG. 6.

Item Contents Active Transaction Number of active transactions DB Session DB Session Count JVM CPU Usage WAS server CPU utilization JVM Thread Count WAS Server Thread Count JVM Heap Size WAS server heap size JVM GC Count WAS server SQL Exec Count SQL execution count Active DB Session Active DB Session Count Time Current monitoring time WAS WAS people Transaction Name Transaction name Class method Class method Client IP Client IP Start time Transaction start time Elapsed Time Transaction execution time up to now (Time-Start Time)

Item Contents Schema DB username Program Program name Module DB module name SPID DB Process ID SID DB Session ID Serial DB Session Serial Number Status DB session state Wait Wait event information SQL SQL statement Elapse Time SQL statement execution time (in DB) PGA (MB) DB session allocation space CPU DB Server CPU Utilization Logical Reads The number of blocks read from the DB buffer cache. Physical Reads Number of blocks read from DB datafile

On the contrary, in the present invention, a number of transactions of the WAS 53 and which one of the numerous sessions of the DBMS 61 are connected to which session are collected and matched by 1: 1 from the information gathering stage in which the transaction proceeds. By storing as an association structure in the (70) to overcome the limitations of the prior art, it is possible to accurately monitor the linkage information between the WAS and the DBMS at a glance without going through the manual manual matching of the user.

Actually, in the WAS and DBMS integrated monitoring software developed by applying the present invention, the WAS system 50 unique monitoring items are stored from the repository 70 in which relevant information of the WAS and the DBMS is stored, as illustrated in FIG. 7. In addition to the information on the specific information on the DBMS server (60) and the monitoring items, as well as a visual representation of the specific WAS that performed the transaction and the specific DBMS associated with the transaction, and related information in a single integrated screen It can be displayed and intuitively grasped when a problem occurs.

Table 5 below describes linkage information between the WAS and the DBMS corresponding to FIG. 7.

Item Contents WAS Information Time Current monitoring time WAS WAS people Transaction Name Transaction name Class method Class method Client IP Client IP Start time Transaction start time Elapsed Time Transaction execution time up to now (Time-Start Time) State Status of the transaction DB Information CPU Time CPU usage time Wait time waiting time Instance Name DB instance name SID DB Session ID Wait info Wait event information SQL Text SQL statement SQL Exec Count SQL execution count Fetch count Fetch Count Prepare Count Prepare (parse) count MEM Usage (MB) Memory usage Logical Reads The number of blocks read from the DB buffer cache. Physical Reads Number of blocks read from DB datafile

So far I looked at the center of the preferred embodiment for the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

1 is an overall configuration diagram of a web application performance monitoring apparatus by linking a WAS transaction and a DBMS session according to the present invention;

FIG. 2 is an overall configuration diagram of a web application performance monitoring apparatus through linkage between a WAS transaction and a DBMS session implemented for a WAS and an Oracle DBMS that conform to the J2EE standard.

3 is a flowchart of a web application performance monitoring method implemented for a WAS and an Oracle DBMS that have adopted the J2EE standard.

4 illustrates a configuration of an integrated repository,

Figure 5 illustrates a WAS monitoring screen according to the prior art,

Figure 6 illustrates a DBMS monitoring screen according to the prior art,

Figure 7 illustrates a WAS and DBMS linked monitoring screen according to the present invention.

* Explanation of symbols for the main parts of the drawings

10_1, 10_n, 50: WAS system 20_1, 20_n, 60: DBMS server

12_1, 12_n, 53: WAS 22_1, 22_n, 61: DBMS

14_1, 14_n: WAS performance information collecting agent

24_1, 24_n: DBMS performance information collecting agent

30, 70: repository

56: jspd 62: rts

80: monitor

Claims (8)

An apparatus for monitoring performance information associated with matching a transaction of a specific web application server and a session of a specific database management system in a web infrastructure including one or more web application servers and one or more database management systems, It is installed in the web application server system and operates together with the web application server, and collects session identifiers (SIDs) of the database management system where session access is made and performance information of the web application server when a specific transaction is performed in the web application server. WAS performance information collection agent for real-time transmission to the DBMS performance information collection agent of the database management system that the session is connected; It is installed and operated in the database management system server with the database management system, and receives the session identifier (SID) and the performance information of the web application server transmitted from the WAS performance information collection agent, and mediates the session identifier (SID) A DBMS performance information collection agent for collecting performance information of the database management system associated with the performance information of the web application server and transmitting the performance information to a repository; And It stores the performance information of the web application server and the performance information of the database management system linked to each other transmitted from the DBMS performance information collection agent, and at the request of the user of the transaction of the specific web application server and the specific database management system Web application performance monitoring apparatus through linkage of the WAS transaction and the DBMS session, comprising; a repository for displaying the associated performance information between sessions on a single integrated screen. The agent of claim 1, wherein the WAS performance information collecting agent WAS transaction, characterized in that for transmitting the collected session identifier (SID) and the performance information of the web application server in real time to the DBMS performance information collection agent of the database management system that the session connection is made by the user datagram protocol (UDP) communication; Web application performance monitoring device by linking DBMS sessions. The agent of claim 1, wherein the WAS performance information collecting agent Web application performance monitoring device by linking the WAS transaction and DBMS session, characterized in that the information related to the database management system of the collected performance information of the web application server is transmitted directly to the repository. The agent of claim 1, wherein the DBMS performance information collection agent is Among the performance information of the collected database management system, information that is not related to the web application server is directly transmitted to the repository without the process of linking through the session identifier (SID). Application performance monitoring device. In a web infrastructure comprising at least one web application server and at least one database management system, a method of monitoring performance information associated with matching a transaction of a specific web application server and a session of a specific database management system, (a) collecting and storing a session identifier (SID) of a database management system to which a session connection is made by a WAS performance information collecting agent installed in a web application server system when a specific transaction is performed in the web application server; (b) collecting, by the WAS capability information collecting agent, the capability information of the web application server and transmitting the capability information together with a session identifier (SID) to a database management system in which the session is connected; (c) The DBMS performance information collecting agent installed in the database management system server receives the session identifier (SID) and the performance information of the web application server transmitted from the WAS performance information collecting agent, and through the session identifier (SID) Collecting performance information of the database management system associated with the performance information of the web application server and transmitting the collected performance information to a repository; (d) storing, by the repository, performance information of the web application server and the performance information of the database management system interrelated with each other transmitted from the DBMS performance information collection agent; And (e) the repository displaying, at the request of the user, the associated performance information between the transaction of the specific web application server and the session of the specific database management system on one integrated screen. How to monitor web application performance by linking sessions with DBMS. The method of claim 5, wherein step (b) The WAS transaction and DBMS, wherein the WAS performance information collecting agent transmits the collected session identifier (SID) and the performance information of the web application server to the DBMS performance information collecting agent in real time through user datagram protocol (UDP) communication. How to monitor web application performance by linking sessions. The method of claim 5, (b1) The WAS performance information collecting agent further includes the step of directly transmitting information, which is not related to the database management system, from the collected performance information of the web application server to the repository. How to monitor web application performance via web. The method of claim 5, (c1) the DBMS performance information collecting agent further includes transmitting information, which is not related to the web application server, from the collected performance information of the database management system to the repository without a process of linking through a session identifier (SID); Web application performance monitoring method by linking WAS transaction and DBMS session, characterized in that.

Images