JP4867864B2 - Performance data collection / display system, performance data display device, and program thereof - Google Patents

Description

  The present invention relates to a performance data collection method for each function of an application program executed on a server in response to a request from a client in a system including a client and a server.

  In a system consisting of a client and a server, check the performance of the application program (for example, which function is taking a long time, etc.) when there is a problem in performance such as slow response of the application program running on the server. As a method, a method of incorporating a mechanism for collecting performance data (such as processing time of the above function) into a source program of an application program has been common.

FIG. 22 shows a conventional system configuration and performance data collection method.
In FIG. 22, a client 100 is a general-purpose computer such as a personal computer owned by a general user, for example, and executes a client program 101 such as a browser on a general OS 102 environment to thereby display a network such as a LAN (not shown) or the Internet. The Web / Ap server 80 is accessed via a request for an arbitrary process. For example, a homepage or the like is displayed.

  The Web / Ap server 80 is a Web server / Ap (application) server, which implements various application programs, executes applications in response to requests from the client 100, and displays, for example, a home page on a display on the client 100 side. Let it be done.

  These various applications are composed of JSP / Servlet 81 and Java class 82. Note that these various applications are executed in a general Java execution environment (OS 85, Java VM (Java virtual machine) 84, Servlet container 83) as shown in the figure. JSP is an abbreviation for Java Server Pages.

  In general, the JSP / Servlet 81 performs basic operations of various applications, the Java class 82 required by the JSP / Servlet 81 is called at any time, and the method (function) of the called Java class 82 is executed.

  If you want to collect performance data (for example, processing time of each function, etc.) for any application (especially each method (function) of Java class 82) among the various applications consisting of JSP / Servlet81 and Java class 82 above, First, the source code file of the performance data collection target application is opened on the personal computer (PC) 90, and the performance data collection processing is added and described in this source program by the operator or the like manually (on FIG. 22). (1)).

  Subsequently, the new source code 91 (source code additionally describing performance data collection processing) is compiled to generate an execution module 92 (with performance data collection function) ((2) shown in FIG. 22). Then, in the Web / AP server 80, the performance data collection target application (execution module) is replaced with the execution module 92 with the performance data collection function ((3) shown in FIG. 22).

After that, by executing the execution module 92, performance data (processing time of each function, etc.)
Collection processing will also be performed.
Collect performance data (processing time of each function, etc.) of OS, middleware, and application program to identify the cause when there is a performance problem such as slow response of application program running on server. Analyzing the collected performance data and displaying it in a graph is a common practice.

  Conventionally, as described above, performance data collection processing is embedded in each application program (such as Java class 82), and the processing time of each function is collected and analyzed, for example, as shown in FIG. In this way, the processing time for each function is displayed in a graph. In addition, the performance data of the OS and middleware can be collected by an existing function such as a performance monitor of Windows (registered trademark), for example, and the collected data is displayed in a graph as shown in FIG. 23B, for example.

As is well known, a method in Java corresponds to a “function” and may be called a function as described above.
The prior art described in Patent Document 1 relates to a log information collection / analysis apparatus, and aims to take correspondence between a display portion of a chart indicating an operation state during program execution and a source program. In the present invention, the function name and line number on the source program corresponding to the position can be known from the position information on the chart designated by the user. Conversely, the display position on the chart can be known from the function name and line number specified by the user.
Japanese Patent Laid-Open No. 9-259011

In the above-described conventional technology, the following problems have occurred.
(1) The performance data collection / aggregation results of the application program do not have information to identify the client (browser) or request when this function is called for each function. Since the processing time cannot be grasped, it was difficult to identify when there was a problem specific to the client or request.

  (2) Since OS / middleware performance data and application performance data can only be displayed separately, the correlation between the movement of the application and the state of the OS / middleware is difficult to grasp, and efficient cause analysis cannot be performed. .

  An object of the present invention is that performance data can be collected for each function to identify a client / request related to the execution of the function. This makes it easy to specify when there is a problem specific to a client or a request. Performance data collection and display that enables efficient and accurate performance bottleneck analysis by overlaying and displaying the processing time of the unit and the OS / middleware resource status (display by table, bar, graph, etc.) It is to provide a system, a performance data display device, its program, and the like.

The performance data collection / display system of the present invention stores a session ID and a request ID corresponding to this request in a predetermined storage area each time an arbitrary request is received from an arbitrary client. A first performance data collecting unit that records predetermined log information in association with the application, an application execution unit that executes processing of one or more predetermined functions in response to the request, and At the time of processing execution, the session ID and request ID are acquired from the predetermined storage area, and predetermined performance data related to the processing execution of each function is added to the log information in association with the session ID and request ID. A second performance data collecting means for recording;
Based on resource status data collection means for collecting data indicating the resource status of the OS / middleware and the recorded log information, the start date / time, end date / time, and processing time of the entire process corresponding to each arbitrary request are obtained. Or, for each function, the start date and time and end date and time of the processing of the function, and the execution time that is the time taken to execute the processing of the function are obtained, and the obtained information is associated with the session ID and the request ID. Internal data generating / storing means for generating / storing internal data, and visualization showing the processing time of the entire processing for each arbitrary request or the execution time of each function in the entire processing based on the internal data Display means for displaying and superimposing the visualization display based on the resource status data on the same time axis as the display.

  In the performance data collection / display system, performance data and the like of each function is recorded in association with a session ID and a request ID corresponding to an arbitrary request from the arbitrary client. Therefore, if this record is referred to / analyzed, for example, the processing time of the entire process for each session request, the execution time of each function in the entire process, and the like are obtained, and the display based on this and the resource status data By doing so, it becomes possible to easily grasp the location where there is a problem (for example, processing of a session request in a time zone in which the resource status deteriorates). Or, for example, the same function, but corresponding to a specific session request, if only the performance data is bad (such as long execution time), it can be inferred that there is some problem inherent to this specific session request .

  In the performance data collection / display system, for example, the program for realizing the second performance data collection means and the application execution means includes a predetermined log output process and an arbitrary log output target / log output location. It is generated by aspect-compiling the described aspect source file and the application program related to the function processing.

  As a result, it is not necessary to add a log output process to a necessary part for each application program, and it is sufficient to create one aspect source file.

  According to the performance data collection / display system, performance data display device, program thereof, and the like of the present invention, it is possible to collect performance data that can identify a client / request related to the execution of the function for each function. If there is a problem, it is easy to identify, and the processing time for each function of the application program and the OS / middleware resource status are superimposed and displayed (displayed in a table, bar, graph, etc.) for efficiency. And accurate performance bottleneck analysis becomes possible. Furthermore, processing for collecting performance data can be easily added.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 shows a system configuration diagram of a system including a client and a server in this example.
In FIG. 1, the client 100 may be the same as the conventional client 100 (a general user's personal computer equipped with a browser, etc.), and is denoted by the same reference numeral, and description thereof is omitted.

In the illustrated Web / Ap server 10, various applications are executed in a general Java execution environment (OS 15, JavaVM (Java Virtual Machine) 14, Servlet container 13), similarly to the above-described conventional Web / Ap server 80. Will be. The various applications include JSP / Servlet 11 and Java class 12. As described above, the JSP / Servlet 11 calls each Java class 12, and each Java class 12 executes one or more methods (functions). In general, the Java class 12 is called a method ( (Function).

In the configuration of this example, the Web / Ap server 10 further includes a first performance data collection program (Servlet filter) 16 and a second performance data collection program 17.
The first performance data collection program (Servlet filter) 16 and the second performance data collection program 17 (and other various programs such as JSP / Servlet 11 and Java class 12) are shown in FIG. The data is stored in the storage unit 75 and is read and executed by the CPU 71 to realize a predetermined function / operation. The following is not particularly noted, but naturally, it relates to various programs in the following description. The description of the function / operation describes the function / operation realized by executing these various programs by an arithmetic processor such as the CPU 71.

  The first performance data collection program (Servlet filter) 16 is a Servlet filter program which is one of Java server application forms, and operates on a Servlet container 13 which is an execution environment of a Servlet or JSP. This program is different from the application program and is deployed and used in the execution environment of the application program.

  The first performance data collection program (Servlet filter) 16, as will be described in detail later, every time an arbitrary request from an arbitrary client 100 is received (and for each response), a session ID, Get the request ID, thread name, date / time information, etc., and record it in the log file. When receiving a request, the session ID and the request ID are stored in a predetermined storage area, and passed to the second performance data collection program (Java class) 17 via the storage area.

  The second performance data collection program (Java class) 17 obtains the session ID and the request ID by referring to the predetermined storage area every time the program is executed, and further acquires the thread name, date / time information, method Get the name (function name) etc. and record them in the log file.

  The second performance data collection program (Java class) 17 is executed by being called at an arbitrary timing from the application program (Java class 12) being executed as shown in FIG. This call timing is, for example, when an arbitrary method (function) for log output is executed (for example, at the start / end thereof). As a result, for example, the date / time information (execution start / end time of the function, etc.) of the executed function is associated with the session ID and request ID indicating the client or request related to the function execution, and the log file Will be recorded.

  As described above, the application program (Java class 12) includes call processing at an arbitrary timing, but this does not exist from the beginning, and is added as necessary. That is, an application program (Java class 12) having a call process is generated together with the second performance data collection program (Java class) 17 as necessary. This generation process is not time-consuming as in the prior art, and can be easily generated as described below. As described later, the second performance data collection program (Java class) 17 may be included in the application program (Java class 12).

Hereinafter, generation processing of the application program (Java class 12) and the second performance data collection program (Java class) 17 will be described.
The application program (Java class 12) and the second performance data collection program (Java class) 17 are a byte code of the application program, an arbitrary log output target function in the application program, and a log output location in the function (example : Function start point, function end point), and the source file of the aspect program describing the log output processing is generated by compiling with the aspect compiler.

  The aspect program is a program according to a so-called “aspect-oriented programming” (abbreviated as AOP) technique. In short, AOP is a programming technique in which functions required across the system are grouped as “aspects” in one place. Therefore, the aspect program describes processing common to a plurality of application programs (eg, log output processing).

Hereinafter, a method for generating the second performance data collection program (Java class: aspect program) 17 and the like will be described with reference to FIG.
The second performance data collection program (Java class) 17 (and Java class 12) includes a byte code (.class file) 22 (hereinafter referred to as application program 22) of the application program shown in FIG. A source file (.aj file) 21 (hereinafter referred to as aspect source file 21) is generated by compiling with the aspect compiler 20 (hereinafter referred to as aspect compilation). In the aspect source file 21, a log output target function of the application program 22, a log output location in the function (eg, function start point, function end point), and log output processing are described by a programmer or the like.

  Then, as a result of compilation by the aspect compiler 20, (3) aspect program (.class file) 23 and (4) application program (.class file) 24 shown in FIG. 2 are generated. The aspect program (.class file) 23 corresponds to the second performance data collection program (Java class) 17 shown in FIG. 1, and the application program (.class file) 24 corresponds to the Java class 12.

  The application program 22 is an application program (Java class 12) before aspect compilation, and the second performance is provided at each log output location of each log output target function described in the aspect source file 21 by the aspect compilation. Call processing of the data collection program (Java class) 17 is inserted, and this is the application program (.class file) 24.

The source files / programs before and after compilation by the aspect compiler 20 will be described together below.
(1) Aspect source file (.aj file) 21;
A source file describing a specific log output target function among the functions of the application program 22, a log output location (eg, function start point, function end point) related to the log output target function, and log output processing. Write in a language similar to Java.

(2) Application program (.class file) 22;
Byte code obtained by compiling an application source file with a Java compiler. This corresponds to the conventional Java class 82 (however, the version without processing time collection processing).

(3) Aspect program (.class file) 23;
The second performance data collection program (Java class) 17 is generated as a result of aspect compilation of the aspect source file 21. The log output process is performed by the application program (.class file) 24 calling at each log output location in each log output target function defined in the aspect source file 21. In other words, the aspect program (.class file) 23 itself basically only performs a predetermined log output process.

(4) Application program (.class file) 24;
A program in which the calling process of the aspect program (.class file) 23 is embedded in each log output location as shown in FIG. 4B, for example, by performing aspect compilation on the application program 22.

  The aspect program (.class file) 23 and the application program (.class file) 24 generated as described above are deployed and replaced in the application execution environment as shown in FIG. 3, for example (as described above, these programs 23 , 24 correspond to the second performance data collection program (Java class) 17 and Java class 12), and the performance data of the application program can be collected.

  In addition, what is shown in FIGS. 1-3 is an example, and is not restricted to this example. That is, as is well known, the compiler according to the above “aspect-oriented programming” method can also integrate the aspect program and the application program.

  In this case, as shown in FIG. 4A, for example, one program in a format in which the aspect program 23 is embedded in the application program 22 is generated by the aspect compilation process. Naturally, the position where the aspect program 23 is embedded is each log output location (for example, the start / end time of the function) related to each log output target function described in the aspect source file (.aj file) 21. Also in this case, the embedded aspect program 23 itself executes the log output process.

  On the other hand, in the example used in this description, as described above, the two programs are not integrated into one, and the aspect program (.class file) 23 and the application program (.class file) 24 are generated.

  In the application program (.class file) 24, as shown in FIG. 4B, processing for calling the aspect program (.class file) 23 is embedded in the application program (.class file) 22 before compilation. Will be. The position where this call processing is embedded is, of course, the log output location described in the aspect source file (.aj file) 21. Then, the called aspect program (.class file) 23 executes the log output process.

  As is well known, one “class” usually has one or more “methods (functions)”. For example, all the “classes” are the application programs 22 and the aspect source file ( In the “class” having the function designated by the .aj file) 21, the calling process may be embedded in the execution location of the function, or “class” designated by the aspect source file (.aj file) 21 Only the “class” may be input to the aspect compiler 20 as the application program 22.

FIG. 5 is a diagram illustrating the operation of the entire system including the client and the server in this example.
When the Web / Ap server 10 receives an arbitrary request sent from a browser or the like of an arbitrary client 100, first, the first performance data collection program (Servlet filter) 16 performs processing shown in FIG. The session ID and request ID obtained by the above are stored in the thread-specific variable area 31 in the main storage device 30. Needless to say, the session ID is an identification code for identifying each session, the request ID is an ID unique to each request, and the thread-specific variable area 31 is a variable area assigned to each thread. .

  The first performance data collection program (Servlet filter) 16 further acquires various types of information such as date / time information, thread name, process start / end information, access URL, and the like by the process of FIG. Then, the acquired information is written in the log file 41 in the auxiliary storage device 40 (hard disk or the like) together with the session ID and request ID.

Subsequent to the processing by the first performance data collection program (Servlet filter) 16, the Java application (JSP / Servlet 11, Java class 12) corresponding to the received request is executed. (JSP / Servlet 11 is executed, and a function called from the thread is executed.)
When an arbitrary Java class 12 is executed, if the Java class 12 is embedded with the call process, the aspect program (.class file) called by executing the call process is executed. ) 23 (second performance data collection program (Java class) 17) is executed.

  This call timing is arbitrarily specified by the user or the like in the source program, for example, at the start / end of the execution of the function, and will be described here using this example.

  The called second performance data collection program (Java class) 17 executes the processing shown in FIG. 7 to be described in detail later, thereby the session ID, request ID, and the like stored in the variable area 31 unique to the thread. Various information such as date / time information, thread name, processing start / end information, access URL, and the like are written in the log file 41 in the auxiliary storage device 40 (hard disk or the like), for example.

  The above-described various processes are temporarily stored in the main storage device 30, and auxiliary storage is performed from the main storage device 30 at a timing when a series of processing (execution of all functions called in response to the request) is completed. You may make it output to the log file 41 on the apparatus 40. FIG.

Hereinafter, processing executed by the first and second performance data collection programs will be described with reference to FIGS.
As described above, FIG. 6 is a process flowchart diagram of the first performance data collection program (Servlet filter) 16, and FIG. 7 is a process flowchart diagram of the second performance data collection program (Java class) 17.

First, the process shown in FIG. 6 will be described.
As shown in FIG. 6, each time the first performance data collection program (Servlet filter) 16 receives an arbitrary request from an arbitrary client (step S11), first, a session ID that is automatically assigned by the Ap server. And the request ID that the program (Servlet filter) counts / generates in the program when the request passes is stored in the thread-specific variable area 31 (step S12). Also, a thread name given inside Java is acquired (step S13). Further, date / time information indicating the current date and time (or the time when the request is received) is acquired from a system clock (not shown) in the Web / Ap server 10 (step S14).

And various information acquired by each of the above processes, that is, current date / time information, session ID, request ID, thread name, process start / end information, access URL
Is written in the log file 41 (step S15).

  The process start / end information is simply information indicating whether the process is started or ended in response to an arbitrary request, and is naturally “start” when a request is received. The first performance data collection program (Servlet filter) 16 also executes the processing of FIG. 6 when a series of processing according to the request is completed and a response is returned. Naturally, the start / end information is “end”. The access URL is the URL of the requested homepage (access destination).

Next, the process of FIG. 7 will be described below.
Of the processes in each step shown in FIG. 7, the processes executed by the second performance data collection program (Java class) 17 itself may be regarded as steps S24 to S27. That is, the processing in steps S21 to S23 may be considered to mean processing until an arbitrary second performance data collection program (Java class) 17 is called. That is, every time the JSP / Servlet 11 calls an arbitrary Java class 12 (step S21), if there is no log output target function in the Java class 12 (step S22, NO), that is, the calling process is completely embedded by the above aspect compilation. If not, naturally, the second performance data collection program (Java class) 17 is not called, and only the processing of the Java class 12 is executed.

  On the other hand, when there is a log output target function (step S22, YES), a call process embedded in the log output location (function execution start / end time, etc.) is executed along with the execution of the log output target function. Each time it is executed (step S23, YES), the called second performance data collection program (Java class) 17 executes the processing of steps S24 to S27.

  That is, first, the session ID and the request ID stored in the thread specific variable area 31 corresponding to the thread are acquired (step S24), and the thread name given inside Java is acquired (step S25). Further, the date / time information of the current date and time (or the time when the call is received, etc.) is acquired from the system clock (not shown) in the Web / Ap server 10 (step S26).

  Then, various information acquired in each process, that is, current date / time information, session ID, request ID, thread name, and process start / end information, access URL, function name (caller) The function performance data is written in the log file 41 (step S27).

The start / end information and the function name (of the caller) may be passed as parameters during the call process, or other methods may be used.
Through the processing described above, the same session ID and request ID are stored in the performance data related to all log output target functions corresponding to an arbitrary request from an arbitrary client (session). When analyzing the collected performance data, for example, list the processing times related to the same function by each request, and if there is a processing time that is very long compared to others, the performance data of this function It is easy to specify when there is a problem specific to the client or the request, such as inferring that there is a problem specific to the client or the request from the included session ID and request ID. FIG. 8 shows how the log file 41 is stored. An example of a data format is shown.

In the example shown in the figure, the table 50 of the log file 41 (hereinafter also referred to as performance data 50) includes year / month / day / hour / minute / second. It consists of data items such as millisecond 51, log level 52, session ID 53, request ID 54, thread name 55, start / end 56, URL 57, execution method information 58, etc. unrelated).

  Year / month / day / hour / minute / second. In the millisecond 51, the current date / time information is stored. As shown in this example, the date / time information includes the year, month, day, hour, minute, and second to the millisecond unit. Here, the millisecond is three digits.

The log level 52 is always “DEBUG”, which is not relevant here.
The session ID 53, request ID 54, thread name 55, start / end 56, and URL 57 store the session ID, request ID, thread name, process start / end information, and access URL, respectively.

The execution method information 58 stores the function name (method name) of the caller. Therefore, nothing is stored in the process of FIG.
According to the above-described system, it is not necessary to incorporate a mechanism for collecting processing time or replace modules for each source code of the application program. Furthermore, even when the same function is called from a plurality of clients and requests, the processing times of the functions corresponding to the clients and requests can be collected.

FIG. 9 and FIG. 10 are shown as drawings schematically showing the operation of the above-described embodiment, and FIG. 9 and FIG. 10 are briefly described below.
As described above, FIG. 9 is a diagram schematically showing the operation of the Web / Ap server 10 of the above-described embodiment, and FIG. 10 is a flowchart thereof.

  The operation shown in FIG. 9 is as described above. When there is an arbitrary HTTP request from the browser of an arbitrary client 100, the first performance data collection program (Servlet filter) 16 performs session information (session ID). , Request ID) and log output of the various information. Then, a Java application corresponding to the request is executed. As a result, the JSP / Servlet 11 causes each method (Java class 12) to be executed. If the Java class 12 has the call process inserted therein, the second performance data is obtained at the timing of the call process execution. The collection program (Java class) 17 is called. In this example, as described above, as an example, the calling process is executed at the start and end timing of the Java class 12 (function).

  As a result, as shown in the figure, the second performance data collection program (Java class) 17 performs the log output processing at the start and end timings of the Java class 12 (function).

  When all the Java application processes corresponding to the request are completed, the first performance data collection program (Servlet filter) 16 outputs the log when the response passes. Further, the session information is canceled. That is, the session information stored in the thread specific variable area 31 is deleted.

  FIG. 10 is a schematic process flowchart corresponding to FIG. Therefore, although it does not necessarily coincide with the actual operation (the actual operation has already been described in FIG. 5, FIG. 6, FIG. 7, etc.), it will be briefly described below.

In FIG. 10, when an arbitrary request is received (step S31), the generated session ID and request ID are stored in the thread specific variable area 31, and each time a function (Java class 12) corresponding to the request is executed. (Step S33), in the above example, the performance composed of the various information (session ID, request ID, date / time information, etc.) at the start of the function processing (Step S34, YES) and at the end (Step S36, YES). Data is acquired (steps S35 and S37) and written to the log file 41 (step S39).

FIG. 11 shows an example of log data written in the log file 41.
As shown in the figure, the log file 41 is executed for each combination of any identical session ID and request ID in response to access to the URL 57 (not shown here) by the same session ID and request ID. In other words, log data (performance data) such as a series of function processing executed in response to an arbitrary request from an arbitrary client (browser) is stored in the order in which it was written (log output processing execution order). Yes.

  Also, in the example of the figure, α and β are stored as the execution method information 58. This is because the two functions of method names (function names) α and β have a session ID = “1122” and a request ID = It means that the processing is executed in response to access to URL 57 (not shown here) by “3”.

  The four records related to the execution of the above methods (functions) α and β are that the execution method information 58 and the start / end 56 are “α; start” → “β; start” → “β; end” → “α; end”. Stored in order means that the method β is called during the execution of the method α. In other words, a plurality of “starts” that are consecutive means that an arbitrary function is being called. In this way, since records are recorded in the log file 41 in the order of log output at the start and end timing of each function, it is possible to analyze the calling relationship of other functions as described above.

  In addition, the execution method information 58 (function name) is not recorded in the first and last records in the illustrated series of records. This is because the HTTP is executed by the first performance data collection program (Servlet filter) 16. This means that the record is recorded by the log output process at the time of request reception and response. Processing related to reception and response of the HTTP request by the first performance data collection program (Servlet filter) 16 is referred to as “request reception / response processing”. Therefore, in the log file 41, a record related to “request reception / response processing” and a record related to each function execution (start / end) are recorded for each combination of any identical session ID and request ID. (For example, in the log recording process, the log file 41 may be searched using the session ID and request ID as keys, and a new record may be added to the end of the corresponding record group).

In FIG. 11, the date / time information (year / month / day / hour / minute / second.millisecond 51) omits the year / month / date / time, and the minute / second. Only milliseconds are shown. Further, as described above, a specific example of the URL 57 is omitted.
Hereinafter, processing for analyzing and displaying performance data collected as described above will be described.

  In this example, in order to visualize the performance data (display with a table, bar, graph, etc.), first, the data of the log file 41 is converted into internal data that is the basis of display of the table, graph, etc. An example of this conversion process is shown in FIG. An example of the internal data structure is shown in FIGS. Note that the processing of FIG. 12 is a processing example corresponding to the example of FIG.

FIG. 13 is a diagram showing a schematic hierarchical structure related to the internal data structure.
First, as shown in FIG. 13, an internal data file (not shown) for storing each internal data has a hierarchical structure such as a hierarchy 0, a hierarchy 1, a hierarchy 2,. Layer 0 is the highest layer.

  Layer 1 is a layer corresponding to each client (browser). In other words, each time there is an access from each new client (browser) that has not been accessed to the Web server so far (at least not in the internal data), a new data of level 1 is created.

Then, for each level 1, every time there is an arbitrary request from the client (browser) of level 1, new internal data of level 2 is created in the level 1.
Here, the hierarchy is considered to be divided into the hierarchy 1 and the hierarchy 2, but in reality, as described above (and as shown in FIG. 14 and the like), the performance with an arbitrary combination of “session ID and request ID” as one unit Since data collection / recording is performed, the data of the illustrated hierarchy 1 and hierarchy 2 will not be described in particular. The data composed of the hierarchy 1 and the hierarchy 2 may be considered as internal data created based on the performance data related to the “request reception / response process”.

  Then, every time there is log data recorded every time a function corresponding to the request is executed for each level 2, new internal data of the level 3 corresponding to the function is created. Further, whenever there is log data relating to another function called during execution of the function of the layer 3, new internal data of the layer 4 corresponding to the other function is created.

The conversion process to the internal data according to the hierarchical structure shown in FIG. 13 will be described with reference to FIG.
In the process of FIG. 12, the performance data stored in the log file 41 is read line by line (1 record) for an arbitrary log file 41 (step S41), and the processes after step S42 are performed for the read record. To implement.

  First, the internal data file is searched using the session ID of the read record to check whether or not there is a hierarchy 1 with the same session ID (step S42). , A new hierarchy 1 corresponding to this session ID (client (browser)) is created in the internal data file, and this is added at the end of hierarchy 0 (after the last hierarchy 1 of the group 1 already created). It adds (step S43).

  Furthermore, a new hierarchy 2 corresponding to the request ID of the read record is newly created and added to the end of hierarchy 1 (here, newly created hierarchy 1). Furthermore, the URL 57 of the record is stored in an arbitrary storage area (or variable) (hereinafter referred to as “start state”) provided on the main memory (step S45). Note that the present invention is not limited to this example, and “no function” may be recorded as the “start state”.

  Moreover, also when step S42 is YES and step S44 is NO, the process of step S45 is performed. Step S44 is a process of determining whether or not there is a hierarchy 2 with the same request ID as the request ID of the read record in the hierarchy 1 with the same session ID.

  After the process of step S45, the process proceeds to the determination process of step S51, and unless the reading of all records in the log file 41 is completed, the determination of step S51 is NO and the process returns to step S41 to read the next record. Will do.

It should be noted that when creating a new hierarchy below hierarchy 2 (hierarchy 2, hierarchy 3, hierarchy 4..., Etc.), each data (year / month / day / hour / minute / second / millisecond 51, session ID 53, request ID 54) of the read record. , URL 57 and execution method information 58) are also stored in the internal data file as a newly added record together with the hierarchy information ('2', '3', '4', etc.). In that case, year, month, day, hour, minute, second. The millisecond 51 is stored as a start date 64 described later.

  After the new hierarchy 2 corresponding to an arbitrary request ID is created by the process of step S45 described above, when the next and subsequent records are read from the log file 41, these records are displayed as shown in the example shown in FIG. It is performance data regarding each function executed in response to a request. Accordingly, the determinations at steps S42 and S44 are YES, and the process at step S46 is executed. In the process of step S46, it is determined whether an arbitrary function name (here, function name α) is stored in the “start state”. In the process related to the record immediately after step S45, since the URL is stored instead of the function name as described above, the determination in step S46 is NO, and the process proceeds to step S47.

  In the process of step S47, a new hierarchy 3 relating to the read record (performance data related to an arbitrary function) is newly created and stored at the end of hierarchy 2. Then, the function name (execution method information 58) of the record is stored as the function name α in the “start state”. And it returns to step S41 through determination of step S51.

  For the next record to be read, the determinations in steps S42, S44, and S46 are YES, and the process proceeds to step S48. In step S48, it is determined whether the start / end 56 of the read record is “start” or “end”. If the function (method) having the function name α does not call another function, the determination in step S48 is “end”, and the process proceeds to step S49.

  In step S49, the year / month / day / hour / minute / second of the record read at the end date / time 65 described later in the internal data related to the function of the function name α. Memories 51 are stored. Further, a time difference between the start date and time 64 and the end date and time 65 is obtained and stored in the elapsed time 66. As a result, all the internal data for display related to the function name α is recorded except for the execution time 67 among the data items 61 to 69 shown in FIG. The calculation / recording process of the execution time 67 will be described later.

In step S49, finally, the function name of the parent hierarchy of the current hierarchy (URL if there is no function name) is stored in the “start state”.
On the other hand, if the function (method) of the function name α has called another function, the read record is, for example, “β; start” next to the record of “α; start” in the example of FIG. Thus, since the called function is a record at the time of “start”, the determination in step S48 is “start”, and the process proceeds to step S50.

  In step S50, a layer of “layer α of function α + 1” (here, layer 4) is newly created and added to the end of the layer of function α. Then, the function name (execution method information 58) of the read record is stored as a new function name α in the “start state” (step S50).

Thereafter, when a record whose start / end 56 is “end” is read, the determination in step S48 is naturally “end”, and the processing in step S49 is executed.
For example, as shown in FIG. 11, at the end of the record group having the same session ID / request ID, a record recorded in the response process of the “request reception / response process” is stored. Therefore, although not particularly shown in FIG. 12, when the last record is read (determined by the absence of a function name or the like), the internal data of layer 2 created in step S45 is completed. . That is, at the end date and time 65 (to be described later) of the internal data of the hierarchy 2, the year, month, date, hour, minute, second, and second of the read record. The millisecond 51 is stored, and the elapsed time 66 is calculated and stored.

  The internal data 60 for display shown in FIG. 14 includes data items of a hierarchy 61, a URL 62, a function name 63, a start date and time 64, an end date and time 65, an elapsed time 66, an execution time 67, a session ID 68, and a request ID 69.

In the hierarchy 61, numerical values indicating the hierarchy such as the hierarchy 1, 2, 3, etc. are stored. As described above, the hierarchy indicates the depth of nesting of functions and the like.
The URL 62 and the function name 63 store the URL 57 and the execution method information 58, respectively. Similarly, a session ID 53 and a request ID 54 are stored in the session ID 68 and the request ID 69, respectively.

  The date / time information (year / month / day / hour / minute / second.millisecond 51) of the record whose start / end 56 is “start” is stored in the start date / time 64, and the date / time information (year / month) of the record whose start / end 56 is “end”. Date / time / minute / second / millisecond 51) is stored in the end date / time 65.

  The elapsed time 66 is the time difference between the start date and time 64 and the end date and time 65 (end date and time 65-start date and time 64) as described above. That is, the elapsed time 66 means, for example, the time from the start to the end of processing of each function. However, not limited to each function, for example, the internal data generated from the first and last records shown in FIG. 11 is the internal data related to the “request reception / response process”, and the elapsed time 66 in this case is It means the time from request reception to response.

  In this example, the request is an example of access to an arbitrary URL, and in this example, the elapsed time 66 related to the “request reception / response process” is from the beginning of the entire process related to an arbitrary URL (homepage) access. It means the time until the end. The “request reception / response processing” includes not only simple reception and response processing but also call processing of each function.

Such “request reception / response processing” is hereinafter referred to as “URL”.
Therefore, the elapsed time 66 related to the “request reception / response process” can be expressed as the elapsed time 66 related to “URL”. From this, the elapsed time 66 can be said to mean the time from the start to the end of the “URL” / function processing. As described above, “URL” calls a function. For example, in the example shown in FIG. 11, “URL” calls a function α. Similarly, in the example illustrated in FIG. 17, “URL” can be expressed as calling the function getDB () and the function setDB ().

  Here, the elapsed time 66 includes a time related to processing of another function called from “URL” / function (elapsed time of the other function). An execution time 67 is obtained by excluding the elapsed time of the other function from the elapsed time 66.

The display internal data 60 will be further described below with reference to specific examples shown in FIGS.
FIG. 15 is a specific example of the internal data 60 for display related to an arbitrary request, and FIG. 16 is a diagram showing an example of the performance data 50 that is the basis of the internal data 60 shown in FIG. FIG. 17 is a diagram illustrating an operation at the time of a request according to the example illustrated in FIG.

As shown in FIG. 15, in this example, it is assumed that there is access to URL = “http //: localhost: 8080 / DBAccess.jsp”, and session ID = “1234” and request ID = “1” are assigned. FIG. 15 shows internal data 60 for display generated from the performance data 50 of FIG. 16 collected in this case.

  In the example shown in FIG. 13 and the process of FIG. 12 corresponding to this example, the session ID is handled as one layer and the request ID is handled as one layer as described above, but this shows one way of thinking. There is no limitation to this example. In this method, basically, performance data 50 is collected for each request indicated by a combination of an arbitrary session ID and request ID. Therefore, the first record of performance data 50 for each request (that is, “ As shown in FIG. 15, the hierarchy 1 is given to the internal data 60 regarding the log output by “URL”.

  Whether it is the first record or not is temporarily stored, for example, the session ID and request ID of the record of the performance data 50 read last time, and this is compared with the session ID and request ID of the record read this time. If they do not match, the first record is determined. Of course, the present invention is not limited to this example.

  That is, each time a series of records having the same session ID and request ID as the first record including the first record are sequentially read, whether the record start / end 56 is “start” or “end”, If it is “start”, the hierarchy is incremented by one, and if it is “end”, the hierarchy is decremented by one. Here, the initial value of the hierarchy is “0”. In this example, since the first record is naturally “start”, “0 + 1” is given the hierarchy 1 as described above.

  After that, for example, if the subsequent record is “start” → “start” → “end” → “end” → “start” → “end” → “end”, the hierarchy is changed from 1 to 2 → 3 → 2 → 1 → 2 → 1. In this example, for example, the execution of the function α is started first (this is given the hierarchy 2), the function β is called from the function α (this is given the hierarchy 3), the function β is terminated, and the function This is the case, for example, when the function γ is executed after this α is finished (this is given the hierarchy 2).

  In the example shown in FIGS. 15 and 17, first, the first record is naturally “start”, and becomes the hierarchy 1 as described above, and the second and subsequent records are as shown in FIG. “Start” → “End” related to the function name getDB (), “Start” → “End” related to the function name setDB (), and finally “End” related to the layer 1. Therefore, as shown in FIGS. 15 and 17, the hierarchy 61 of the display internal data 60 relating to these function names getDB () and setDB () is both “2”.

  In this way, the performance data 50 is a separate record for each “start” and “end”, and the internal data 60 for display is combined into one for each “URL” and each function. The end date and time is recorded, and the hierarchy and elapsed time are obtained and stored. Although not shown in FIG. 14, the function name of the function of the caller (upper layer) may be further stored in the internal data 60.

  Here, although not particularly shown, the internal data creation processing of the data structure shown in FIG. 14 will be described below with reference to the examples shown in FIGS. In FIG. 16, the date / time information (year / month / day / hour / minute / second.millisecond 51) omits the year / month / day / hour and omits the minute / second. Only milliseconds are shown.

In this process, for example, every time one line of a record is read from the log file 41 (performance data 50), first, the session ID 53 and the request ID 69 that are the same as the session ID 53 and the request ID 54 of the read record are stored in the internal data 60. Check if data exists. Alternatively, in this check process, the session ID and request ID of the record read last time may be temporarily stored, and the determination may be made based on whether or not these match.

  If there is no data having the same session ID 68 and request ID 69 (assuming that the check result is NO), this record is the “URL” (particularly the first performance data collection program (Servlet filter)). 16) is a record (first record in a record group having the same session ID 68 and request ID 69) that is output when a request is received.

  If the read record is the first record (e.g., corresponding to the record a shown in FIG. 16), first, an initial value “1” is set to an arbitrary variable (here, referred to as “hierarchical variable”). .

  Subsequently, a new record is added to the internal data 60, and the value of the hierarchy variable (here, “1” as described above) is stored in the hierarchy 61 of this record. Further, the data of the corresponding data item in the record read from the log file 41 is copied to each data item of the new record of the internal data 60. That is, the URL 57, the execution method information 58, the session ID 53, and the request ID 54 are copied and stored in the URL 62, the function name 63, the session ID 68, and the request ID 69, respectively. Further, in this case, since the start / end 56 is “start”, the date / time information (year / month / day / hour / minute / second / millisecond 51) is copied and stored in the start date / time 64. In this case, since the execution method information 58 is blank, the function name 63 is blank as shown in the data of the hierarchy 1 in FIG.

  In this state, for example, in the example shown in FIG. 15, only the internal data of level 1 is created and this internal data is incomplete. That is, the end date / time 65, the elapsed time 66, and the execution time 67 are not yet recorded.

Then, the next record is read.
Since the records after the first record all have the same session ID 68 and request ID 69 until the record at the end of the series of processes, the check result is YES, and in that case The following processing is executed.

That is, first, referring to the start / end 56 of the read record, the processing is divided depending on whether it is “start” or “end”.
First, in the case of “start”, first, the “hierarchy variable” is incremented by +1. Then, in the same manner as in the case of the first record, a new record is added to the internal data 60, the current “hierarchy variable” value is stored in the hierarchy 61 of this record, and a new value of this internal data 60 is stored. The data of the corresponding data item in the read record is copied to each data item of the record. As described above, the data of each data item other than the end date and time 65, the elapsed time 66, and the execution time 67 is copied and recorded.

  In the example of FIG. 16, the record b is read after the record a, the hierarchy variable becomes “2”, and each data (end date and time 65, elapsed time 66, and (Excluding the execution time 67) is recorded.

  On the other hand, when the start / end 56 of the read record is “end”, a new record has already been added to the internal data 60 by the “start” record paired with this “end” record (however, , As described above, incomplete), and search for this “start” record to complete this record.

That is, for example, a record in which the value of the hierarchy 61 is the same as the current “hierarchy variable” value and the function name is searched for and obtained. Then, the date / time information (year / month / day / hour / minute / second / millisecond 51) of the read record is stored in the end time 65 of the obtained record, and the elapsed time 66 is calculated and stored. Further, if possible, the execution time 67 is also calculated and stored. A method for calculating the execution time 67 will be described later.

  In this way, each time an “end” record is read, an incomplete record in the internal data 60 is completed. In the example of FIG. 16, by reading the record c, the internal data regarding the function getDB () shown in FIG. 15 is completed.

  If the start / end 56 of the read record is “end”, the “hierarchy variable” is decremented by −1 at the end after the above processing. Then, the next record is read. In the process related to the record c, the hierarchy variable = “1” is finally set.

  In the example shown in FIG. 16, records d and e are further read after that, and as shown in FIG. 15, a new record (hierarchy = '2') of internal data relating to the function setDB () is created and completed. Become.

Finally, the record f is read, and the record of the hierarchy 1 is completed.
Here, the calculation process of the execution time 67 will be described.

  In the example shown in FIG. 17, for example, the elapsed time 66 of the record of level 1 includes the elapsed time 66 of two functions (getDB () and setDB ()) called from this level 1 (“URL” above). From the elapsed time 66, the time taken for processing of the hierarchy 1 (“URL”) itself is not known. This also applies to each function. In FIG. 17, the two functions (getDB () and setDB ()) do not call other functions. For example, in the example shown in FIG. The function A called from the function B calls the function B, and the function B called from the “URL” thereafter calls the function C.

  A thick vertical line in FIG. 18A indicates the “URL” and the elapsed time 66 of each function A, B, C. As shown in the figure, for example, the elapsed time of the function A includes the elapsed time of the function B called from the function A, and the time required to execute the processing of the function A itself is not known from the elapsed time. Therefore, in the case of this example, a time obtained by subtracting the elapsed time of the function B from the elapsed time of the function A is obtained and set as the execution time 67. If no other function is called, elapsed time 66 = execution time 67.

  When the execution time 67 is obtained in this way, in the case of FIG. 18A, the “URL” and the execution time 67 of each function are shown by thick vertical lines in FIG. 18B. For example, the execution time 67 of the function A is “a1 + a2” shown in the figure. The execution time 67 of the function B called from the function A is the same as the elapsed time 66. Further, the execution time of the function B called after “URL” is “b1 + b2” shown in the figure.

  In the example illustrated in FIG. 17, the execution time 67 of the hierarchy 1 (“URL”) is a value obtained by subtracting the elapsed time of getDB () and the elapsed time of setDB () from the illustrated elapsed time. In other words, whether it is a “URL” or a function, a value obtained by subtracting the total elapsed time of each function directly called from the own elapsed time is obtained as the execution time of the “URL” or function. It is done.

Here, the directly called function is not shown in FIG. 14 as described above, but if the function name of the calling function is also stored in the table 60, it can be understood by referring to this. Even if this is not the case, the calling relationship can be understood by comparing the hierarchy and the time zone from the start date and time 64 to the end date and time 65 (hereinafter referred to as the elapsed time zone).

  That is, when the execution time 67 of an arbitrary target record is obtained, the hierarchy immediately below the target record hierarchy (hierarchy of target record + 1; for example, “3” if the target record hierarchy is “2”) Are extracted, and it is determined whether or not the elapsed time zone of each extracted record is included in the elapsed time zone of the target record. Then, the execution time 67 of the target record is obtained by subtracting the sum of the elapsed time 66 of all the corresponding records from the elapsed time 66 of the target record.

  For example, in the example shown in FIG. 15, when a record of the illustrated hierarchy 1 (“URL”) is a target record, the elapsed time zone of this target record is “40: 00.848 to 40: 30.848” if the year, month, and date are omitted. It becomes. Further, since the hierarchy of the target record is “1”, when a record whose hierarchy is “2” is extracted, two records of the function names getDB () and setDB () shown in the figure are extracted.

  As shown in the figure, the elapsed time zones of each extracted record are “40: 10.848 to 40: 15.848” and “40: 20.848 to 40: 25.848”, both of which are the elapsed time zones of the target record “40: 00.848”. -40 to 40.848 ", both are the above records.

And the elapsed time of the target record is 30000 (milliseconds), and the elapsed time of each corresponding record is 5000 (milliseconds) and 5000 (milliseconds),
Execution time 67 of target record = 30000-(5000 + 5000) = 20000 (milliseconds)
It becomes.

  Although already described, the “URL” in the description of FIGS. 15 and 17 and the “URL” shown in FIGS. 18A and 18B are mainly the first performance data collection program (Servlet Filter) 16 and processing executed by the JSP / Servlet 11. In other words, it means a process other than the process executed by each function among the processes related to access to an arbitrary URL. For example, the elapsed time of URL processing (layer 1 processing) shown in FIG. 17 means the time from reception of an access request to response to URL = “http / :: localhost: 8080 / DBAccess.jsp”.

  Furthermore, OS / middleware performance data (various data indicating resource status) is also collected when collecting the performance data of the application program described above. Collection of various data indicating the resource status of the OS / middleware can be realized by an existing function such as a performance monitor of Windows (registered trademark), for example, as described above.

  Then, by plotting and displaying the internal data for display 60 generated by the above-described processing and the OS / middleware resource status on the same time axis, for example, a display as shown in FIG. Done. Regarding the internal data 60 for display, in the illustrated example, a bar indicating the time (processing time) required for processing for each session request is displayed (for example, at the elapsed time 66 of the hierarchy 1 (“URL”)). Display based on). In the figure, each session is shown, but actually, it is displayed for each combination of an arbitrary session ID and request ID.

  The computer apparatus that performs the display process and the internal data generation process described above may be the Web / Ap server 10 or any other information processing apparatus. In any case, the apparatus / system as a whole that collects performance data such as the functions described above, collects various data indicating the OS / middleware resource status, generates internal data for display, and displays based on the internal data. It shall be called a performance data collection / display system.

  Alternatively, based on the data collected and stored on the assumption that the performance data collection of each function described above and various data indicating the OS / middleware resource status have already been collected and stored. An apparatus that generates internal data for display and performs display based on the internal data is referred to as a performance data display apparatus.

  Further, if only the display as shown in FIG. 19A is performed, it is possible to display only with the data of the elapsed time 66 of the hierarchy 1 as described above. For example, all the internal data of session ID = '1234' and request ID = '1' shown in FIG. 15 is acquired and displayed.

  Therefore, although not shown in FIG. 19A, as shown in the enlarged display of FIG. 19B, for example, the bar indicating the processing time for each session request indicates the execution time for each URL / function. It is generated as a combination of processing time bars (for example, different colors are displayed for each function and displayed so as to be distinguished). That is, for example, what is shown in FIG. 18 (b) is shown in a single bar shape as shown in FIG. 19 (b). This is substantially the same as that shown in (b). Although not shown in FIG. 19B, the function name of each function may be displayed in the bar.

As shown in FIGS. 19A and 19B, a graph or the like based on various data indicating the resource status of the OS / middleware is also displayed superimposed on the bar display.
In the display screen shown in FIG. 19A, disk I / O (load amount to the disk) is displayed as an example of the resource status of the OS / middleware (displayed as a line graph in the figure). . By visually confirming this, for example, the time zone in which the load on the disk is increasing can be seen, and further the session executed during this time zone can be seen (mainly session 3 in the figure), For example, by selecting a rectangle as shown in the figure (not limited to this example, for example, by directly specifying the corresponding session), the performance data of the corresponding session is enlarged and displayed as shown in FIG.

  As described above, in the enlarged display shown in FIG. 19B, the execution time of each function executed in connection with the session 3 is displayed. Therefore, the operator or the like may refer to this display, or may be other normal. Functions that have poor performance (compared to others) (such as functions that have a long execution time; disk load) It is possible to easily grasp the functions that are affecting the increase).

  The display shown in FIG. 19A is displayed when an operator or the like designates an arbitrary time zone (corresponding to the entire time on the horizontal axis in the figure), but is not limited to this example. For example, when the operator designates an arbitrary URL, all the data having the same URL 62 as the designated URL out of the performance data 60 may be extracted and displayed. In this case, there is a problem specific to the client (browser), for example, it is possible to specify a session whose processing time is extremely longer than that of other sessions despite access to the same URL. In some cases, identification becomes easy.

  Not limited to the above example, for example, by specifying a specific function name and extracting corresponding data and displaying the execution time (in this case, the session ID and the like are also displayed for each data) Various search conditions can be input, and display according to the search conditions can be performed.

20A and 20B show other display examples. These display examples are basically shown in FIG.
20A is a display substantially similar to FIG. 20, FIG. 20A is a display screen of application performance data and OS / middleware resource status in an arbitrarily designated time zone, and FIG. 20B is a display screen of FIG. ) Is an enlarged display screen of a portion (rectangular region indicated by a dotted line in the figure) arbitrarily designated by an operator or the like.

  The difference between FIG. 20A and FIG. 19A is that the OS / middleware resource status is displayed in two types: the amount of load on the disk and the CPU usage rate (in the figure, each is a line graph). It is a point). In this way, a plurality of types of resource statuses can be displayed, and the correspondence between application performance data and resource statuses can be more accurately performed. The above display can be displayed by designating any one or a plurality of types by an operator or the like from various data indicating the OS / middleware resource status, for example.

  Further, in FIG. 20 (a), since processing for each session request is executed in a shorter time than in FIG. 19 (a), the bar display for each session is displayed densely. As shown in FIG. 20 (a), the bar for each session is displayed on the screen indistinguishable. In other words, a band-like line from the upper left to the lower right of the screen, which is substantially centered at the position of time t on the screen (position indicated by a vertical dotted line), is a display in which the display of bars for each session is dense. It has become. In this way, there are cases where the images are displayed as densely as if they were one line. It should be noted that both the bar display and the line graph display may be regarded as a kind of graph display.

  Even in such a display, referring to the display of the resource status of the OS / middleware, a specific time zone that is likely to have a problem is designated as the rectangle, and the display is enlarged as shown in FIG. Since it is displayed, the operator or the like knows the processing time of each session and the processing time of each function related to each session, and can easily grasp the problematic session or function. FIG. 20B differs from FIG. 19B in that a plurality of sessions are displayed, but it is also possible for an operator or the like to further select and display a specific session from among these.

  The method for selecting and specifying the specific area (specific time zone) is not limited to the rectangular method, and may be various known methods. For example, it may be linked with mouse wheel operation, numerical value designation, or the like. In addition, the resource status of the OS / middleware is not limited to the Web server on which the application program is executed, but may be that of a server (such as a database server) connected to the Web server and on the same system. .

  Further, based on the performance data collection / analysis result of the application program (the internal data 60 for display, etc.), it is also possible to calculate the average / fastest / latest processing time, the number of method calls, etc. The calculation results can be output in a tabular format using, for example, commercially available spreadsheet software.

  FIG. 21 is a hardware configuration diagram of a computer such as the Web / Ap server 10. The computer is not limited to the Web / Ap server 10 and may be another information processing apparatus constituting the performance data collection / display system.

  21 includes a CPU 71, a memory 72, an input unit 73, an output unit 74, a storage unit 75, a recording medium drive unit 76, and a network connection unit 77, which are connected to a bus 78. It has become.

The CPU 71 is a central processing unit that controls the entire computer 70. Further, for example, the main storage device 30 may be incorporated in the CPU 71.
The memory 72 is a memory such as a RAM that temporarily stores a program or data stored in the storage unit 75 (or the portable recording medium 79) during program execution, data update, or the like. The CPU 71 executes various processes using the program / data read out to the memory 72.

The output unit 74 is, for example, a display, and displays a display screen of internal data and the like shown in FIGS.
The input unit 73 is, for example, a keyboard, a mouse, and the like, and the user operates these to perform a desired input operation (designation of the rectangular area, etc.) on the screen shown in FIGS.

  The network connection unit 77 is configured to connect to a network (not shown) and perform communication (command / data transmission / reception, etc.) with another information processing apparatus (client 100 or the like), for example.

  The storage unit 75 is, for example, a hard disk or the like, and stores, for example, first and second performance data collection programs 16 and 17 and application programs (JSP / Servlet11, Java class 12, etc.). In addition, various functions and processes (especially the processes shown in FIGS. 6, 7, 10, and 12) of the Web / Ap server 10 of the present example, such as programs for realizing the OS 15 and the Java VM 14. The program is stored.

  The CPU 71 implements various functions and processes as the performance data collection / display system described above by reading and executing various programs stored in the storage unit 75.

  The storage unit 75 may correspond to the auxiliary storage device 40. In this case, the log file 41 is also stored. The storage unit 75 may also store internal data 60 for display. That is, the storage unit 75 may store data shown in FIGS. 8, 11, 13, 14, 15, 16, and the like.

  Alternatively, the various programs / data stored in the storage unit 75 may be stored in the portable recording medium 79. In this case, the program / data stored in the portable recording medium 79 is read by the recording medium driving unit 76. The portable recording medium 79 is, for example, an FD (flexible disk) 79a, a CD-ROM 79b, a DVD, a magneto-optical disk, or the like.

  Alternatively, the program / data may be downloaded from another device via a network connected by the network connection unit 77. Or you may download further what was memorize | stored in the other external apparatus via the internet.

  In addition, the present invention can be configured not only as a portable storage medium recording a program for realizing the various processes of the present invention on a computer, but also as the program itself.

As described above, in this method, the processing time and processing execution date and time at the function level for each session request of the application program are automatically totaled, and the totaled result is displayed on the same graph as the OS / middleware resource status. The processing time for each session request of the application program, the processing time for each function, and the OS / middleware resource status can be grasped.
As a result, as described above, not only can the function affecting the processing performance deterioration of the OS / middleware be identified, but also the session request related to this function execution can be grasped, and there is a problem specific to the client or request. Identification becomes easy. That is, an efficient and accurate performance bottleneck analysis can be performed.

  In addition, the processing for collecting performance data at each function level for each session request of the application program can be easily added by aspect compilation as described above, so that it does not take time and effort for the user. Become.

Note that this technique is particularly useful in the following systems and situations.
(A) Data collection and display after collecting performance data in performance tests to confirm the required performance achievement level and improve performance of newly developed business system users.

(A) Data collection and display after performance data collection when application program performance confirmation / improvement is performed after the start of operation due to addition of functions or increase in users.
(C) Other general systems that require application program performance data aggregation and display.

1 is a system configuration diagram of a system including a client and a server in this example. It is a figure for demonstrating production | generation processes, such as a 2nd performance data collection program. It is a figure which matches and shows FIG. 2 and FIG. (A), (b) is an example of an application (Java class) of an aspect compilation result. It is a figure which shows operation | movement of the whole system of this example. It is a process flowchart figure of a 1st performance data collection program. It is a process flowchart figure of a 2nd performance data collection program. It is a figure which shows an example of the storage data format of a log file. It is a figure which shows roughly operation | movement of the Web / Ap server of a present Example. FIG. 10 is a schematic flowchart corresponding to FIG. 9. It is a figure which shows an example of the log data written in the log file. It is a flowchart figure which shows an example of the conversion process according to the example of FIG. FIG. 3 is a diagram (part 1) illustrating an example of an internal data structure. FIG. 10 is a diagram (part 2) illustrating an example of an internal data structure. It is a specific example of internal data in the data structure shown in FIG. It is a figure which shows an example of the performance data used as the origin of the internal data shown in FIG. It is a figure which shows the operation | movement at the time of the request according to the example shown in FIG. (A) is a URL / elapsed time of each function, and (b) is a diagram showing its execution time. (A) is an example of a display screen based on internal data (part 1), and (b) is an enlarged screen example of a part of the screen shown in (a). (A) is a display screen example (part 2) based on internal data and the like (b) is an enlarged screen example of a part of the screen shown in (a). It is a computer hardware block diagram. It is a figure which shows the conventional system configuration | structure and a performance data collection system. (A), (b) is a display example of conventional performance data or the like.

Explanation of symbols

10 Web / Ap Server 11 JSP / Servlet
12 Java class 13 Servlet container 14 JavaVM (Java virtual machine)
15 OS
16 First performance data collection program 17 Second performance data collection program 20 Aspect compiler 21 Aspect source file 22 Application program 23 Aspect program (.class file)
24 Application program (.class file)
30 Main storage device 31 Thread-specific variable area 40 Auxiliary storage device 41 Log file 50 Log file table (performance data)
51 year, month, day, hour, minute, second. Millisecond 52 Log level 53 Session ID
54 Request ID
55 Thread name 56 Start / End 57 URL
58 Execution method information 60 Internal data for display 61 Hierarchy 62 URL
63 Function name 64 Start date and time 65 End date and time 66 Elapsed time 67 Execution time 68 Session ID
69 Request ID
70 Computer 71 CPU
72 Memory 73 Input unit 74 Output unit 75 Storage unit 76 Recording medium drive unit 77 Network connection unit 78 Bus 79 Portable recording medium 79a FD (flexible disk)
79b CD-ROM
100 Client 101 Client program (browser, etc.)
102 OS

Claims (6)

Each time an arbitrary request is received from an arbitrary client, the session ID and request ID corresponding to the request are stored in a predetermined storage area, and predetermined log information is recorded in association with the session ID and the request ID. First performance data collection means;
Application execution means for executing processing of one or more predetermined functions in response to the request;
When executing the process of each function by the application execution unit, the session ID and the request ID are acquired from the predetermined storage area, and the predetermined process related to the process execution of each function is associated with the session ID and the request ID. Second performance data collecting means for additionally recording the performance data of the
Resource status data collecting means for collecting data indicating the resource status of the OS / middleware;
Based on the recorded log information, the start date / time, end date / time, and processing time of the entire process corresponding to each arbitrary request are obtained, or the processing start date / time and end date / time of the function for each function, An internal data generating / storing means for obtaining an execution time which is a time taken to execute the processing of the function, and generating / storing internal data in which the obtained information is associated with the session ID and the request ID;
On the basis of the internal data, and visualization display indicating any said execution time of each function in the overall processing time and the processing overall process for each request in a bar or graph, and visualization display based on the resource status data Display means for displaying on the same time axis ,
A performance data collection / display system characterized by comprising:   The program for realizing the second performance data collection means and the application execution means is an aspect source file in which predetermined log output processing and arbitrary log output targets / log output locations are described, and processing of the function. 2. The performance data collection / display system according to claim 1, wherein the performance data collection / display system is generated by aspect-compiling the application program.   3. The performance data collection / display system according to claim 1, wherein the predetermined performance data related to the execution of each function is a function name of each function, a process start / end date and time, and a connection destination URL. . In association with a session ID and a request ID generated every time an arbitrary request from an arbitrary client is received, performance data related to the entire process corresponding to the request, or processing execution of each function in the entire process Performance data storage means in which such performance data is stored as log information;
Resource status data storage means for storing at least various data indicating the resource status of the OS / middleware at the time of execution of processing according to the request;
Based on the recorded log information, the start date / time, end date / time, and processing time of the entire process corresponding to each arbitrary request are obtained, or the processing start date / time and end date / time of the function for each function, An internal data generating / storing means for obtaining an execution time which is a time taken to execute the processing of the function, and generating / storing internal data in which the obtained information is associated with the session ID and the request ID;
On the basis of the internal data, and visualization display indicating any said execution time of each function in the overall processing time and the processing overall process for each request in a bar or graph, and visualization display based on the resource status data Display means for displaying on the same time axis ,
A performance data display device comprising: Computer
Each time an arbitrary request is received from an arbitrary client, the session ID and request ID corresponding to the request are stored in a predetermined storage area, and predetermined log information is recorded in association with the session ID and the request ID. First performance data collection means;
Application execution means for executing processing of one or more predetermined functions in response to the request;
When executing the process of each function by the application execution unit, the session ID and the request ID are acquired from the predetermined storage area, and the predetermined process related to the process execution of each function is associated with the session ID and the request ID. Second performance data collecting means for additionally recording the performance data of the
Resource status data collecting means for collecting data indicating the resource status of the OS / middleware;
Based on the recorded log information, the start date / time, end date / time, and processing time of the entire process corresponding to each arbitrary request are obtained, or the processing start date / time and end date / time of the function for each function, An internal data generating / storing means for obtaining an execution time which is a time taken to execute the processing of the function, and generating / storing internal data in which the obtained information is associated with the session ID and the request ID;
On the basis of the internal data, and visualization display indicating any said execution time of each function in the overall processing time and the processing overall process for each request in a bar or graph, and visualization display based on the resource status data Display means for displaying on the same time axis ,
Program to function as. Computer
In association with a session ID and a request ID generated every time an arbitrary request from an arbitrary client is received, performance data related to the entire process corresponding to the request, or processing execution of each function in the entire process Performance data storage means in which such performance data is stored as log information;
Resource status data storage means for storing at least various data indicating the resource status of the OS / middleware at the time of execution of processing according to the request;
Based on the recorded log information, the start date / time, end date / time, and processing time of the entire process corresponding to each arbitrary request are obtained, or the processing start date / time and end date / time of the function for each function, An internal data generating / storing means for obtaining an execution time which is a time taken to execute the processing of the function, and generating / storing internal data in which the obtained information is associated with the session ID and the request ID;
On the basis of the internal data, and visualization display indicating any said execution time of each function in the overall processing time and the processing overall process for each request in a bar or graph, and visualization display based on the resource status data Display means for displaying on the same time axis ,
Program to function as.