WO2005071560A1

WO2005071560A1 - Method and system for application performance management

Info

Publication number: WO2005071560A1
Application number: PCT/KR2005/000151
Authority: WO
Inventors: Keebok Park
Original assignee: Keebok Park
Priority date: 2004-01-17
Filing date: 2005-01-15
Publication date: 2005-08-04
Also published as: KR100447041B1; KR20040013058A

Abstract

The present invention relates to the methods and system for recording clients' requests and for making tests, analyses and monitoring the performances of the requests and the performances of the servers in the multi-tiered, distributed computing environment. More specifically, running each agent for each server, each agent relaying its client's requests and its server's responses between the client and server to record clients' requests and for making automated tests, analyses and monitoring, with the recorded requests, the performances of the requests and the induced requests by the servers and the performances of the servers in the multi-tiered, distributed computing environment.

Description

Description METHOD AND SYSTEM FOR APPLICATION PERFORMANCE MANAGEMENT Technical Field

[I] The present invention relates to the application performance management and more specifically to the automated tests, analyses and monitoring the performances of the applications in the multi-tiered, distributed computing environment to optimize or to predict the performances of the applications or the individual server or the entire system. Background Art

[2] Today's computing environment has grown from client-server computing environment to the multi-tiered, distributed computing one in which web servers, database servers, middleware servers and server applications play their roles to accomplish the client's requests. The servers in this environment will cooperate with one another to accomplish the client's requests.

[3] Generally, tests, analyses and monitoring the performance of the web application systems are performed according to the following process.

[4] Recording and saving a web client's requests (URL, Uniform Resource Locator) in order in which they were requested.

[5] And creating virtual web clients and have them replay the recorded requests.

[6] And analyzing the virtual web clients' responses and the performances of the web application systems.

[7] Here, in order to record and save the web client's requests, a client application is needed which can communicate with web application servers and can record and save the requests in order in which they were requested.

[8] Generally, tests, analyses and monitoring the performance of the database systems are performed according to the following process.

[9] Creating a database client's requests (SQLs, Structured Query Language) manually in order in which the real database client requested them.

[10] And creating virtual database clients and have them replay the created requests. And Analyzing the virtual database clients' responses and the performances of the database systems.

[II] Here, a database client's requests are created manually, not automatically, in most cases.

[12] These methods to make tests, analyses and monitoring the performance of the servers are not easily applicable to the systems in the multi-tiered, distributed computing environment. Methods and system are needed to make tests, analyses and monitoring the performance of the each server in the multi-tiered, distributed computing environment and to optimize and predict the performance of the entire system. Disclosure of Invention Technical Problem

[13] A method and system are needed to make tests, analyses and monitoring the performance of the each server and the entire system that is in the multi-tiered, distributed computing environment. A method and system for recording every request that is requested by each client and processed by each server in the multi-tiered, distributed computing environment is needed. For example, in a system which is comprised of a web client, a web server, a web application server and a database server, the web client make a request (URL) to the web server and the web server relays the requested URL to the web application server and the web application server processes the application identified by the requested URL and the application makes several database requests (SQLs) to the database server. The database server processes the requested SQLs and the responses will go to the application in the web application server and the application in the web application server will send its response to the web server and the web server finally sends the final-response to the web client. Here, a method is needed to record and save the web client's request (URL) and at the same time, to record and save web application's requests (SQLs). And more, a method is needed to record and save the sequences, the response times, the response codes of every URL and SQL that made by every client and every server in each tier.

[14] The information of the recorded URLs and SQLs that requested by each client and processed by each server makes it possible to analyze the performance of the servers in each tier. And the information also makes it possible to make tests and monitoring to analyze and optimize each server in each tier.

[15] The present invention is presented to solve the above-mentioned problem and an object of the present invention is to provide a method and system for recording requests of the every client and every server in each tier in the multi-tiered, distributed computing environment to make tests the performance of the servers in each tier.

[16] An object of the present invention is to provide a method and system for aggregating interrelated requests into a set and saving it into the repository so that users can make performance tests with the every set of requests and make a new set of requests by combining the saved sets of requests.

[17] An object of the present invention is to provide a method and system for analyzing the performances of the requests generated by an arbitrary number of virtual clients, the performances of the servers in each tier, the performances of the requests created by every server in each tier to accomplish the requests of the virtual client in the first tier. Here, virtual clients make requests with the saved sets of requests in the repository.

[18] An object of the present invention is to provide a method and system for saving performance data of the tests into the repository and analyzing the data in the repository, subsequently ebables users to optimize the performances of the servers in each tier.

[19] An object of the present invention is to provide a method and system for monitoring the performances of the servers in real-time, having several virtual clients replay some requests eternally. Here, the requests are selected and queried from the repository on the basis of performance effect on the monitored system. Technical Solution

[20] The present invention to solve the above-mentioned problem comprises a controller, agents, a repository, a performance monitor, and a user interface. Specifically, the controller provides a job-scheduler, which manages the load tests which performed with the recorded requests of the clients, a workbench, which records the clients' requests and makes performance tests of the each request in real time, an analyzer, which analyzes the performance of the requests and servers with the performance data in the repository, a vuser, which creates a number of virtual clients and has them replay the requests and sends the result data to controller to save the data into the repository, a performance monitor, which monitors the status of the tests in real time. An agent can run on any machine independent of the location of ther servers run on. And an agent provides a bridge, which connects to its server with the communication protocol that the server uses when communicating with its clients, a log-manager, which gathers the performance data of the clients' requests and sends the data into the repository. The repository is a database management system that manages tasks, (a task is the smallest set of requests), jobs (a job is a combination of tasks), every individual client's request, the performance data of the servers.

[21] The key point of the present invention is the roles of the agents of the servers in each tier in the multi-tiered, distributed computing environment. Each agent accepts the client's requests in place of the servers in each tier and sends the received requests to the server that the agent is connected to with communication protocol and receives the responses from the server and then sends the responses to the client. Meanwhile, each agent saves the details of the each client's requests and the server's responses into the repository so as to use them later for analyzing the performances of the servers in each tier and for replaying the recorded requests of the clients in each tier to make performance tests. [22] In this way, an agent gathers the details of the clients' requests and the server's responses residing between the clients and the servers by supporting the protocol that the clients and the servers use when communicating with each other. [23] Each client/server in each tier must be configured to send its requests to the agent instead of its server. Each agent saves the details of the clients' requests and the server's responses into the repository. [24] Advantageous Effects

[25] According to the present invention, the tests, analyses and monitoring the performance of the clients' requests and the servers' responses in the multi-tiered, distributed computing environment make it possible to optimize and predict the performance of the individual request as well as the performance of each server in that environment.

[26] And according to the present invention, the tests, analyses and monitoring the performances of the clients' requests and the servers' responses in the multi-tiered, distributed computing environment are possible independent of the application languages, the operating systems and the underlying hardware, because the agents gathers the details of the clients' requests and the servers' responses using the protocols only that clients and servers use when communicating with each other.

[27] And according to the present invention, it is possible to reuse the test conditions and scenarios and analyze, predict the performances of the requests and the performances of the servers in detail, because the tasks, jobs (which are the test conditions and scenarios) and performance data are all saved and managed in the repository database.

[28] And according to the present invention, it is possible to monitor constantly the performance of the servers under operation in the multi-tiered, distributed computing environment without much load on the servers by making tests constantly on the servers with a job in which tasks are comprised of the selected requests that having critical effects on the performance of the servers. Brief Description of the Drawings

[29] Figure 1 is a block diagram of a preferred embodiment of the present invention which comprising the controller, the agents, the repository, the performance monitor and the user interface.

[30] Figure 2 is a block diagram illustration of a configuration of an embodiment of the present invention in which a database server and its clients are in the computing environment.

[31] Figure 3 is a block diagram illustration of a configuration of an embodiment of the present invention in which a database server, a middleware server, a web application server and their clients are in the computing environment (3-tierd).

[32] <Names of the blocks in the figures>

[33] 10. Controller

[34] 11. VUser 12. Workbench 13. Job-Scheduler 14. Analyzer

[35] 20. Repository

[36] 30. Performance Monitor

[37] 40. Agents

[38] 41. Web Agent 42. Middleware Agent 43. Database Agent

[39] 50. User Interface

[40] 60. Servers

[41] 61. Web Application Server 62. Middleware Server 63. Database Server

[42] 70. Client Applications

[43] 71. Web Client 72. Middleware Client 73. Database Client

[44] Best Mode for Carrying Out the Invention

[45] A preferred embodiment of the present invention will now be described, by way of example, with reference to the accompanying drawings.

[46] The figure 1 is a block diagram describing a preferred embodiment of the present invention which comprises a controller(lθ), a repository(20), a performance monitor(30), agents(41,42,43), a user interface(50), which makes possible to record and manage clients' requests in every tier and to make tests, analyze, monitor the performances of the severs in every tier with the recorded clients' requests.

[47] As shown in figure 1, the system to make tests, analyze, monitor the performance of the servers in the multi-tiered, distributed computing environment according to the present invention comprises a controller(lθ), a repository(20), a performance monitor(30), agents(40) and a user interface(50).

[48] The controller (10) comprises vuser(l 1), a workbench(12), a job-scheduler(13) and an analyzer(14).

[49] The vuser(l 1) has means to communicate with each server in each tier.

[50] The repository(20) is a database management system which supports standard SQLs.

[51] The performance monitor(30) is a window application.

[52] The user interface(50) is a standard web browser.

[53] The agents(41,42,43) connect the servers(61,62,63) with the supported protocols respectively and may not run on the same machine that the connected servers run on and gathers the clients' requests and the servers' responses and saves them into the repository(20). [54] With the system that created according to the present invention, users can make tests, analyze and monitor the performance of the servers in the multi-tiered, distributed computing environment only if the users have a user interface(50) and optionally, the client applications(70) of the servers(60). [55] <Recording and managing clients's requests>

[56] Firstly, the recording clients' requests are necessary to test, analyze the performances of the servers in the multi-tiered, distributed computing environment. It is divided into two cases whether the web clients can access the servers or not. [57] In case it is possible to access the server with the web browser, it comes under the figure 1. [58] In this case, users navigate to accomplish a certain tasks with the user interface (50, web browser), the workbench (12), the web agent (41) and the web application server (61). [59] The web agent (41) gathers the performance data and saves them into the repository (20), here the performance data are requested URLs, the time intervals between the requests (stay times), the response times, response codes, response sizes, http request headers, http response headers and cookies for example. [60] And users create tasks by querying the recorded URLs from the repository(20) with the user interface(50) through the workbench(12). Here, the tasks are the sets of requests and the basic unit of test scenarios. [61] In the mean time, for the middleware tier, the web application server(61) which connected to the middleware server(62) by the middleware agent(42) makes RPC(remote procedure call) requests to middleware agent(42) to accomplish the URLs requested by the web clients. [62] The middleware agent(42) gathers the performance data of the PRC requests and saves them into the repository (20). [63] And users create tasks by querying the recorded RPC requests from the repository(20) with the user interface(50) through the workbench(12). [64] And for the database tier, the middleware server(62) which connected to the database server(63) by the database agent(43) makes SQL requests to the database agent(43) to accomplish the RPC requests requested by the web application server (61). [65] The database agent(43) gathers the performance data of the SQL requests and saves them into the repository (20). [66] And users create tasks by querying the recorded SQL requests from the repository(20) with the user interface(50) through the workbench(12). [67] In case it is impossible to access the server with the web browser, users accomplish a certain tasks with the client applications of the server.

[68] In a configuration in which a database server and its clients are in the computing environment, as shown in figure 2, for example, the database agent(43) gathers the performance data and saves them into the repository (20), here the performance data are requested SQLs, the time intervals between the requests (stay times), the response times, response codes and response sizes.

[69] And users create tasks by querying the recorded SQL requests from the repository(20) with the user interface(50) through the workbench(12).

[70] The sets of the client's requests to the servers in each tier are saved in the repository(20) as tasks. The IP addresses of the servers, iteration options, time intervals between the two requests as well as the requests themselves are saved in the repository (20).

[71] For http, http request headers such as query string, cookie, referer, user-agent, authentication and content-type as well as the requested URL itself, iteration options and stay times are saved in the repository (20).

[72] Applying some functions on the properties of the clients' requests makes it possible to make a variety of tests with varying conditions, the functions are sequence(F,T,I), file('data.txt') and random(F,T).

[73] The sequence(F,T,I) function replaces its value with a number from F to T incremented or decremented by I while loops.

[74] The file('data.txt') function replaces its value with a line data from the data.txt file while loops.

[75] The random(F,T) function replaces its value with a random number between F and T while loops.

[76] The job-scheduler(13) make performance tests according to a job which is combined with the tasks. Setting iteration option to each tasks when combining tasks makes it possible to create a variety of performance test scenarios. All the tasks and jobs can be reused and commonly used by all users because they are all saved and managed in the repository(20).

[77] <Analyzing the sequences, the response times, the response sizes, etc. of all the requests processed in each server, which are induced by the first-tier client's requests to the first-tier server>

[78] With the help of the performance data of the requests and responses gathered by each agent(40) in repository(20), users can analyze the sequences, the response times, the response sizes, etc. of all the requests processed in each server, which are induced by the first-tier client's requests to the first-tier server.

[79] In figure 1, let the web-tier be the first-tier, so that web clients can communicate with the entire system by accessing the web-tier server. [80] Users make performance test with a URL that selected from the recorded URLs from the repository(20) with the user interface(50) and the workbench(12).

[81] The web agent(41) saves the performance data of the requested URL into the repository(20), which processed in the web application server(61).

[82] The middleware agent(42) saves the performance data of the requested RPC requests into the repository (20), which are requested by the web application server(61) to the middleware server(62) to accomplish its(61) requested URL.

[83] The database agent(43) saves the performance data of the requested SQLs into the repository(20), which are requested by the middleware server(62) to the database server(63) to accomplish its(62) requested RPC requests.

[84] And finally, the workbench(12) analyze the sequence, the response times, the number of times of each request and the contents of the URL, SQLs, RPC requests that processed in the servers in each tier with the help of analyzer(14) ( which can access the repository(20) ) and sends the data to the user interface(50).

[85] In the meanwhile, the workbench(12) and all the agents(41,42,43) are exclusively locked, so that it is guaranteed that only one user could make performance test without interruptions of the other concurrent users.

[86] And more, using the same method described above, although the web-tier is not the first-tier, it is possible to analyze the sequence, the response times, the response sizes, etc of the requests which are induced and processed in all servers.

[87] <Analyzing the performances of other servers with a performance test to a server>

[88] It is possible to make tests the performance of a server with the user interface(50), a set of recorded requests, having created virtual clients load on the server and analyze, monitor the performance of the server and the performances of the requests.

[89] Here, if the tested server makes additional requests to other servers to accomplish its requests, each agent of each server will gather the performance data of the requests and saves the data into the repository. So, users can query the performance data of the every server from the repository with the user interface. With this method, users can test, analyze and monitor the performance of other servers just with a testing to a server.

[90] The above described can be completely understood through the detailed description of an embodiment below and the accompanying drawings;

[91] In figure 1, lets assume the above tested server be web application server(61), and the URLs are already recorded and saved in the repository(20).

[92] Scheduling a performance test to the web application server(61) with the user interface(50) and the job-scheduler(13), the vuser(ll) will create a number of virtual clients and have them make URL requests to the web application server(61).

[93] Then, web application server(61) will make RPC requests to the middleware agent(42) to accomplish the requested URLs.

[94] And then, the middleware agents(42) will sends the RPC requests to the middleware server(62), and receives the responses from the middleware server(62) and saves the performance data into the repository (20).

[95] Meanwhile, middleware server(62) will make SQL requests to the database agent(43) to accomplish the requested RPC requests.

[96] And then, the database agents(43) will sends the SQL requests to the database server(63), and receives the responses from the database server(63) and saves the performance data into the repository (20).

[97] And then, the vuser(l 1) will save the performance data of the requested URLs into the repository (20) after receiving the responses.

[98] Subsequently, in the repository(20), there saved the performance data of all the requests (URLs, RPC calls, SQLs) that processed in the servers. So, users can analyze the performances of the URLs, RPC calls, SQLs by querying the performance data from the repository (20).

[99] And the performance monitor(30) running inside the user interface(50) makes it possible to monitor the performances of the servers in real time through receiving performance data from the controller(30). Here, the controller(30) receives the performance data from the agents(40), the vuser(l 1) and the servers(60) (including system resource usage information).

[100] < Analyzing the performance of every request that induced and processed in each server with a performance test to a server>

[101] As described above, it is possible to analyze the sequences, the response times, the response sizes, the number of times, etc of the each request that induced and processed in each server using single virtual client and it is also possible to analyze the performances of other servers with a performance test to a server using a number of virtual clients.

[102] With the above two analyses , it is possible to analyze the sequences, the response times, the response sizes, the number of times, etc of the each request that induced and processed in each server as well as the performances of other servers with a performance test to a server using a number of virtual clients.

[103] The above described can be completely understood through the detailed description of an embodiment below and the accompanying drawings;

[104] In figure 1, there are web application server(61), middleware server(62) and database server(63).

[105] If users make performance tests to the web application server(61) with a number of virtual clients, the vuser(l 1) changes its status to be exclusively locked and creates a virtual client and has the virtual client test with each URLs to analyze the sequences, the response times, the response sizes, etc of each URL and induced RPC calls and SQLs and then saves the data into the repository (20). And then, the vuser(l 1) changes its status to be normal mode and make performance test with a number of virtual clients. In the meanwhile, each agent(40) in each tier saves the performance data of the requested URLs, RPC calls and SQLs into the repository (20).

[106] And then, users can query the sequences, the response times, the response sizes, etc of each requested URL, RPC call, SQL and can query the performance data of all the servers as well.

[107] <Managing, analyzing, and querying the performance data>

[108] Users can query a variety of information from the repository (20) with the user interface(50) through the analyzer(14), because all the performance data that tested and gathered are saved in the repository (20).

[109] Explaining this in more detail, the performance data can be queried by time, by day, by month and by year. The top/bottom-N ranked queries on the performance data such as response times, response sizes and bytes per second can be performed from the repository(20).

[110] It is possible to query performance data based on varying test conditions, the number of virtual clients, the staying times and the persistence options. And it is also possible to merge queried results into a new one so that users can compare and analyze the performances of the servers.

[Ill] <Monitoring and analyzing the systems under operation>

[112] Explaining this in detail along with the figure 3, having job-scheduler(13) and vuser(l 1) make performance tests constantly with the requests queried from the repository(20) based on the performance effect on the servers(60). Then, it is possible to monitor the performances of the servers(60) by the performances of the selected requests in real time. And because all the performance data are saved in the repository, it is possible to analyze and monitor in detail the performance of the systems(60) under operation with the user interface(50) and the analyzer(14).

[113] Mode for the Invention

[114] Although above-described embodiments are particular examples of the methods and system for application performance management, it will be understood that the present invention is not limited thereto and many modifications and additions are possible within the scope of the present invention's technology.

[115] For example, the present invention can be used in the multi-tiered, distributed computing environment in which following servers are running. Xml database servers, web servers, ERP solutions, CRM(Customer Relationship Management) solutions that support HTTP(HTTPS) protocol and CORBA(Common Object Request Broker Architecture) middleware that supports IIOP(Internet Inter-Object Protocol) and EJB (Enterprise Java Beans) servers that supports RMI(Remote Method Invocation) protocol and any servers that support FTP(File Transfer Protocol), TELNET, SMTP(Simple Mail Transfer Protocol), POP3(Post Office Protocol 3), IMAP(Internet Message Access Protocol), NNTP(Network News Transfer Protocol), MMS(Microsoft Media Service), RTSP(Real Time Streaming Protocol), SOCKS(Firewall Protocol) protocols.

[116] Industrial Applicability

[117] According to the methods and system of the present invention, it is possible to optimize the performance of the developing system through the tests, analyses the performances of the systems when companies are developing their information systems, internet shopping malls or web sites. And it is possible to predict the performances of the systems before it starts to service officially through a variety of tests and analyses. Making a company's IT systems have better performance, lowers costs of management of the systems, of course it is beneficial to the company. The monitoring the performances of the servers constantly in the multi-tiered, distributed computing environment makes the entire system have high performance and high availability.

Claims

[1] A method for recording the URLs, RPC calls, SQLs that requested and processed by the servers in the multi-tiered, distributed computing environment to use later for performance tests or for replaying the communications, said method comprising the steps of; Running agents for each server to relay the requests and the responses between the clients and the server; Setting the the configurations of the applications with the IP addresses and port numbers of the agents instead of the those of the servers, the applications are running on the servers, so that the applications' requests go to the agents, not to the servers; Using the user interface or the client's applications, connecting to the first-tier agent and making requests to the agent that connects the first-tier server that will service to the client's request; The first-tier agent receiving the client's request, sending the request to the connected, the first-tier server, receiving the response from the first-tier server and saving the performance data of the request and the response into the repository; The first-tier server making additional requests to the second-tier agent to accomplish the first-tier client's request, the second-tier agent receiving the requests from the first-tier server and sending the requests to the second-tier server that is connected by the second-tier agent; The second-tier agent receiving the first-tier server's requests, sending the requests to the connected the second-tier server, receiving the response from the second-tier server and saving the performance data of the requests and the responses to the repository; In this way, having each agent for each server save the performance data of the requests that made by the clients and each server and the responses that processed by each server into the repository;

[2] A method for analyzing the performance data such as the sequence, the response times and the response sizes of the requests, where the requests are typically URLs, RPC calls and SQLs that requested by the clients and the servers in the multi-tiered, distributed computing environment, said method comprising the steps of; Running agents for each server to relay the requests and the responses between the clients and the server; Setting the the configurations of the applications with the IP addresses and port numbers of the agents instead of the those of the servers, the applications are running on the servers, so that the applications' requests go to the agents, not to the servers; Using the user interface or the client's applications, connecting to the first-tier agent and making requests to the agent that connects the first-tier server that will service to the client's request; The first-tier agent receiving the client's request, sending the request to the connected, the first-tier server, receiving the response from the first-tier server and saving the performance data of the request and the response into the repository; The first-tier server making additional requests to the second-tier agent to accomplish the first-tier client's request, the second-tier agent receiving the requests from the first-tier server and sending the requests to the second-tier server that is connected by the second-tier agent; The second-tier agent receiving the first-tier server's requests, sending the requests to the connected the second-tier server, receiving the response from the second-tier server and saving the performance data of the requests and the responses to the repository; In this way, having each agent for each server save the performance data of the requests that made by the clients and each server and the responses that processed by each server into the repository, where the requests are typically URLs, RPC calls and SQLs; By querying the performance data from the repository, analyzing the sequences, the response times, the response sizes of the requests that processed by each server. [3] A method for analyzing the performance metrics of the servers such as mean response times, transactions per second, bytes per second and the performances of the requests such response times, response sizes using virtual clients, user interface and the sets of clients' requests (typically sets of URLs, RPC calls, SQLs) in the multi-tiered, distributed computing environment, said method comprising the steps of; Running agents for each server to relay the requests and the responses between the clients and the server; Setting the the configurations of the applications with the IP addresses and port numbers of the agents instead of the those of the servers, the applications are running on the servers, so that the applications' requests go to the agents, not to the servers; Preparing for the load test by creating tasks and jobs that are the test scenarios, using the user interface and job-scheduler, Using the ability of the virtual clients to make requests(URLs, RPC calls, SQLs) to the servers, having the virtual clients perform the load test according to the test scenarios described in the created job. The tested server making requests to an agent to accomplish the virtual clients' requests, the agent sending the requests to a server that is connected by the agent; The agent receiving the virtual clients' requests, sending the requests to the connected the server, receiving the responses from the server and saving the performance data of the requests and the responses into the repository; In this way, having each agent for each server save the performance data of the requests and the responses that requested and processed by each server into the repository, where the requests are typically URLs, RPC calls and SQLs; The virtual clients receiving the responses from the tested server and saving the performance data of the requests and the responses to the repository; By querying the performance data from the repository, users can analyze the performances of the servers such as mean response times, transactions per second, bytes per second and the performance of the requests such as the sequences, the response times, the response sizes of the requests that processed by each server. [4] A system for making tests, analyses and monitoring the performances of the servers in the multi-tired, distributed computing environment, the system comprising; A controlled 10), agents(40), a repository(20), a performance monitor(30) and a user interface(50); The controller (10) comprising; Means(l 1) for creating a number of virtual clients and communicating with the servers in each tier; means(12) for making performance tests under exclusive lock and communicating with the agents(40) to analyze the performances of the requests and servers in each tier, means(13) for scheduling the test scenarios, the jobs with various test conditions; means for communicating the performance data with the performance monitor(30); means for querying the recorded requests from the repository (20); means(13) for creating a test scenario (a job) combining the recorded set of requests (tasks) from the repository (20); means(14) for communicating with the repository (20) and querying the performance data from the repository (20); The agents(40) comprising; means for communicating with the connected server with the supported communication protocol; means for gathering the performance data of the client's requests that are requested to the connected server and saving the data into the repository (20); means for making exclusive lock status for only a client communicating with the agent;

The repository (20) comprising; means for communicating with the controlled 10) and saving the performance data; means for communicating with the agents(40) and saving the performance data; The performance monitor(30); means for communicating with the controlled 10) and receiving the performance data of the servers in each tier; means for displaying the performance data of the servers which received from the controlled 10); The user interface(50) comprising; means for users communicating with the controlled 10), the agents(40) and the performance monitor(30);