JP3945521B2 - Distributed processing system and performance monitoring method thereof - Google Patents

Description

  The present invention relates to a distributed processing system in which a plurality of objects are distributed and arranged on a plurality of computers, and more particularly to a performance monitoring method thereof.

For example, a computer system as disclosed in Japanese Patent Application Laid-Open No. 7-295864 is an apparatus for measuring the operation status of a plurality of processes related to a case where a plurality of processes cooperate to perform one process on one computer. There is a device that measures the operational status of each as time-series data for each process.
As an example of commercializing this, “Nikkei Byte Special Special Issue” 1998.11-8, No. 184 pp192-193 Visual Quantifier of Rational Software, a profiler that analyzes performance bottlenecks of applications executed on one computer at the module level, function level, and source level (Visual Quantify) is known.

  On the other hand, in a distributed processing system composed of a plurality of computers, when a plurality of processes perform one process in cooperation with each other, as a method for measuring performance without being aware of remote procedure call, for example, Japanese Patent Laid-Open No. 5-274185 As disclosed in the official gazette, there is an example in which a mechanism for associating processes is realized by having a remote procedure call issuance detection unit, a remote procedure call end detection unit, and a central performance measurement control unit. In this method, all the remote procedures are notified to the central performance measurement control device, thereby associating the calling side with the called side.

Japanese Unexamined Patent Publication No. 7-295864 Japanese Unexamined Patent Publication No. 5-274185 Nikkei Byte Special Special Issue 1998.11-8, No. 184 pp192-193

  In the future, the distribution of processing across multiple computers will progress, and there will be a distributed object that has a plurality of computers, a program that is distributed and executed on these multiple computers, and a communication function between these objects. The system is expected to become widespread.

  By using the technique disclosed in Japanese Patent Laid-Open No. 7-295864, it is possible to detect a bottleneck of the performance in one computer. However, simply applying this to each computer of the distributed object system makes it difficult to detect the performance bottleneck of the distributed object system because there is no correspondence between the performance data collected in each computer.

  Further, by using the technique disclosed in Japanese Patent Application Laid-Open No. 5-274185, it is possible to associate the transmission object and the reception object for each inter-object communication in the distributed object system. However, if one process is completed after passing through the processing of multiple objects via inter-object communication, there is no means to correlate related inter-object communication. Have difficulty.

  As described above, in the conventional technique, performance data of points can be collected like each computer and each object, but there is a problem that performance monitoring for the entire distributed object system cannot be performed.

  The present invention has been made in view of the above circumstances, and an object thereof is to provide a method for performing performance monitoring for the entire distributed processing system and such a distributed processing system. .

  Moreover, it aims at providing the performance monitoring method of the distributed processing system which can narrow down the bottleneck of performance.

  The present invention collects, as performance data, at least one of a message reception time from another program entity and a message transmission time to another program entity for a program entity to be measured by a monitoring means arranged on each computer A performance monitoring method for a distributed processing system that aggregates the performance data collected by each monitoring means and calculates the processing time of each program entity constituting the processing flow and the communication time between the program entities and displays them on the display device It is characterized by.

  In the present invention, (a) the processing time of each object constituting the processing flow is measured, and (b) when the processing time measured in (a) exceeds a predetermined processing time threshold of the object. Measure the waiting time until each object obtains a result after issuing a request to another object for the object group executed on the computer where the object is arranged, and the waiting time measured in (c) and (b) Is characterized by a performance monitoring method for a distributed object system that executes (a) for a processing flow starting from the processing of the object when the threshold of the object exceeds a predetermined waiting time threshold.

  According to the present invention, the processing time of each object and the communication time between objects can be acquired for a processing flow in which one process is completed after passing through the processing of a plurality of objects via inter-object communication. Performance monitoring for the entire system can be performed. In addition, since the performance monitoring for the processing flow and the performance monitoring for a specific computer can be dynamically switched, there is an effect of facilitating the analysis of the performance bottleneck.

  Embodiments of the present invention will be described below in detail with reference to the drawings.

(1) 1st Embodiment FIG. 1: is a block diagram of the computer system which implement | achieves the performance monitoring method of this embodiment. The computer system includes a computer 103 that executes a manager 130 that is a program for processing and displaying collected performance data, computers 101 and 102 that have objects to be performance monitored, and a LAN 140 that connects the computers. Consists of. In this example, there are two computers to be monitored, but the number is not limited. The computers can communicate with each other via the LAN 140, but the means for realizing the communication is not limited to the LAN. The collectors 131 and 132 are programs that receive instructions from the manager 130 and collect performance data and transfer the collected data to the manager as necessary. Reference numerals 121 to 126 are objects that are actual program entities to be monitored. The manager distinguishes this by using a unique ID called an object ID for each object. As the object ID, for example, an object reference used in CORBA, which is one of the standards of distributed object technology, is used. For CORBA technology, “" The Common Object Request Broker: A
For details, refer to "structure and specification" OMG Document Revision 2.2, February 1998.

  Although not shown, a display device and an input device are connected to each computer 101, 102, 103. In particular, the display device of the computer 103 displays a list of object IDs, a processing time of each object, a communication time between objects, and the like for a series of processing from the object to the object. The input device of the computer 103 is used for data input and command input such as designating an object to be monitored.

  In FIG. 1, the manager 130 is arranged on the computer 103 independent of the computers 101 and 102, but the present invention can be implemented even if the manager 130 is arranged in the same computer 101 as the collector 131, for example, the computer 101. it can. If the manager 130 is arranged on the independent computer 103, it is possible to remove the influence on the performance that the manager 130 has on the performance monitoring.

  In addition, it is possible to create a storage medium that stores the manager 130 and the collectors 131 and 132 as programs. The program on the storage medium is read from a drive unit connected to the computers 101, 102, 103, or is transmitted from another computer to the computers 101, 102, 103 via the network, and is arranged in each computer. The collector 131, 132 or manager 130, which is a program part, can be loaded into the memory of the computer and executed by the computer.

  FIG. 2 is a diagram illustrating a schematic procedure of processing of the entire system according to the first embodiment. This processing procedure consists of two blocks: a block 201 which is a part in charge of the manager 130 and a block 202 which is a part in charge of the collectors 131 and 132.

First, the block 201 executed by the manager 130 will be described. The manager 130 first displays a list of objects in step 210 and accepts an input for selecting an object for collecting performance data. Next, in step 220, the object ID of the object from which the performance data input in step 210 is collected is notified to all the collectors 131 and 132 by broadcast. In step 230, the manager 130 waits for the arrival of performance data transferred from the collectors 131 and 132. When the performance data is received, in step 240, the piecewise performance data transmitted from each collector is associated. Here, the association means that performance data belonging to the same processing sequence is grouped and arranged according to a time series. The associated performance data is displayed in step 250. After the display, the end condition is determined in step 255. In this embodiment, an arbitrary operation time is set in advance, and it is checked in step 255 whether the set time is exceeded. If it exceeds, the process ends. If not, the process returns to Step 230. As described above, the processing in steps 230, 240, and 250 is repeatedly performed for a predetermined time after the manager 130 first receives performance data from the collectors 131 and 132.

  Next, the block 202 executed by the collectors 131 and 132 will be described. In step 270, the collectors 131 and 132 receive data consisting of at least one object ID broadcast by the manager 130. If there is an object having the same object ID as the received object ID in the computers 101 and 102 in which the collector is running, the collectors 131 and 132 start monitoring the object. Hereinafter, this object is referred to as a measurement target object. When processing occurs in the measurement target object in step 280, the collectors 131 and 132 collect performance-related data, and transmit the collected data to the manager in step 290. After the performance data is transmitted, the end condition is determined in step 295. In the present embodiment, the same operation time as the operation time in step 255 is set in advance, and it is checked whether the time set in step 295 has been exceeded. If it exceeds, the process ends. If not, the process returns to Step 280. As described above, the processes in steps 280 and 290 are repeatedly performed for a predetermined time after the collectors 131 and 132 receive the object ID data from the manager 130.

  FIG. 3 is a diagram illustrating an example of the measurement target object selection screen 301 displayed on the display device of the computer 103. A plurality of object IDs are displayed on the object list window 302 as candidate candidates for acquiring performance data, and one or more objects to be measured can be selected from them. When a plurality of objects are selected at the same time, the plurality of selected objects is a group of objects that are usually associated by inter-object communication. The measurement start button 303 is a button for instructing the manager 130 to start measurement after the measurement target object is selected. When the measurement start button 303 is pressed, the manager 130 broadcasts the selected object ID to the collectors 131 and 132 in step 220.

  In this example, the object list window 302 displays object IDs 20001, 20002, 20003, 20004, 20005, and 20006 of objects to be measured by the collectors 131 and 132, of which 20001, 20004 and 20005 are selected. It shows that.

  FIG. 4 is a diagram showing the data structure of the collection data list 501 created by the collectors 131 and 132 on the memories of the computers 101 and 102, respectively. The collection data list 501 includes fields of an object ID 502, a reception object ID 503, a reception message ID 504, a reception time 505, a transmission object ID 506, a transmission message ID 507, and a transmission time 508. One collection data list 501 is generated each time the measurement target object receives a message from another object, transmits a message to another object, or transmits a message following message reception. An object ID 502 is an ID of a measurement target object. The receiving object ID 503 is the ID of the partner object when the measurement target object receives a message. The receiving side message ID 504 stores a message ID added to the received message. The reception time 505 stores the message reception time. The transmission side object ID 506 is an ID of the partner object when the measurement target object transmits a message. The transmission side message ID 507 is a message ID added to the transmission message. The transmission time 508 stores the message transmission time. For the object ID 502 that starts processing when an event such as data input from the user occurs, the receiving object ID 503 and the receiving message ID 504 are not stored, and the processing start time is stored at the receiving time 505. In addition, for the object ID 502 that terminates the processing with the measurement target object instead of transmitting a message to another object, the transmission end object ID 506 and the transmission side message ID 507 are not stored, and the processing end time is stored at the transmission time 508. . Here, as the message ID, for example, a message ID used internally in CORBA, which is one of the standards of the distributed object technology, can be used.

  The measurement target object notifies the collector of the measurement target object ID and processing start time to the collector provided in the computer when an event such as data input occurs and processing is started. The measurement target object notifies the collector of the ID of the measurement target object, the ID of the counterpart object, the message ID to be transmitted, and the message transmission time at the time of transmitting a message to another object. When a message is received from another object, the collector is notified of the ID of the object to be measured, the ID of the partner object, the received message ID, the message reception time, and a flag indicating whether or not message transmission will continue to occur. . Further, the ID of the measurement target object and the processing end time are notified to the collector when the series of processing ends. After receiving the measurement target object notification from the manager 130, the collector sends a command to the measurement target object to start notification of the object time and the like.

  FIG. 5 is a flowchart showing a processing flow of the collectors 131 and 132 for collecting performance data. When the collectors 131 and 132 receive a notification from the measurement target object, the collectors 131 and 132 secure the area of the collection data list 501 on the memory (step 420), and the measurement target object notified to the object ID 502 of the secured collection data list 501 area. The other object fields are initialized with -1 (step 430). Next, the type of communication that has occurred is checked (step 440). When a processing start notification and a message transmission notification are received from the measurement target object (step 440 transmission), the processing start time is stored in the reception time 505 of the collection data list 501 and the collection data list 501 is based on the information of the message transmission notification. The transmission side object ID 506, the transmission side message ID 507, and the transmission time 508 are stored (step 445), and the collection data list 501 is completed.

  When a message reception notification is received from the measurement target object (step 440 reception), the reception side object ID 503, reception side message ID 504, and reception time 505 of the collection data list 501 are stored based on the message reception notification information (step 450). . Next, it is determined whether or not transmission continues with the flag received from the measurement target object (step 455). If the transmission continues (Yes in step 455), it waits for a message transmission notification from the same object to be measured. When a message transmission notification is received, the transmission side object ID 506, the transmission side message ID 507, and the transmission time 508 in the collection data list 501 are received. (Step 460), and the collection data list 501 is completed. If transmission does not continue (No in step 455), the process end notification from the same measurement target object is waited, and when the process end notification is received, the process end time is stored in the transmission time 508 of the collection data list 501 (step 465). ), The collection data list 501 is completed.

  If the processing time from the processing start time to the message transmission time or the processing time from the message reception time to the processing end time can be ignored for performance monitoring for the same object, the collection of the processing start time or the processing end time is omitted. May be. When ignoring the processing end time, there is no processing in step 465.

  FIG. 6 is a diagram showing a data configuration of the request flow table 701 created by the manager 130 on the memory of the computer 103. The request flow table 701 is obtained by sorting the collection data list 501 that has arrived at the manager 130 with respect to the group of measurement target objects associated through communication so that they are arranged in time series according to the order in which the processing is performed. Each row of the request flow table 701 is the collection data list 501 itself, and the contents of each field of the object ID 702, the reception side object ID 703, the reception side message ID 704, the reception time 705, the transmission side object ID 706, the transmission side message ID 707 and the transmission time 708. Are the same as the object ID 502, the reception object ID 503, the reception message ID 504, the reception time 505, the transmission object ID 506, the transmission message ID 507, and the transmission time 508, respectively. The difference between the transmission time 708 and the reception time 705 for each row of the request flow table 701 is the processing time of the measurement target object (elapsed processing time including waiting time in the same computer). Further, the object ID stored in the sending object ID 706 of a certain line is the object ID 702 of the next line, the object ID 702 of the line having the object ID stored in the receiving object ID 703 of the next line, When the message ID matches the message ID of the receiving side, it indicates that communication has been performed between both measurement target objects in the processing flow for the same transaction, and the transmission time 708 of one line and the next line The difference from the reception time 705 is the communication time between both objects. The request flow table 701 is created for each series of processing flows.

  FIG. 7 is a diagram illustrating an example of a measurement result display screen 810 displayed on the display device of the computer 103. The measurement result display screen 810 displays a processing flow 820 that schematically illustrates the request flow table 701. In the processing flow 820, the object IDs 801 of the processed objects are arranged in time series according to the order in which the processing is performed, and the object ID 801 is connected by a line segment 804 before and after. The processing flow 820 includes an object ID 801, a set of 802 indicating the processing time thereof, a set of 803 indicating a communication time between objects, and a line segment 804 connecting the objects. Each object ID 801 corresponds to each object ID 702 in the request flow table 701.

FIG. 8 is a flowchart showing a processing flow of the manager 130 that creates and displays the request flow table 701. The manager 130 waits for the collection data list 501 to arrive from the collectors 131 and 132 (step 610).
When the collection data list 501 arrives (step 610 Yes), the receiving side object ID 503 is checked to determine whether or not this ID matches any of the IDs of the selected measurement target objects (step 620). If they do not match (No in step 620), a new area of the request flow table 701 is secured on the memory of the computer 103, and the arrived collection data list 501 is set as the head element (step 635). The unfinished request flow table 701 will be referred to as a request flow table being created. A plurality of in-creation request flow tables can be created while the processing shown in FIG. 8 is being performed.

If they match (Yes in step 620), the request flow table being created is searched, and the transmission side message ID of the collection data list constituting the tail of the table and the received message ID of the collection data list just acquired are It is checked whether there is a matching table (step 645). If there is a match as a result of the check (step 645 Yes), the acquired data list just acquired is added to the end of the request flow table being created (step 647). If there is no match (No in step 645), the collection data list is stored in the collection data list buffer, which is a temporary storage area on the memory (step 649), and the process returns to step 610 to wait for the arrival of a new collection data list. .

In step 650 following step 635 and step 647, the transmission side object ID 706 of the collection data list added to the end of the request flow table being created is checked (step 650). If this is not the ID of the selected measurement target object (No in step 650), this request flow table is completed, so this request flow table is displayed (
Step 652). After the display, it is checked whether or not a preset time has been exceeded (step 654). If not exceeded (Yes in step 654), the process returns to step 610 to wait for the arrival of a new collection data list. If it exceeds (No in Step 654), the process of the manager 130 is terminated.

  If the result of the check in step 650 is that the sending object is the ID of the selected measurement target object (Yes in step 650), a collected data list having the same receiving message ID as the sending message ID 707 is collected. (Step 655). If the collection data list is found (Yes in step 655), the collection data list is added to the tail of the request flow table being created in step 635 or 647, and then the process returns to step 650. If there is no collection data list (no step 655), the process returns to step 610 to wait for the arrival of a new collection data list.

  According to the processing procedure of the manager 130 shown in FIG. 8, the collection data list 501 belonging to a plurality of transactions is mixed and arrives at the manager 130, or the processing sequence of each object is different from the arrival sequence of the collection data list 501. However, a request flow table 701 is created for each transaction, and the collected data list constituting the request flow table 701 is arranged in time series according to the processing sequence. The collected data list that arrives earlier than the time point to be stored in the request flow table is stored in the collected data list buffer in step 649, and is stored in the table in step 665 when the time point to be stored is reached.

  In the first embodiment, a certain operation time is set in advance, and the performance data collection processing of the manager 130 and the collectors 131 and 132 is repeated for this time, but the manager 130 is given a function of accepting an end instruction from the user. Thus, processing can be performed for an arbitrary time. Changes to the flowchart shown in FIG. 2 necessary for performing this processing are as follows. The manager 130 has two changes: the end determination step 255 is “Is there an end instruction from the user?” And if there is an end instruction, the end instruction is transmitted to the collector before the end. The change of the collectors 131 and 132 is that step 295 is set to “Is there an end instruction from the manager?”.

  According to the first embodiment described above, the processing time related to the selected measurement target object can be collected. Furthermore, when processing is performed over a plurality of selected measurement target objects, these processing can be displayed as one processing flow 820, and the processing time for each object and the communication time between the objects can be displayed. is there.

(2) Second Embodiment In the first embodiment, when a user wants to acquire a processing flow, there is a hassle that the user must designate all objects involved in the processing flow as measurement targets. In the second embodiment, the user can obtain a processing flow for a series of processing after the processing performed by the object by designating one object. In order to realize this function, the collectors 131 and 132 create a request flow table. That is, a request flow table is added to a message that moves between objects, and a collection data list is added to the request flow table every time processing is performed on each object. The configuration and operation of the second embodiment will be described below for the distributed object environment shown in FIG.

  FIG. 9 is a flowchart illustrating a schematic procedure of processing of the entire system according to the second embodiment. This processing procedure consists of two blocks: a block 901 that is a part in charge of the manager 130 and a block 902 that is a part in charge of the collectors 131 and 132.

  First, the block 901 executed by the manager 130 will be described. In step 910, the manager 130 first receives an input for selecting an object to be processed at the beginning of the processing flow. This input method is the same as the method described in the first embodiment. However, the number of objects to be specified is limited to one. Next, in step 920, the object ID of the object from which the performance data input in step 910 is collected is notified to all the collectors 131 and 132 by broadcast. In step 930, the manager 130 waits for arrival of data transferred from the collectors 131 and 132. When the performance data is received, a processing flow is displayed in step 950. After the display, the end condition is determined in step 955. In the present embodiment, an arbitrary operation time is set in advance, and it is checked in step 955 whether the set time has been exceeded. If it exceeds, the process ends. If not, the process returns to Step 930. As described above, the processes in steps 930 and 950 are repeatedly performed for a predetermined time after the manager 130 first receives performance data from the collectors 131 and 132.

  Next, the block 902 executed by the collectors 131 and 132 will be described. In step 970, the collectors 131 and 132 receive the object ID broadcast by the manager 130. The collectors 131 and 132 start monitoring the objects being executed in the computers 101 and 102 in which the collectors are executed. When processing occurs in the object in step 980, the collectors 131 and 132 collect processing start time or message reception time, message transmission time or processing end time as necessary, and create processing flow data from the collected data. Next, the processing flow data created in step 990 is transmitted to the manager. After the performance data is transmitted, the end condition is determined in step 995. In this embodiment, the same operation time as the operation time of Step 995 is set in advance, and it is checked whether the time set in Step 995 has been exceeded. If it exceeds, the process ends. If not, the process returns to Step 980. As described above, the processes in steps 980 and 990 are repeatedly performed for a predetermined time after the collectors 131 and 132 receive the object ID data from the manager 130.

  FIG. 10 is a diagram illustrating a data configuration of the collection data list 1101 used in the second embodiment. The collection data list 1101 includes fields of an object ID 1110, a reception time 1120, and a transmission time 1130. The object ID 1110 is an object specified by the user or an ID of any object constituting the processing flow. The reception time 1120 is a processing start time or a message reception time for the object. The transmission time 1130 is a message transmission time or a processing end time for the object.

  FIG. 11 is a diagram illustrating a data configuration of the request flow table 1201 used in the second embodiment. The request flow table 1201 is a table in which the collection data list 1101 is arranged in time series according to the order in which processing is performed. One request flow table 1201 is created for each processing flow.

  Each object notifies the ID of the object and the process start time to the collector provided in the computer when an event such as data input occurs and the process starts. Each object notifies the collector of the ID of the object and the time when the message transmission occurred at the time of message transmission to the other object. The request flow table 1201 is received from the collector, and the received request flow table 1201 is added to a message to another object and transmitted. When a message or message and request flow table 1201 are received from another object, the collector receives the ID of the object, the request flow table 1201 if the request flow table 1201 has been received, and message transmission continues. A flag indicating whether or not to perform is notified. In addition, when the series of processing ends, the collector notifies the collector of the object ID and processing end time.

  In the process of step 910, that is, the process of receiving an object selection input from the user, the collectors 131 and 132 display the measurement target object selection screen 301 and receive the input of the object ID as in the first embodiment. However, in the second embodiment, only one of the object IDs displayed in the object list window 302 can be selected. When the measurement start button 303 is pressed after the object ID is selected, the manager 130 broadcasts the selected object ID to the collectors 131 and 132.

  FIG. 12 is a flowchart showing the processing flow of the collectors 131 and 132 that collect performance data and create the request flow table 1201. First, the collectors 131 and 132 check whether or not a preset time has been exceeded (step 1005). If it exceeds, the processing of the collectors 131 and 132 is terminated. If not, it waits for the occurrence of communication for all objects being executed on the computer (step 1010).

  When a message transmission notification or a process start notification and a message transmission notification are received from any object (step 1020 YES), it is checked whether or not the object to be transmitted is a selected (designated) object (step 1030). If it is not the designated object (NO in step 1030), it is not necessary to collect performance data, and the process returns to step 1005. If it is a designated object, an area for the request flow table 1201 is secured on the memory (step 1032). Next, an area of the collection data list 1101 is secured in the memory (step 1034), and the object ID 1110, the reception time 1120, and the transmission time 1130 are stored in this list (step 1036). The object ID 1110 stores the object ID of the object, the reception time 1120 stores the processing start time, and the transmission time 1130 stores the transmission time. Next, the created collection data list 1101 is added to the last end of the request flow table 1201 and transmitted to the object (step 1040).

  On the other hand, when a message reception notification is received from the object (NO in step 1020), it is checked whether the request flow table 1201 is added to the notification (step 1050). If the request flow table 1201 is not added (step 1050 NO), it is checked whether or not the object is a designated object (step 1060). If it is not the designated object (NO in step 1060), it is not necessary to collect performance data, and the process returns to step 1005. If it is the designated object, an area for the request flow table 1201 is secured in the memory (step 1062), and the process goes to step 1070.

  When the request flow table 1201 is added to the message reception notification (YES in step 1050), an area of the collection data list 1101 is secured on the memory (step 1070), and the object ID 1110 and the reception time 1120 are stored in this list (step 1010). 1072). The object ID 1110 stores the object ID of the object, and the reception time 1120 stores the message reception time.

Next, it is determined whether or not the transmission continues with the flag received from the object (step 1080). If transmission continues (YES in step 1080), the message transmission notification from the same object is waited, and when the message transmission notification is received, the transmission time is stored in the transmission time 1130 of the collection data list 1101 being created. (Step 1082). Next, the created collection data list 1101 is added to the last end of the request flow table 1201 that has already been received from the object or is newly generated, and transmitted to the object (step 1084).

  If the transmission does not continue (NO in step 1080), the processing end notification from the same object is awaited, and when the processing end notification is received, the processing end time is stored in the transmission time 1130 of the collection data list 1101 being created (step 1085). Next, the created collection data list 1101 is added to the last end of the request flow table 1201 that has been received from the object or newly generated (step 1086), and the completed request flow table 1201 is transmitted to the manager 130 (step 1088), it returns to step 1005.

  Next, processing flow display performed in step 950 will be described. Here, the processing flow 820 is displayed on the measurement result display screen 810 as in the first embodiment. The object ID 801 is the object ID 1110 itself of the collection data list 1101 constituting each row of the request flow table 1201, and the processing time 802 for executing the object is the reception time 1120 and the transmission time of the collection data list 1101 constituting each row of the request flow table 1201. The communication time 803 is obtained by taking the difference between the transmission time and the reception time of the two consecutive collection data lists 1101 constituting the request flow table 1201.

  According to the second embodiment described above, the user can obtain a subsequent processing flow from the processing of the object by designating one object. Thus, for example, even if it is not known which server object a certain client object accesses, it is possible to obtain a processing flow of a series of processes starting from a request from the client only by specifying the client object. It is also possible to extract a processing flow processed by a specific object as in the first embodiment.

(3) Third Embodiment In the first and second embodiments, an input of an object to be measured or an object to be processed at the head of the processing flow is received, and a processing flow or a specified object related to the specified object is received. Acquired the processing flow at the beginning of the process. In the third embodiment, the input of the target computer is accepted, and when the target computer is input, the point data of all objects executed in the designated computer can be acquired. In addition, a function of automatically switching between the performance data collection process and the point data collection process of the second embodiment according to the situation is provided.

  FIG. 13 is a diagram showing an example of a data collection target selection screen 1410 displayed on the display device of the computer 103. The selection screen 1410 displays a flow data selection button 1420 and a point data selection button 1430. The flow data selection button 1420 is a button that is pressed when selecting flow data as a collection target. As described in the first embodiment, the flow data refers to the processing time of each object and the communication time between objects that constitute the processing flow when a series of processing is performed over a plurality of objects. It is a collection. The point data selection button 1430 is a button that is pressed when selecting point data as a collection target. Point data is a collection of processing times of all objects executed on a computer by paying attention to the computer.

  FIG. 14 is a diagram illustrating an example of a measurement target computer selection screen 1510 displayed on the display device of the computer 103. The measurement target computer selection screen 1510 displays a computer list window 1520 and a measurement start button 1530. The computer list window 1520 displays a list of all computers connected on the LAN 140. The measurement start button 1530 is a button for instructing the start of measurement after a computer is designated.

  FIG. 15 is a diagram showing a data structure of the threshold table 1610 set on the memory of the computer 103. “Object ID” is the ID of each object, and “Processing time” is the upper limit of the time required for processing in the object. “Processing time” is a processing elapsed time including a waiting time generated in a computer executing the processing. The “waiting time” is a waiting time from when the object requests processing to an object of another computer until the result is received.

  FIG. 16 is a diagram showing an example of a point data collection result display screen displayed on the display device of the computer 103. On the screen, the identifier of the designated measurement target computer, the ID of the object executed on the computer, and the processing time are displayed. Idle is a waiting time that occurs because the object immediately above has requested processing from an object of another computer.

  FIG. 17 is a flowchart illustrating a processing flow of the manager 130 according to the third embodiment. The flowchart is mainly composed of three blocks: a block 1301 for initial setting of data collection / display target, a block 1302 for collection / display of flow data, and a block 1303 for collection / display of point data.

  The manager 130 first displays a selection screen 1410, and determines from the input information whether the data collection target is flow data or point data (step 1305). When the flow data is selected, the measurement target object selection screen 301 is displayed, and designation of the target object located at the beginning of the processing flow is accepted (step 1307). When the measurement start button 303 is pressed, the process proceeds to step 1310. On the other hand, when the point data is selected, a measurement target computer selection screen 1510 is displayed, and designation of the measurement target computer is accepted (step 1309). When the computer is specified and the measurement start button 1530 is pressed, the process proceeds to step 1360.

  In the case of flow data collection / display, first, the ID of the designated object is notified to each collector to instruct data measurement (step 1310). Next, the request flow table 1201 is received from each collector (step 1320), and the collected data is edited to display the processing flow (step 1330). The processes in steps 1310 to 1330 described above are the same as the processes of the manager 130 and the collectors 131 and 132 in the second embodiment.

Further, it is determined whether or not it is necessary to switch the measurement target with reference to the threshold table 1610 on the memory (step 1340). The manager 130 compares the processing time including the waiting time of the in-computer processing measured for each object constituting the processing flow with the processing time of the corresponding object on the threshold value table 1610. If there is no object having a measurement time exceeding the processing time threshold (NO in step 1340), it is determined that switching is not necessary, and the process returns to step 1310 to continue the flow data collection / display processing for the objects constituting the same processing flow. On the other hand, if there is an object having a measurement time exceeding the threshold (YES in step 1340), it is determined that switching is necessary, one corresponding object is selected, and the computer on which the object is executed is set as the measurement target. (Step 1350). The manager 130 makes an inquiry to each collector 131, 132 by specifying the ID of the object, and obtains an answer of the identifier of the computer on which the collector that monitors the object is executed. The process advances to step 1360 to switch to point data collection / display processing.

  In the case of collecting / displaying point data, the manager 130 first instructs the collector corresponding to the designated computer to measure data for the processing of all objects executed by the computer (step 1360). Upon receiving the instruction, the collector receives notification of processing start time, message reception time, message transmission time, and processing end time from the object to be measured. Then, a collection data list 501 is created for the target object, and a request flow table is created by arranging the collection data list 501 in time series for each processing flow. Next, the processing time and waiting time of each target object are calculated from this request flow table. The processing time is the difference between the processing start time and the message transmission time, the difference between the message reception time and the message transmission time, or the difference between the message reception time and the processing end time. The waiting time is a difference between a message transmission time to an object of another computer and a reception time of a message from the same object of another computer. Next, the collector transmits the processing time and waiting time of each target object to the manager 130. The collector measures data from when a data measurement instruction is received until a predetermined time elapses, and collectively transmits these data to the manager 130. The manager 130 receives the measurement data from the collector (step 1370) and displays the collected point data (step 1380).

Next, it is determined whether it is necessary to switch the measurement target with reference to the threshold value table 1610 on the memory (step 1390). The manager 130 compares the waiting time measured for each measurement target object with the waiting time of the corresponding object on the threshold table 1610. If there is no object having a waiting time exceeding the waiting time threshold (NO in step 1390), it is determined that switching is unnecessary, and the process returns to step 1360 to continue the point data collection / display processing for the designated measuring object computer. On the other hand, when there is an object having a waiting time exceeding the threshold (YES in step 1390), one corresponding object is selected, the object is set as a measurement target, the process proceeds to step 1310, and the process is switched to the flow data collection / display process. .

  According to the third embodiment, when an object whose processing time exceeds a processing time upper limit set value is detected during flow data collection, the processing of another object executed on the computer on which the object is executed The cause of excessive processing time can be pursued by collecting time. In addition, when an object that has measured a waiting time exceeding the upper limit setting value of the waiting time is detected while collecting point data, the cause of excessive waiting time is collected by collecting flow data for the processing flow that starts with the processing of that object. Can be pursued. In this way, by collecting performance data while switching from flow data collection to point data collection and point data collection to flow data collection, the performance bottleneck exists in which object in which processing flow, or on which computer It is possible to detect which objects are present. Switching between flow data collection and point data collection at this time can be automatically performed.

(4) Fourth Embodiment When a large number of objects operate on a plurality of computers, it is possible to grasp which object is related to which object and which processing flow is concentrated in which processing flow. It can be difficult. The fourth embodiment solves such a problem by obtaining the relationship of calls between objects and the number of calls, thereby supporting performance monitoring.

  The features of the fourth embodiment will be described below using the schematic processing procedure of FIG. 2 in the distributed object environment shown in FIG. The manager 130 first displays a list of objects in step 210 and accepts an input for selecting an object for which object correlation data is collected. It is also possible to select all objects on the object list. Next, in step 220, the object ID of the object from which the object correlation data input is collected is notified to all the collectors 131 and 132 by broadcast. In step 230, the manager 130 waits for arrival of the collection data list 501 transferred from the collectors 131 and 132. When the collection data list 501 is received, a call table 2001 to be described later is created from the collection data list 501 in step 240, and an object correlation diagram 1802 to be described later is created and displayed from the call table 2001 in step 250. After the display, an end condition is determined in step 255 as to whether or not the specified time has passed. If the specified time has not passed, the process returns to step 230 and the above processing is repeated.

  On the other hand, the processing of the block 202 executed by the collectors 131 and 132 is exactly the same as that described in the first embodiment.

  FIG. 18 is a diagram showing the data structure of the call table 2001. As shown in FIG. The caller 2010 is the ID of the object that issued the request, the callee 2020 is the ID of the object that received the request, and the number of calls 2030 is the number of times the request has been issued, that is, the number of times the object of the callee 2020 has been called.

  FIG. 19 is a diagram illustrating an example of an object correlation diagram display screen 1801. The object correlation diagram display screen 1801 displays an object correlation diagram 1802. 1810 is an object ID display section, 1820 is a line segment that joins related objects, and 1830 is the number of times an object located on the right side of the line segment 1820 is called. An object correlation diagram 1802 in FIG. 19 is a diagram of the call table 2001 illustrated in FIG.

FIG. 20 is a flowchart showing the flow of processing in steps 240 and 250 described above. When the collection data list 501 arrives from the collector, it first matches the receiving object ID 503 of the collection data list 501 received by the caller 2010 in the call table 2001, and the call destination 2020 is an object of the collection data list 501. It is checked whether there is a line that matches the ID 502 (step 1910). In this case, the object indicated by the object ID 502 is an object designated as a measurement target. If there is a match (step 1910 YES), 1 is added to the number of calls 2030 in the matched call table row (step 1920). If there is no match (NO in step 1910), the call table 2001 includes a line with the caller 2010 as the receiving object ID 503 in the collection data list 501, the callee 2020 as the object ID 502 in the collection data list, and the number of calls 2030 as 1. Add (step 1925).

  After the call table 2001 is updated by the processing of step 1920 or 1925, the display of the object correlation diagram 1802 on the object relation diagram display screen 1801 is updated based on the latest call table 2001 (step 1930).

  Note that the caller 2010 may be considered to match the object ID 502 of the collection data list 501 and the callee 2020 may match the transmission object ID 506 of the collection data list 501. Also in this case, the object indicated by the object ID 502 is the object designated as the measurement target.

According to the fourth embodiment described above, when the collection data list 501 is collected for a specified object and a series of processing is performed from the object to another object, the caller / callee between these objects The object relation diagram 1802 showing the number of requests between objects can be displayed.

It is a block diagram of the computer system of embodiment. It is a figure which shows the schematic procedure of the process of 1st Embodiment. It is a figure which shows the example of the measurement object selection screen 301 of 1st Embodiment. It is a figure which shows the data structure of the collection | collection data list 501 of 1st Embodiment. It is a flowchart which shows the flow of a process of the collectors 131 and 132 of 1st Embodiment. It is a figure which shows the data structure of the request flow table 701 of 1st Embodiment. It is a figure which shows the example of the measurement result display screen 810 of 1st Embodiment. It is a flowchart which shows the process sequence of the manager 130 of 1st Embodiment. It is a figure which shows the schematic procedure of the process of 2nd Embodiment. It is a figure which shows the data structure of the collection data list 1101 of 2nd Embodiment. It is a figure which shows the data structure of the request flow table 1201 of 2nd Embodiment. It is a flowchart which shows the flow of a process of the collectors 131 and 132 of 2nd Embodiment. It is a figure which shows the example of the selection screen 1410 of 3rd Embodiment. It is a figure which shows the example of the measurement object computer selection screen 1510 of 3rd Embodiment. It is a figure which shows the data structure of the threshold value table 1610 of 3rd Embodiment. It is a figure which shows the example of the point data collection result display screen of 3rd Embodiment. It is a flowchart which shows the process sequence of the manager 130 of 3rd Embodiment. It is a figure which shows the data structure of the call table 2001 of 4th Embodiment. It is a figure which shows the example of the object correlation diagram display screen 1801 of 4th Embodiment. It is a flowchart which shows the flow of the process of the principal part of 4th Embodiment.

Explanation of symbols

101-103: Computer, 121-126 ... Object, 131-132 ... Collector, 130 ... Manager, 140 ... LAN, 501 ... Collection data list, 701 ... Request flow table

Claims (2)

A plurality of first computers for executing a program capable of realizing predetermined processing; a plurality of a series of processes composed of the plurality of programs; a second computer having a memory;
A system comprising:
The first computer includes an execution unit that executes one or more programs, and a call source program identifier that specifies the call source program and a call destination that specifies a call destination program when a call between the programs occurs. have a transmitting means for transmitting the performance data including the time of calling call message identifier and time called from another program and other programs that identifies the program identifier and paging message to the second computer,
The second computer is configured to receive performance data of a plurality of programs constituting a series of processes based on receiving means for receiving the performance data, the call source program identifier, the call destination program identifier, and the call message identifier. Association means for associating, storage means for storing the associated performance data in the memory for each series of processing, time called from the other program included in the one performance data, and time called another program Calculation means for calculating the processing time of the program on the basis of a plurality of call times based on the plurality of call times included in the associated performance data, and association of the performance data and output means for outputting said calculated communication time and processing time for each series of processes based on System that is characterized by having. A second computer having a memory and connected to a system capable of executing a plurality of series of processes by a plurality of first computers capable of executing a program for realizing a predetermined process;
When a call between programs executed by the first computer occurs by executing the series of processing, a call source program identifier for specifying a call source program and a call destination program identifier for specifying a call destination program; Means for receiving, from one or more first computers, performance data including a time when the other program is called, a time when the other program is called, and a call message identifier that identifies a call message;
Means to associate the performance data of a plurality of programs constituting the series of processing based on said caller program identifier and said call destination program identifier and the call message identifier,
Means for storing the associated performance data in the memory for each series of processing;
The processing time of the program is calculated based on the time when the other program included in the one performance data is called and the time when the other program is called, and the plurality of calls included in the associated performance data Means for calculating a communication time between programs having a calling relationship based on time;
And a means for outputting the calculated communication time and processing time for each series of processes based on the association of the performance data.

Images