Multiplicity adjustment system and method

A multiplicity adjustment agent collects request information database from a sub-system including an element of a system to be monitored. An individual sub-system's multiplicity adjustment server sorts and merges request information collected from each sub-system for each element/request path. An integrated multiplicity analysis server calculates a necessary multiplicity on the basis of the request information.

INCORPORATION BY REFERENCE

The present application claims priority from Japanese application JP2005-016250 on Jan. 25, 2005, the content of which is hereby incorporated by reference into this application.

BACKGROUND OF THE INVENTION

The present invention relates to a simultaneous executable multiplicity adjustment system and method for determining a simultaneous executable multiplicity as an upper limit value corresponding to a maximum number of requests simultaneously executable in a distributed system (in particular, Web system) having a plurality of divided sub-systems.

A distributed system (in particular, Web system) having a plurality of functionally-divided sub-systems has a complicated structure because the system has many elements. Even when a system looks like a virtually single system when viewed from system users, the structure of a server is divided into elements according to a logical or physical boundary such as business type, development department, sub-network or the like. By combining such elements called sub-systems, a total system can be realized.

For this reason, the cause of a problem such as performance bottleneck is also complicated, and thus it is difficult to suitably design a multiplicity, considering also the influences on other systems cooperated therewith. Meanwhile, it is desirable to stably run the system and establish optimum system environments satisfying performance requirements. In other words, it is desirable to set the system considering an optimum trade-off between the performance bottleneck and the system stability.

JP-A-5-173807 discloses a technique in which, for solving a performance bottleneck, the number of simultaneously-executable jobs (job executable multiplicity) is set from a job input queue, and the job executable multiplicity is changed according to a measured server load quantity. JP-A-5-143559 discloses a technique in which, of service computers which informed of their load states in response to a load state notification, the service computer having a lightest load is found to be connected.

SUMMARY OF THE INVENTION

However, the techniques disclosed in the aforementioned Patent Documents cannot satisfy both of the system running stability and the effective resource use under some system condition.

In JP-A-5-173807, for example, as a job CPU time is increased (as a load on a server is increased), the job executable multiplicity decreases. In this connection, in an online system (such as a distributed system having a plurality of functionally-divided sub-systems, e.g., a Web system), when a job generation rate or the number of input jobs is small (when a load on a server is small), the job executable multiplicity is increased. From the viewpoint of the effective resource use, however, it is actually desirable to decrease the job executable multiplicity of the job in question and to allocate the server resource to another job (to increase the job executable multiplicity of the other job). In other words, there exists a problem that such a job executable multiplicity as to meet both respects of the system running stability and the effective resource use cannot be determined only from the consideration of the server load.

In JP-A-5-143559, further, when a request goes through a plurality of system elements, it is impossible to determine the job executable multiplicity of each element. This Patent Document also cannot cope with a resource lack or an increased number of jobs caused by increased number of system users.

It is an object of the present invention to provide a multiplicity adjustment system which can assist in designing a simultaneous executable multiplicity (which will be referred to merely as multiplicity, hereinafter) to secure the stable running of the system. Another object of the present invention is to provide a multiplicity adjustment system which can cope with a resource lack or a situation when a request generation rate (the number of generated requests per unit time) is increased by an increased number of system users.

In accordance with the present invention, the above objects can be attained by providing a multiplicity adjustment system for adjusting the multiplicity of a request to a system to be watched which, on the basis of a request to one of elements included in the watch system of interest, calculates the multiplicity of a request to each element, acquires information about the request multiplicity from the multiplicity adjustment agent, and stores the acquired information as request information for each element. And the system also acquires the stored request information for each element, analyzes the request multiplicity of each element on the basis of the acquired request information, and changes the request multiplicity for each element according to the analyzed result.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Preferred embodiments of the present invention will be detailed by referring to the accompanying drawings. However, the present invention is not limited to the specific example.

FIG. 1shows a general configuration of a system in accordance with the present embodiment. As shown inFIG. 1, a simultaneous executable multiplicity adjustment system103is arranged to watch a system107to be monitored.

The monitored system107is made up of a plurality of sub-systems. These sub-systems can be used by a monitored system use terminal106connected therewith. InFIG. 1, the structure of only one108of the plurality of sub-systems is shown. The sub-system108has monitored system elements113and115, and a plurality of multiplicity adjustment agents110and112for individually watching the monitored system elements113and115. The monitored system elements113and115include queues109and111for limiting the multiplicity. The multiplicity adjustment agents110and112are connected to a request information database114for storing information obtained from the monitored system elements113and115.

The simultaneous executable multiplicity adjustment system103has an individual sub-system's multiplicity adjustment server105and an integrated multiplicity analysis server104. The individual sub-system's multiplicity adjustment server105, which is provided for each sub-system, functions to individually watch the sub-system108through the multiplicity adjustment agents110and112to collect request information. The integrated multiplicity analysis server104integrates a plurality of individual sub-system's multiplicity adjustment servers105. A multiplicity adjustment terminal102is connected to the integrated multiplicity analysis server104. An operator101of the monitored system107can obtain design assist information about multiplicity from the integrated multiplicity analysis server104via the multiplicity adjustment terminal102.

As mentioned above, since the multiplicity adjustment system individually watches the monitored system elements113and115to collect information necessary for determining a multiplicity for each element, this can assist the operator in designing an optimum multiplicity for the entire system. Further, definition information for setting a multiplicity for each distributed product can be managed at one location across products.

FIG. 2is a schematic sequence diagram showing a relation between processing flows and functional modules in the system ofFIG. 1. Blocks surrounded by thick lines on the left side ofFIG. 2show a summary of processing operation steps, and blocks surrounded by dotted lines on the right side of the left-side blocks show details of the respective step operations. Blocks on the upper side of the drawing indicate operations to be carried out by the terminal, the server and so on. In the present embodiment, “modify” and “change” of a multiplicity are defined as follows.

“Modify”: To virtually set a multiplicity on the integrated multiplicity analysis server104. And the multiplicity is not actually set yet.

“Change”: To actually set a multiplicity for the element of the monitored system107.

InFIG. 2, first of all, actually measured values are collected (Step201). More specifically, the multiplicity adjustment agents110and112collect actually measured values (Step207). That is, the multiplicity adjustment agents110and112collect request-associated actually-measured values generated by the actual system operation from the monitored system107, and transmit the collected actually measured values as request information to the individual sub-system's multiplicity adjustment server105. The individual sub-system's multiplicity adjustment server105then collects the actually measured values and set values (Step206) and transmits the actually measured values and the multiplicity set values for each element to the integrated multiplicity analysis server104. The details of Step201will be explained later inFIG. 12.

After Step201, a bottleneck in the monitored system107is analyzed (Step202). More specifically, the integrated multiplicity analysis server104automatically analyzes the bottleneck on the basis of the information collected from the individual sub-system's multiplicity adjustment server105in Step201(Step208). The integrated multiplicity analysis server104transmits its analyzed result to the multiplicity adjustment terminal102, which in turn displays the analyzed result information (Step209). The details of Step202will be explained later inFIGS. 13 to 17.

Subsequent to Step202, a multiplicity modification process is carried out (Step203). More specifically, the operator of the monitored system determines a suitable multiplicity on the basis of the above bottleneck analysis result information and modifies the multiplicity from a multiplicity modify/change view320. The multiplicity adjustment terminal102transmits a multiplicity modification instruction to the integrated multiplicity analysis server104on the basis of an entry from the monitored system operator (Step210). And the integrated multiplicity analysis server104modifies the multiplicity on the basis of the transmitted information (Step211). The details of Step203will be explained later inFIG. 18.

Subsequent to Step203, an influence analysis process is carried out (Step204). More specifically, the integrated multiplicity analysis server104automatically analyzes an influence on the basis of the multiplicity modified in Step203(Step212), the integrated multiplicity analysis server104transmits its influence analyzed result to the multiplicity adjustment terminal102, and the multiplicity adjustment terminal102in turn displays the influence analysis result information (Step213). The details of Step204will be explained later inFIGS. 19 to 22.

Subsequent to Step204, a multiplicity change process is carried out (Step205). More specifically, when the monitored system operator enters a multiplicity in the multiplicity modify/change view320of the multiplicity adjustment terminal102on the basis of the influence analysis result information displayed in Step204, the multiplicity adjustment terminal102transmits the entered multiplicity change information to the integrated multiplicity analysis server104(Step214). And the integrated multiplicity analysis server104transmits a multiplicity change request to the individual sub-system's multiplicity adjustment server105(Step215). The individual sub-system's multiplicity adjustment server105in turn increases the multiplicity set value of the monitored system107, and thereafter instructs the multiplicity adjustment agents110and112to change the multiplicity (Step216). The details of Step204will be explained later inFIG. 24.

Through the above operations, information necessary for determining a multiplicity for each element is collected, an element forming a bottleneck is searched for on the basis of the collected information (bottleneck analysis process), and a multiplicity for the bottleneck element is temporarily modified. Thus, an influence on the other elements caused by the multiplicity change (influence analysis process) or the like can be carried out, and the design of a multiplicity optimum for the entire system can be assisted. Once the multiplicity is determined, system arrangement can be automatically changed so as to satisfy the multiplicity.

Although the processes of collecting actually measured values and set values in Steps206and207are of a push type (wherein information acquired by an information generation originator is transmitted to an information collection destination), the processes may be of a pull type (wherein an information collection destination collects information acquired by an information generation originator). The push type process, which can collect request information on a real-time basis, is advantageous in that dynamic optimization of a multiplicity enables dynamic redistribution of server resources. The pull type process, on the other hand, is advantageous in that a monitored system operator or administrator can collect, as necessary, information necessary for multiplicity design in a necessary period and can determine a prefixed optimum multiplicity set value. For this reason, since an overhead to the system caused by dynamic multiplicity change can be reduced, system performance can be advantageously secured.

FIG. 3shows details of a system configuration shown inFIG. 1. Meanings of information and definitions inFIG. 3are shown in a Remark9999. In the present embodiment, the integrated multiplicity analysis server104operable by the terminal102connected to a network manages the respective sub-systems108via the individual sub-system's multiplicity adjustment server105. The sub-system108has the monitored system elements113and115of the monitored system connected via the network and the multiplicity adjustment agents110and112for watching these elements113and115. The multiplicity adjustment agent110watches the monitored system element113in the sender side; while the multiplicity adjustment agent112watches the monitored element115in the receiver side. More in detail, the monitored system elements113and115refer to functional modules such as thread, instance, load balancer, HTTP daemon and DBMS; or system elements on which the multiplicity adjustment agents110and112can directly perform a multiplicity control process or a load balance process.FIG. 3is different fromFIG. 1in an envelope relation between the monitored system elements113and115and the multiplicity adjustment agents110and112. However, both arrangements ofFIGS. 1 and 3are essentially the same in the operations of the present embodiment.

The multiplicity adjustment agent110includes a transmission multiplicity control module301and a transmission request measurement module302. The transmission multiplicity control module301performs the load balance process and multiplicity control process on the monitored element115on the basis of the multiplicity set value changed in the multiplicity change process (Step205inFIG. 2). The transmission request measurement module302performs the actually-measured value collection process (Step207inFIG. 2). More specifically, the module302acquires untransmitted request information304for each time band/request path from the sender-side monitored system element113on the basis of a transmission definition303for an actually measured value to be acquired. In this example, the “request path” indicates a path for a request to go through system elements. Details of a data structure expressing a request path will be later explained in the form of a request path definition918inFIG. 9.

In the transmission definition303of an actually measured value to be acquired, information to be acquired is defined. The detailed structure of the transmission definition303is shown inFIG. 9and explained later. In the untransmitted request information304for each time band/request path, untransmitted requests acquired by the transmission request measurement module302are classified according to each time band/request path.

The multiplicity adjustment agent112includes a reception multiplicity control module305and a reception request measurement module307. The reception multiplicity control module305performs a load balance process and a multiplicity control process on the monitored element115on the receiver side; whereas, the reception request measurement module307acquires unprocessed request information309for each time band/request path and processed request information310for each time band/request path from a request to the monitored element115on the receiver side.

Server load information306on its own element indicates the load state of the monitored system element115on the receiver side. A reception definition308for an actually measured value to be acquired defines information to be acquired (, which is shown inFIG. 9in the form of its detailed structure). In the unprocessed request information309for each time band/request path, unprocessed requests acquired by the reception request measurement module307are classified according to each time band/request path. In the processed request information310for each time band/request path, processed requests acquired by the reception request measurement module307are classified according to each time band/request path. In a multiplicity definition311of its own element, information about the simultaneous executable multiplicity of the monitored system element115on the receiver side is defined, and the detailed structure of the definition is shown inFIG. 9.

Explanation will be made in detail as to the transmission multiplicity control module, transmission request measurement module302, reception multiplicity control module305, and reception request measurement module307in the multiplicity adjustment agents110and112.

Explanation will first be directed to the transmission multiplicity control module301. When the monitored system element113tries to transmit a request to the system element115for executing a business logic in the receiver side, the transmission multiplicity control module301once traps the request. And the module301decides whether or not to transmit the request on the basis of the server load information306of its own element and the multiplicity definition311of its own element. When deciding to transmit the request, the module301decides one of clustered system elements115to which the module transmits the request, and performs the load balance process and the multiplicity control process.

Explanation will next be made as to the transmission request measurement module302. When the transmission multiplicity control module301decides that transmission of the received request is impossible, the transmission request measurement module302acquires necessary information from information about the request on the basis of the transmission definition303for an actually measured value to be acquired. And the module302stores the acquired information in the untransmitted request information304for each time band/request path. Lastly, the module302returns an error to the monitored system element113on the transmission side.

The reception multiplicity control module305will then be explained. When a request is transmitted from the monitored system element113in the transmission side to the monitored system element115on the reception side, the reception multiplicity control module305once traps the request. And the module305decides whether or not to process the request on the basis of the server load information306of its own element and the multiplicity definition311of its own element. When deciding to process the request, the module305performs the load balance process and the multiplicity control process by deciding one of clustering elements115to which the module transmits the request.

Explanation will lastly made as to the reception request measurement module307. The reception multiplicity control module305decides that processing of the received request is impossible, the reception request measurement module307acquires necessary information from information about the request on the basis of the reception definition308for an actually measured value to be acquired. And the module307stores the acquired information in the unprocessed request information309for each time band/request path. Lastly, the module307returns an error to the monitored system element113in the transmission side. Meanwhile, when the reception multiplicity control module305decides to process the received request, the reception request measurement module307acquires necessary information from information about the request on the basis of the reception definition308for an actually measured value to be acquired. And the module307stores the acquired information in the processed request information310for each time band/request path. Finally, the module307issues the request to the monitored system element115on the reception side.

The individual sub-system's multiplicity adjustment server105includes an individual sub-system's measured-value collection module312and a multiplicity change instruction module315for instructing the multiplicity adjustment agents110and112to change the multiplicity.

The individual sub-system's measured-value collection module312, on the basis of a sub-system internal arrangement definition316, collects and merges the untransmitted request information304for each time band/request path and the unprocessed request information309from each time band/request path from the multiplicity adjustment agents110and112, classifies the collected information according to each element, and stores the classified information in an unarrived request information313for each element/time band/request path. The individual sub-system's measured-value collection module312further collects the processed request information310for each time band/request path from the multiplicity adjustment agents110and112, classifies the collected information according to each element, and stores the classified information in processed request information314for each element/time band/request path.

The multiplicity change instruction module315, when accepting a multiplicity change instruction from the integrated multiplicity analysis server104, changes the multiplicity set value of the multiplicity definition311of its own element for the multiplicity to be changed on the basis of a multiplicity setting meta definition317.

In this case, in the sub-system internal arrangement definition316, relations between a plurality of elements in a sub-system and structure thereof are recorded. The detailed structure of the definition316is shown inFIG. 8. The multiplicity setting meta definition317indicates what item in what definition file indicates a multiplicity parameter. The detailed structure of the definition317will be later explained inFIG. 9.

Explanation will finally made as to a summary of the integrated multiplicity analysis server104. The integrated multiplicity analysis server104includes a measured value collection module322for collecting request information, a bottleneck analysis module321for analyzing a bottleneck in a monitored system, a multiplicity modification module326for temporarily modifying a multiplicity, an influence analysis module324for analyzing the influence of the temporarily-modified multiplicity on the entire monitored system, and a multiplicity change module328for actually changing an actual multiplicity set value for the monitored system.

The load balance process in the multiplicity control modules301and305in the multiplicity adjustment agents110and112are not indispensable or essential, and thus it is only required for the process to be carried out on any one of the transmission and reception sides. Further, the function of performing the load balancing process and the multiplicity control process may be provided, in some cases, by an existing application server product. When such an application server is employed, the multiplicity control modules301and305are arranged, in many cases, in the interiors of the monitored system elements113and115in the form of a plug-in or library (see the configuration ofFIG. 1). When the multiplicity control modules301and305are newly mounted, on the other hand, these modules can be realized by externally arranging the modules outside of the monitored system elements113and115(see the arrangement ofFIG. 3). Further, if it is difficult to mount the multiplicity control on the transmission side, then the multiplicity control may be carried out only on the reception side. In this case, since generation of an untransmitted request in the transmission side can be avoided, provision of the transmission request measurement module302becomes unnecessary.

With respect to the timing of collecting request information, the request measurement modules302and307may transmit a request periodically to the individual sub-system's measured-value collection module312or each time that the request is generated, or the individual sub-system's measured-value collection module312may periodically collect such a request. The collection of request information can be realized even by an existing profiler product. When a profiler is employed, the request measurement modules302and307are used as plugs-in or libraries, or are provided, in many cases, within the monitored system elements113and115, for example, by changing a program and embedding the module therein (refer to the configuration ofFIG. 1). When the request measurement modules302and307are newly mounted, it can be realized by providing the modules outside of the monitored system elements113and115(refer to the configuration ofFIG. 3).

With respect to the timing of reflecting the multiplicity definition311of its own element on the multiplicity control modules301and305, the multiplicity control modules301and305may periodically reload a multiplicity set value. Or each time that the multiplicity change instruction module315changes a multiplicity set value, the module315may instruct the multiplicity control modules301and305to reload the multiplicity set value. In this case, in order to avoid the influence thereof on the request during process, it is desirable that the process of reloading a multiplicity set value be carried out in the following procedure. That is, (1) the acceptance of a request to the multiplicity control modules301and305is suspended (blockaded). (2) The system waits for until the request process during process is fully completed. (3) At the time point that the request during process becomes null, the system reloads a multiplicity set value. (4) Finally, the system releases the blockade.

As mentioned above, by changing the number of the multiplicity control modules301and305or the number of the transmission request measurement modules302or by utilizing an existing product, the system can have an arrangement which pays consideration to the balance between the availability or performance demanded by the system and the operational load of the operator/administrator of the monitored system. For this reason, the present invention can advantageously support the optimum system configuration realizing compatibility between the secured performance and system running stability and the design work of deriving parameter values. Further, the present invention has an advantage that server resources can be dynamically redistributed in real time by shortening a timing interval of collecting a request and automatically changing the multiplicity set value.

FIG. 4is a general configuration of a bank system401as an example of the monitored system107. A large scale system such as the bank system401has sub-systems specialized in respective businesses. InFIG. 4, a financing system402, a sales office system404, an interest rates system403, and a security & guarantee system405correspond to the sub-systems108inFIG. 1. InFIG. 4, the general configuration of the bank system401will be explained in connection with an example of paths of a request going through the bank system401.

A request issued from the monitored system use terminal106(browser) arrives at the interest rates system403or the security & guarantee system405via the financing system402or the sales office system404. The request arrived at the security & guarantee system405is distributed from a load balancer406for security & guarantee to a security Web407and a guarantee Web411.

The request arrived at the security Web407is sent to a security server408and a guarantee database (DB)409. Meanwhile, the request arrived at the guarantee Web411is distributed to a guarantee inquiry thread416and a guarantee registration thread419. The request arrived at the guarantee inquiry thread416, as necessary, accesses guarantee instance417or the guarantee registration thread419, and accesses the employment income earner guarantee instance417and further a guarantee DB427. The request arrived at the guarantee registration thread419, on the other hand, accesses, as necessary, a self-supporter guarantee instance423before or after the execution of the business operation of a registration AP420or in the middle thereof.

The request arrived at the self-supporter guarantee instance423accesses, as necessary, the guarantee DB427before or after the execution of the business operation of a self-supporter inquiry AP424or a self-supporter registration AP426or in the middle thereof.

In the bank system401of the present embodiment, connection relations between the browser, load balancer, Web server, AP server, and DB server are as shown inFIG. 4. However, the actual connection relations therebetween can be realized in multiple-to-multiple connection. Although an example wherein connection between the browser and the Web server is made in HTTP (Hyper Text Transfer Protocol) is shown in the bank system401ofFIG. 4, another protocol supported by the load balancer such as FTP (File Transfer Protocol) may be employed. A system arrangement without any load balancer may also be possible. Further, the connection relation between the AP server and process, the connection relation between the process and thread or instance, and the connection relation between the thread or instance and business AP may also be realized in multiple-to-multiple connection.

As has been explained above, in accordance with the present invention, even when the bank system401has any complex arrangement, use of the method ofFIGS. 12 to 24advantageously enables support of the optimum multiplicity design.

In the present embodiment, system elements inFIG. 4are all shown as logically different elements. For example, the security server408and a guarantee server414are shown, assuming that logically different business applications are running. In the drawing, accordingly, such a plurality of physically divided elements that an identical type of plural AP servers are running for the purpose of increasing availability of AP server clustering or the like, are all regarded as an identical element and thus represented by a single element. Increasing availability represented by typical clustering also means to increase a sort of critical multiplicity by scale-out. In the case where the logical arrangement is considered (the boundary between the elements is considered) in view of the multiplicity as in the present embodiment, this means that such elements can be regarded as the same element. In this connection, the “critical multiplicity” as used therein means a multiplicity when the throughput is saturated and the server cannot run stably.

FIGS. 5 to 7show display view images of result information displayed after bottleneck analysis and after influence analysis.

FIG. 5shows a display view501for displaying and setting a request generation rate and a multiplicity. The word “request generation rate” refers to the number of generated requests per unit time. The request rate & multiplicity display/set view501mainly includes (1) a toolbar503for conducting various sorts of operations, (2) a system arrangement tree display area502for displaying system elements as a layer-by-layer tree from upper layer level to lower on the basis of an inter-system arrangement definition329(seeFIG. 3) and a group of sub-system internal arrangement definitions330(seeFIG. 3), (3) an element title display area508for displaying the title of an element (parent element) selected on the system arrangement tree display area502and a layer level title display area509for displaying the title of a layer level of the parent element, (4) an cooperation display area513indicative of how system elements in the same layer are cooperated, (5) an analysis result display area514for displaying bottleneck analysis result information318(seeFIG. 3) or an influence analysis result319(seeFIG. 3), and (6) a multiplicity modify/change area531for modifying/changing a multiplicity. Each of the respective sections (1) to (6) will be detailed below.

(1) The toolbar503has a measured-value collect button504to be clicked when the operator wants to conduct the measured-value collection process (Step201inFIG. 2), a bottleneck analysis button505to be clicked when the operator wants to conduct the bottleneck analysis process (Step202inFIG. 2), an influence analysis button506to be clicked when the operator wants to conduct the influence analysis process (Step204inFIG. 2), an individual element influence's analysis button507to be clicked when the operator wants to analyze the influence analysis process (Step204inFIG. 2) with only the influence of a specific element interior (a security & guarantee system6708being selected as the specific element in the example ofFIG. 5), and a time band list box510to be clicked when the operator wants to change a display time band.

When the processing time of the influence analysis process204of the entire system is long, a local influence can be grasped in a short time by using the individual element influence's analysis button507. Thereafter, when the influence of the entire system is recognized or grasped by using the influence analysis button506, a multiplicity design work time can be shortened. That is, this can advantageously reduce a try and error frequency for system tuning based on multiplicity.

(2) In the system arrangement tree display area502, system elements are classified according to various levels (system, sub-system, node (server), process, component (thread or instance), business AP) to represent envelope relations between the elements in the form of a tree. In the display area502, respective rectangular blocks indicate system elements which are displayed to have lower layers as the layer goes from upper layer level to lower on the paper sheet. The title of each element is given in each block. The elements on the display area502are given as an example of the bank system inFIG. 4.

The system arrangement tree display area502can assist the operator/administrator of the monitored system in his design work, since the operator/administrator can visually know the entire structure of the system therefrom and promote his understanding of the system structure.

In the system arrangement tree display area502, further, the security & guarantee system6708is surrounded by a block of a thick frame. This means that the cooperative state of elements (children elements in lower layer levels of the security & guarantee system405) of node levels of the security & guarantee system is displayed in the cooperation display area513. When an element being displayed on the cooperation display area513is displayed to be emphasized or highlighted by a thick frame block or the like in the system arrangement tree display area502in this manner, the operator can visually know the position of the element in the entire system. As a result, the visual knowing enables the operator to get easy understanding of the range of the multiplicity to be optimized, and thus it can assist the operator in his design work. Further, when the operator clicks a plus button, this causes a list of children elements at lower layer levels of the system element in question to be developed and displayed. Clicking a minus button causes a list of children element belonging to the system element in question to be closed.

(3) InFIG. 5, “security & guarantee system” as the title of the parent element selected in the system arrangement tree display area502is displayed on the element title display area508. A “sub-system” as the title of the layer level of the parent element is displayed on the layer level title display area509.

(4) The cooperation display area513shows the internal structure of the element (the security & guarantee system6708in the case ofFIG. 5) selected in the system arrangement tree display area502. When the operator moves a mouse pointer to each element displayed in the cooperation display area513, this causes simple information about the element to appear as a pop-up hint. Guarantee server information after influence analysis is displayed, for example, as a pop-up hint701for a guarantee server icon6714. Details of display contents of the pop-up hint701will be explained inFIGS. 6 and 7. A guarantee DB icon6721is surrounded by a thick frame line. This means that the detailed analysis result of the element in question is displayed on the analysis result display area514.

From the cooperation display area513, the operator can visually know a possible range influenced by the multiplicity change. As a result, the operator can get easy understanding of a range of multiplicity to be optimized and this can assist the operator in his design work. Since the element displayed on the analysis result display area514is highlighted by a thick frame line or the like in the cooperation display area513in this way, the operator can visually know the position of the element of interest in the parent element. As a result, since a range of multiplicity to be optimized can be made easy to understand, this can assist the operator in his design work.

(5) Shown in the analysis result display area514is an analysis result of the guarantee DB427(refer toFIG. 4) corresponding to the guarantee DB icon6721selected in the cooperation display area513. A result after the execution of the bottleneck analysis process (Step202inFIG. 2) is displayed in a bottleneck analysis result area515. A result after the execution of the influence analysis process (Step204inFIG. 2) is displayed in an influence analysis result area520. A detailed explanation of a result after the execution of the bottleneck analysis process202or the influence analysis process204as well as how to cope with the result are displayed in an analysis result explanation area527. Each item will be explained. In this connection, the meaning of specific numeric values displayed in each item and a relation between numbers will be explained inFIGS. 6 and 7. How to calculate numbers in each item will be explained in connection with a processing flow ofFIGS. 12 to 24.

(5-1) The bottleneck analysis result area515has an original multiplicity set value516as a multiplicity originally set by a multiplicity adjustment agent before bottleneck analysis, an original upper limit request generation rate517as a request generation rate calculated from the original multiplicity set value516, an actual request generation rate519as a request generation rate obtained after the bottleneck analysis using actually measured values, and an actually necessary multiplicity518as a necessary multiplicity calculated from the actual request generation rate519.

(5-2) The influence analysis result area520has an after-modification multiplicity set value521(which is automatically set when “automatic” is selected in a multiplicity modification method534(to be later explained) and which is entered by the user when “manual” or “enforcement” is selected) as a multiplicity modified after the bottleneck analysis; an after-modification upper limit request generation rate522as a request generation rate calculated from the after-modification multiplicity set value521; a current estimated request generation rate524after recalculation (details of which will be explained inFIG. 21) as a current request generation rate obtained as a result of the influence analysis considering a request newly taken in due to the multiplicity modification; a current necessary multiplicity523after recalculation as a necessary multiplicity calculated from the current estimated request generation rate524after recalculation; a future estimated request generation rate526after recalculation (details of which will be explained inFIG. 21) as a request generation rate which is obtained after influence analysis considering taken in in future due to multiplicity modification and which is estimated to possibly increase in future and reach the value; and a future necessary multiplicity525after recalculation as a necessary multiplicity calculated from the future estimated request generation rate526after recalculation.

(5-3) The analysis result explanation area527has a state528indicative of whether or not the request can be processed with the multiplicity set value; a guide529indicative of how to cope with a situation when the multiplicity set value is insufficient or the insufficient multiplicity set value is estimated; and a reason530indicative of a reason why it led to determination of the state528or the guide529. As a message given in the state528, three patterns of “multiplicity is currently sufficient”, “multiplicity is currently insufficient”, and “multiplicity may become insufficient in future” are considered. As a message given in the guide529, three patterns of “increase the multiplicity set value”, “scale-out”, and “scale-up” are considered.

Since a result of the influence analysis of the guarantee DB led to the fact that the multiplicity is currently sufficient but may become insufficient in future in the example ofFIG. 5, the fact is displayed on the analysis result explanation area527. A notification level “WARNING” is displayed in the uppermost row of the analysis result display area514. If the multiplicity is lack even in this stage, the notification level of “ERROR” appears; whereas, if the multiplicity is sufficient, then the notification level of “OK” appears.

As mentioned above, from the analysis result display area514, the user can compare the current and ideal value of the multiplicity set value, necessary multiplicity, and request generation rate of each element; and use it as reference information on the multiplicity design. This results in assisting the user in the design work of deriving an optimum parameter value. Further, the user can determine whether or not the derived parameter value is employed based on the trade-off between the cost of resource expansion and the performance security.

(6) Included in the multiplicity modify/change area531are a multiplicity modify button532to be clicked when the operator wants to execute the multiplicity modification process (Step203in FIG.2); a multiplicity change button533to be clicked when the operator wants to execute the multiplicity change process (Step205inFIG. 2); a radio button534for selecting one of “automatic”, “manual”, and “enforcement” as a method for executing the multiplicity modification process; and a radio button535for selecting one of “automatic” and “manual” as a method for executing the multiplicity change process.

When the operator selects “automatic” by the radio button534for multiplicity modifying method, this causes the actually necessary multiplicity518to be automatically input in the text area521. Thus the operator can save a labor of entering a modified value for the multiplicity for each element. Further, since a new server introduction cost is high or a system formation period is long in an actual situation, it is impossible in some cases to change the multiplicity of an element as a bottleneck to a value beyond the necessary multiplicity. In this case, by selecting “enforcement” by the radio button534of multiplicity modification method and entering a multiplicity set value smaller than the necessary multiplicity in the text area521, the element having the multiplicity set therefor can also be treated as an element not to be subjected to the influence analysis.

From the multiplicity modify/change area531, the operator/administrator of the monitored system can select the multiplicity modify or change method for each element, reduce his/her design work load, and dynamically redistribute server resources in real time. Further, he/she can determine whether or not to employ the derived parameter value based on the trade-off between the resource expansion cost and the performance security. In addition, he/she can manually determine the parameter value when failing to derive an optimum parameter value.

Shown inFIG. 6is the cooperation display area513(seeFIG. 5) after the bottleneck analysis process (Step202inFIG. 2) is carried out. More specifically,FIG. 6shows details of the cooperation display area513when the self-supporter guarantee instance423is a bottleneck in the bank system ofFIG. 4.

The cooperation display area513first displays a bank system cooperation view6701. On the bank system cooperation view6701, cooperation arrows extended from a financing system icon6705and a sales office system icon6707to a security & guarantee system icon6708are shown by thick lines, and the security & guarantee system icon6708is shown to be surrounded by a double line. This means that the security & guarantee system405is a bottleneck.

In order to examine one of elements in the security & guarantee system405forming a bottleneck, next, the operator selects the security & guarantee system icon6708(by double-clicking the mouse on it), this causes the current screen to be transited to a security & guarantee system cooperation display view6702. This view6702displays the cooperative relations between sub-systems of the bank system (the cooperation display area513inFIG. 5also showing relations between such sub-systems). Since the guarantee server icon6714is shown by a double line in the security & guarantee system, this means that the guarantee server414(FIG. 4) is a bottleneck.

Information included in a guarantee server icon601for the guarantee server icon6714refers to the fact that the original upper limit request generation rate is 250 (requests/sec), the original multiplicity set value is 13, the actual request generation rate is 320 (requests/sec), and the actual necessary multiplicity is 16 (the information also being shown in the bottleneck analysis result area515inFIG. 5). Since a relation of (original analysis result)<(actual necessary multiplicity) (i.e., 13<16) is satisfied in this example, the operator can see the fact that the guarantee server414fails to fully process all the requests. When a pop-up hint602is displayed for the state of the guarantee DB427, further, this means to satisfy a relation of (original multiplicity set value)>(actual necessary multiplicity) (or 17>13). From this, the operator can see the fact that the guarantee DB427can fully process the requests. When a pop-up hint603is displayed, this means that (original multiplicity set value)>(actual necessary multiplicity) (or 15>13). Thus the operator can see the fact that the guarantee DB427can fully process the requests. A difference between the two exemplary cases will be explained inFIG. 7.

When a parent element positioned at an upper layer level of the bottleneck element is displayed to be highlighted in this way, the present system can know a location where a problem (bottleneck) occurred from macroscopic viewpoint and this can assist the operator in his/her design work.

For the purpose of examining one of elements in the guarantee server414as a bottleneck, the operator selects the guarantee server icon6714(by double-clicking the mouse on it). This causes the cooperation display area513for a guarantee process415(FIG. 4) at a lower layer level of the guarantee server to appear (not shown inFIG. 6). Selection of the guarantee process415causes the view to be transited to a guarantee process view6703.

In the guarantee process view6703, cooperation arrows extended from both threads of a guarantee inquiry thread icon6715and a guarantee registration thread icon6717to a self-supporter guarantee instance icon6718are shown by thick lines, and the self-supporter guarantee instance icon6718is shown by a double line. This means that the self-supporter guarantee instance423(FIG. 4) is a bottleneck. Though not shown inFIG. 6, when the original multiplicity set value516of “5” and the actually necessary multiplicity518of “9” are shown as an example in the analysis result display area514(FIG. 5) of the self-supporter guarantee instance423, a relation of (original multiplicity set value516)<(actually necessary multiplicity518) is satisfied. From this, the operation can know the fact that the self-supporter guarantee instance423cannot fully process the requests.

From a message of “State: Bottleneck occurred” in a pop-up hint604, the operator can see the fact that the self-supporter guarantee instance423is an element which causes the bottleneck. From a message of “Guide: Increase the multiplicity” and a message of “Reason: CPU/memory both sufficient”, the operator can know the fact that he/she can get rid of the bottleneck with the load on the guarantee server414and the memory system cache being kept stable (in a range of critical multiplicity), by increasing the multiplicity set value of the self-supporter guarantee instance423.

In this way, since the bottleneck analysis result is displayed on the screen for easy understanding of the detailed state of the problem (bottleneck), this can advantageously assist the operator in his design work.

With respect to the memory system cache, it can be analyzed by a method similar to a flow of load analysis process of the server to be explained later inFIG. 17. Not only the CPU time or the memory system cache but also another parameter (the number of IO times or the like) having a model similar to these can also be analyzed by a method similar to the method shown inFIG. 17.

In order to examine one of elements in the self-supporter guarantee instance423forming a bottleneck, finally, the operator double-clicks the mouse on the self-supporter guarantee instance icon6718. This causes the view to be transited to a self-supporter guarantee instance cooperation display view6704. On the view display6704, a self-supporter registration AP icon6720is shown by a double line, which means that the self-supporter registration AP426(FIG. 4) is a bottleneck. However, a multiplicity cannot be set directly for an element of a business AP level. Accordingly, the bottleneck is gotten rid of, actually by adjusting the set multiplicity of the self-supporter guarantee instance423as the parent element of the self-supporter registration AP426.

As has been mentioned above, the system operator/administrator can see the analysis result by gradually breaking down the problem from macroscopic viewpoint to microscopic viewpoint; that is, by sequentially displaying the security & guarantee system cooperation display view6702, the guarantee process view6703, and the self-supporter guarantee instance cooperation display view6704sequentially from the bank system cooperation view6701as the cooperation display area513of the uppermost layer level, that is, by sequentially displaying system elements of lower layer levels and their states on the cooperation display area513(FIG. 5). For this reason, the operator can advantageously take a measure to secure the performance of the entire system efficiently from broad viewpoint and can reduce a frequency of try and error for system tuning based on multiplicity.

FIG. 7shows the cooperation display area513after the influence analysis process (Step204inFIG. 2) is carried out. InFIG. 7, explanation will then be made in detail as to how the respective cooperation display view (6701to6704) ofFIG. 6change, on the assumption that the multiplicity lack (view example inFIG. 6) of the self-supporter guarantee instance423which was known by the bottleneck analysis is solved by increasing the multiplicity set value, and that then, as a result of influence analysis, it becomes obvious that a multiplicity lack takes place in the guarantee DB427.

The guarantee process view6703, first of all, shows a state after “5” for the original multiplicity set value of the self-supporter guarantee instance423(the original multiplicity set value516having “5” and the actually necessary multiplicity518having “9” in the example ofFIG. 6) decided as a bottleneck inFIG. 6is modified to “10”, and then the influence analysis process (Step204inFIG. 2) is carried out. From this view, the operator can know the fact that the self-supporter guarantee instance423got ready for sufficiently processing the request, since “10” for the after-modification multiplicity set value521after the modification as well as “9” for the current necessary multiplicity523after recalculation are displayed on the influence analysis result area520, and since a relation of (multiplicity set value after modification)>(current necessary multiplicity after recalculation) is satisfied. The operator also can know the fact that the bottleneck caused by the self-supporter guarantee instance423was gotten rid of, from a message saying “state: bottleneck gotten rid of” in a pop-up hint704. The double line of the self-supporter guarantee instance icon6718disappears. Even on the self-supporter guarantee instance cooperation display view6704after the influence analysis process, the double line of the self-supporter registration AP icon6720indicating a bottleneck also disappears. Accordingly, the operator can know the fact that it can get ready for sufficiently processing the request.

When the influence analysis result is displayed on the screen in this way, the operator can easily understand the problem (bottleneck) solving state and thus this can assist the operator in his/her design work.

The security & guarantee system cooperation display view6702shows a state of the security & guarantee system after the influence analysis process is carried out on the guarantee process view6703. On the screen, the double line of the guarantee server icon6714indicating a bottleneck already disappears. From the pop-up hint701for the guarantee server icon6714, the operator can know the fact that the guarantee server414can sufficiently get ready for processing the request, since a relation of (multiplicity set value after modification)>(current necessary multiplicity after recalculation) (18>16) is satisfied.

The state of the guarantee DB427is divided into two cases as shown in pop-up hints702and703. In any case, the guarantee DB icon6721is surrounded by a double line, indicating the possibility of a new bottleneck. The pop-up hint702corresponds to the case of the pop-up hint602inFIG. 6, while the pop-up hint703corresponds to the case of the pop-up hint603inFIG. 6.

(1) In the case of the pop-up hint702, “17” for the original multiplicity set value516and “16” for the current necessary multiplicity523after recalculation are displayed on the analysis result display area514based on numeric values included in the pop-up hint701and the pop-up hint602, though not shown. Since a relation of (original multiplicity set value)>(current necessary multiplicity after recalculation) is now satisfied, the operator can know the fact that the guarantee DB427can get ready for sufficiently process the request for the time being. However, since “17” for the original multiplicity set value516and “18” for the future actual necessary multiplicity525after recalculation are displayed, the operator can see the fact that a relation of (original multiplicity set value)<(future actual necessary multiplicity after recalculation) is satisfied and thus the guarantee DB427may not be able to process the request in future.

The “Notification level: WARNING” in the pop-up hint702means that the request can now be process but may not be able to be processed in future. From a message “State: Future connection lack”, the operator can know the fact the guarantee DB427may become an element which causes a new bottleneck. From a message of “Guide: Increase the number of nodes for DB server” and a message of “Reason: Insufficient in CPU performance”, the operator can realize that if the number of nodes (the number of servers) for the guarantee DB427is not increased, then the bottleneck cannot be gotten rid of in future with the stable load on the guarantee DB427being kept (that is, in a range of critical multiplicity).

(2) In the case of the pop-up hint703, “15” for the original multiplicity set value and “16” for the current necessary multiplicity523after recalculation are displayed on the analysis result display area514of the guarantee DB427on the basis of numeric values included in the pop-up hint701and the pop-up hint603though not shown. A relation of (original multiplicity set value)<(current necessary multiplicity523after recalculation) is now satisfied. Therefore, the operator can know the fact that, when the multiplicity set value of the self-supporter guarantee instance423is increased for the state of multiplicity lack of the self-supporter guarantee instance423, the guarantee DB427will not able to process the request.

The “Notification level: ERROR” in the pop-up hint703means that increasing the multiplicity set value of the self-supporter guarantee instance423without any measure taken results in that the guarantee DB427will not be able to process the request. The “State: Connection lack!” means that the guarantee DB427may become an element which causes a new bottleneck. From the messages “Guide: Increase the number of nodes for DB server” and “Reason: Insufficient in CPU performance”, the operator can know the fact that the load on the guarantee DB427cannot be kept stable without increasing the number of nodes (the number of servers) for the guarantee DB427.

When influence analysis result is displayed on the display view in this way, the operator can get easy understanding of the detailed state of a newly generated problem (bottleneck) and this can assist the operator in his design work.

Finally, the bank system cooperation view6701shows the state of the bank system after influence analysis process. Since the security & guarantee system icon6708is now surrounded by the double line, the operator can know the still existence of the bottleneck. This is, as mentioned above, because it has been decided, through the influence analysis after the multiplicity modification of the self-supporter guarantee instance423, that the guarantee DB427may fail to fully process the request.

FIG. 8shows a system configuration of the monitored system107(more specifically, the bank system401), having the inter-system arrangement definition329and the sub-system internal arrangement definition316(both shown inFIG. 3).

The inter-system arrangement definition329includes a system arrangement definition801as a table for storing arrangement information about the system (bank system401inFIG. 4) and a sub-system relation802as a table showing a relation from the system arrangement definition801to a sub-system arrangement definition803(included in the sub-system internal arrangement definition316).

The sub-system internal arrangement definition316has 5 types of arrangement definition tables and 4 types of relation tables.

The 5 types of arrangement definition tables are (1) the sub-system arrangement definition803as a table for storing arrangement information about sub-systems (the financing system402, interest rates system403, sales office system404, and security & guarantee system405inFIG. 4); (2) a server arrangement definition805as a table for storing arrangement information about servers (the load balancer406, security Web407, security server408, guarantee DB409, guarantee Web411, guarantee server414, and guarantee DB427inFIG. 4); (3) a process arrangement definition807as a table for storing arrangement information about processes (the guarantee HTTP daemon412, guarantee process415, and guarantee DBMS428inFIG. 4); (4) a component arrangement definition809as a table for storing arrangement information about components (the guarantee inquiry thread416, guarantee registration thread419, employment income earner guarantee instance417, and self-supporter guarantee instance423inFIG. 4) (in which ‘component’ is a general term for the conception of an execution unit smaller than a process such as thread or instance); and (5) a business AP arrangement definition811as a table for storing arrangement information about business APs (the registration AP420, self-supporter inquiry AP424, and self-supporter registration AP426inFIG. 4).

The 4 types of relation tables are (1) a server relation804as a table showing a relation between the sub-system arrangement definition803and the server arrangement definition805; (2) a process relation806as a table showing a relation between the server arrangement definition805and the process arrangement definition807; (3) a component relation808as a table showing a relation between the process arrangement definition807and the component arrangement definition809; and (4) a business AP relation810as a table showing a relation between the component arrangement definition809and the business AP arrangement definition811.

For the guarantee process415(a children component having four of the guarantee inquiry thread416, guarantee registration thread419, employment income earner guarantee instance417, and self-supporter guarantee instance423inFIG. 4) as one of elements stored in the process arrangement definition807, for example, the component relation808from the process arrangement definition807to the component arrangement definition809will be explained in more detail. When component name (ID) is ‘guarantee inquiry thread416’, a cooperation originator component list is ‘guarantee HTTP daemon412’ and a cooperation destination component list is ‘employment income earner guarantee instance417’ and ‘guarantee registration thread419’. The ‘cooperation originator component’ as used therein means a component from which an arrow is directed to a component designated by a component name inFIG. 4; and the ‘cooperation destination component’ means a component to which an arrow is directed from a component designated by a component name inFIG. 4. When the cooperation originator has no definition information of component level, it has process information of upper layer level.

Information included in a multiplicity modifying method814, etc. stored in each arrangement definition table is referred to in the multiplicity modification process (Step203inFIG. 2). More specifically, in Step1801inFIG. 18to be explained later, the information is referred to as a multiplicity modifying method1804. Similarly, information included in a multiplicity modifying method815stored in each arrangement definition table is referred to in the multiplicity change process (Step205inFIG. 2). More specifically, the information is referred to as a multiplicity modifying method2306in Step2301inFIG. 24to be explained later. Accordingly, this can assist the operator/administrator of the monitored system in lightening his/her operation load and in his/her design work of deriving an optimum system arrangement and parameter values so as to realize compatibility between the performance security and the system running stability.

Further, since a link to an agent information908is established from the component arrangement definition809, the multiplicity adjustment agents110and112(FIG. 1) can be identified and server resources can be dynamically redistributed advantageously.

FIG. 9shows a data structure of details of history and definition information. The data structure includes a request path definition918for defining how a request goes through sub-systems; acquired measured-value transmission/reception definitions303and308for defining what request information of the request measurement modules302and307(FIG. 3) to be acquired (FIG. 3); and a multiplicity setting meta definition317for defining which item of the multiplicity definition311of its own element and the multiplicity definition311of its own element storing the multiplicity set value and a queue length set value corresponding to the multiplicity set value and the queue length set value.

The request path definition918includes 4 tables, that is, a request path identify definition901as a table for storing information for identification of a request path; a cooperation destination arrangement element information903as a table for storing information (such as order, frequency and divergence condition) when the request goes through a component; a request path performance information904as a table for storing performance information (critical multiplicity, average response, and critical CPU time of each server in the critical multiplicity) for each request path; and an element relation902as a relation table from the definition903to the definition904. In this case, as shown inFIG. 9, a link is provided from each table to each table in the sub-system internal arrangement definition316(FIG. 8). The word “critical CPU time” as used herein refers to a server CPU time for a critical multiplicity.

The cooperation destination arrangement element information903includes a cooperation order911and a cooperation condition912as attributes. Based on the attributes, the operator can know that the request for each request path goes through which component in what order and how many times. For a branch, further, the operator can know the branch takes place in what condition and frequency. In this way, this can assist the operator in his design work of deriving optimum parameter values. The request path performance information904has critical parameters (including critical memory system cache, and critical IO generation rate) such as a critical multiplicity1707, an average response1414and a critical CPU time1708as attributes. For the definition of such parameters and how to use these, refer toFIG. 17. Based on such parameters, the operator can see the request generation rate and derive parameter values optimum for the server load analysis process1304(FIG. 13) or the load analysis reexecution process1904(FIG. 19).

The acquired measured-value transmission/reception definitions303and308for acquisition of an actually measured value has three tables, that is, an actually measured value905as a definition table for designating information to identify the actually measured value obtained by one of the multiplicity adjustment agents110and112(FIG. 1); request information906as a definition table for designating information to identify a request path; and message information907as a definition table for designating information to uniquely identify the request information. The request measurement modules302and307, individual sub-system's measured-value collection module312, and measured value collection module322, shown inFIG. 3measure, collect, sort and merge actually measured values on the basis of information stored in the acquired measured-value transmission/reception definitions303and308.

As shown inFIG. 9, the actually measured value table905includes an agent name (ID)913for identifying one of the multiplicity adjustment agents110and112which measured the actually measured value. The request information table906includes a request path name (ID)914for identifying the request path of the request. The message information table907includes a transaction identifier (ID)915for linking a plurality of pieces of request information measured by a plurality of elements into a single piece of information, a time band916as an item for sorting information according to each acquisition time band, and a message type917as an item for discriminating between untransmitted, unprocessed, and processed. The above items can assist the operator in his/her design work of deriving optimum parameter values.

The multiplicity definition311includes two tables; that is, agent information908as a table for storing information about identification between the multiplicity adjustment agents110and112, and multiplicity information909as a table for storing information necessary for carrying out the simultaneous executable multiplicity control process and the load balance process. The multiplicity information table909includes information which is used when the multiplicity control modules301and305carry out the simultaneous executable multiplicity control process and the load balance process. Based on such information, the system can automatically redistribute server resource in real time while securing the server running stability.

Last, the multiplicity setting meta definition317is made up of two tables; that is, agent information908as a table for storing information for identification between the multiplicity adjustment agents110and112, and multiplicity set item information910as a table for storing information for identification between various set parameter items. The multiplicity change instruction module315(FIG. 3) instructs to change a multiplicity set value on the basis of information included in the multiplicity setting meta definition317(Step2305inFIG. 24to be explained later).

FIG. 10is a diagram for explaining a relation between a request generation rate and a system element. A necessary multiplicity1010for a request having a request path can be expressed in accordance with a calculation equation1009, (request generation rate1011)×(average response1012), shown inFIG. 10. The necessary multiplicity1010is a parameter controllable by an element, while the request generation rate1011and the average response1012are parameters measurable by an element. Accordingly, by measuring the request generation rate1011for each element and the average response1012therefor, the necessary multiplicity1010can be decided and the simultaneous executable multiplicity of each element can be controlled using the necessary multiplicity1010. The average response1012is an average stay-in time for a request in each element, which can be calculated by measuring a stay-in time in each element.

A request having a request path has such a path characteristic as shown inFIG. 10. That is, the request goes through the monitored system use terminal106(browser)→load balancer406→guarantee HTTP daemon412→guarantee inquiry thread416→guarantee registration thread419self-supporter inquiry AP424in the self-supporter guarantee instance423→self-supporter registration AP426in the instance423, in this order. And when the contents of a message of the request is normal and no error return occurs in the middle of the go-through path, the request generation rate1011has the same value even when measured at any of request measurement points1002to1005,1007and1008of each element inFIG. 10.

When as for the measurement point1006, the request goes through the same element (self-supporter guarantee instance423) twice in the first-time request process, a value corresponding to double of the request generation rate1011measured at another measurement point is the same as the request generation rate1011measured at the measurement point1006. Conversely, a value obtained by dividing the request generation rate1011measured at the measurement point1006by 2 is the same as the request generation rate1011measured at another measurement point. In this way, when the request goes through the same element a plurality of times in the first-time request process, the request generation rates of elements can be mutually converted by multiplying or dividing the request generation rate of the element by the go-through frequency of each element. In other words, the request generation rate1011can be converted to a parameter commonly usable to elements.

Accordingly, with respect to a request for which an error return occurred by the multiplicity control function of the multiplicity control modules301and305of the multiplicity adjustment agents110and112in the middle of the request path; the number of requests (i.e., the request generation rate1011) to be originally processed in each element when the request is assumed to have been normally processed without any error return, can be calculated. And from the calculated request generation rate1011and the average response1012, the necessary multiplicity1010for each element can be calculated using the calculation equation1009for necessary multiplicity.

When some transaction error in the middle of the request path causes a request to be returned or when there are a plurality of patterns of paths through which the request goes by a branch, an error return rate or a branch rate can be calculated from the past history or a previous estimated value to calculate a request generation rate in each element. For example, (request generation rate measured in an element having the request therein) becomes equal to (request generation rate measured in the request generation originator)×(rate at which the request goes through the element).

FIG. 11shows an example of how to efficiently derive a necessary multiplicity. InFIG. 11, the abscissa is a time axis ‘t’ and the ordinate is a necessary multiplicity axis.FIG. 11shows variations with time in a necessary multiplicity a(t)1103for the self-supporter inquiry AP424(FIG. 4) and in a necessary multiplicity b(t)1104for the self-supporter registration AP426(FIG. 4).

When no consideration is paid to time changes in the request generation rates of the inquiry AP424and the registration AP426, a necessary multiplicity1107as a sum of maximums1105and1106necessary for the respective business APs becomes a necessary multiplicity for the self-supporter guarantee instance423. However, a multiplicity as large as the necessary multiplicity1107is not necessary even at any time, as shown inFIG. 11. Thus the necessary multiplicity1107is not such a necessary multiplicity as to efficiently use system resources. For this reason, considering variations in the necessary multiplicities of the inquiry AP424and the registration AP426, a necessary multiplicity is varied with time for each time interval Δt. In other words, (maximum of a(t) for Δt)+(maximum of b(t) for the Δt) is used as a necessary multiplicity. When Δt is now taken as shown inFIG. 11, the necessary multiplicity of the self-supporter guarantee instance423becomes such a graph as shown by1110. When Δt→0, the necessary multiplicity becomes such a graph as shown by1109.

When a request generation rate for each time band is measured and the calculation equation1009for necessary multiplicity or a generation rate upon branch is calculated in this way, resources under a mixed business environment can be effectively used.

FIGS. 12 to 24show detailed processing flows of the measured-value collection process (Step201), bottleneck analysis process (Step202), multiplicity modification process (Step203), influence analysis process (Step204), and multiplicity change process (Step205) inFIG. 2. In description given in the following, “system element of lowest level” refers to thread, instance, load balancer, HTTP daemon or the like among elements inFIG. 3. Meanwhile, “system element of upper layer level” refers to a system element (more specifically, system, sub-system, web server, AP server, DB server, process or the like) which can indirectly perform the multiplicity control process or the load balance process by adding multiplicity set values or request generation rates of the system elements of lowest level. An element for transmitting a request directly to another element is referred to as “upper tier element”, whereas, an element for receiving a request directly from another element is referred to as “lower tier element”.

FIG. 12is a detailed flowchart of the measured-value collection process (Step201inFIG. 2). In respective steps inFIG. 12, the definition information and request information shown inFIG. 3will be appropriately referred to.

The transmission request measurement module302of the multiplicity adjustment agent110first acquires transmission side request information (Step1201). More in detail, the transmission request measurement module302, on the basis of the transmission definition303for an actually measured value to be acquired, acquires untransmitted request information, sorts the acquired information according to each time band/request path, and stores the sorted information in the untransmitted request information304for each time band/request path.

The reception request measurement module307of the multiplicity adjustment agent112then acquires reception side request information (Step1202). More in detail, the reception request measurement module307, on the basis of the reception definition308for an actually measured value to be acquired, acquires unprocessed request information, sorts the acquired information according to each time band/request path, and stores the sorted information in the unprocessed request information309according to each time band/request path. The reception request measurement module307, on the basis of the reception definition308for an actually measured value to be acquired, acquires processed request information, sorts the acquired information according to each time band/request path, and stores the sorted information in the processed request information310according to each time band/request path.

Steps1201and1202may be executed concurrently, or be executed at the same time or be executed in random order sequentially.

Next, the individual sub-system's measured-value collection module312of the individual sub-system's multiplicity adjustment server105collects an actually measured value for each sub-system (Step1203). More specifically, the individual sub-system's measured-value collection module312, on the basis of the sub-system internal arrangement definition316, collects the untransmitted request information304for each time band/request path and the unprocessed request information309for each time band/request path from the multiplicity adjustment agents110and112of each element, sorts the collected information according to each element, merges it, and stores such information in the unarrived request information313according to each element/time band/request path. The individual sub-system's measured-value collection module312, on the basis of the sub-system internal arrangement definition316, collects the processed request information310for each time band/request path from the multiplicity adjustment agent112of each element, sorts the collected information according to each element, and stores the sorted information in the processed request information314according to each element/time band/request path.

Finally, the measured value collection module322of the integrated multiplicity analysis server104collects actually measured values of the entire system (Step1204). More specifically, the measured value collection module322, on the basis of the sub-system internal arrangement definition group330and the inter-system arrangement definition329, collects the unarrived request information313for each element/time band/request path from the individual sub-system's multiplicity adjustment server105of each sub-system, and stores the collected information in the request information332according to each element/time band/request path in the integrated multiplicity analysis server104.

FIG. 13is a flowchart showing a summary of the bottleneck analysis process (Step202inFIG. 2). The bottleneck analysis process is carried out by the bottleneck analysis module321of the integrated multiplicity analysis server104(FIG. 3).

On the basis of request information of each element and its upper tier element, the bottleneck analysis module first calculates a necessary multiplicity for each element of lowest level and each time band (Step1301), details of which will be explained later inFIG. 14. On the basis of a multiplicity set value and the necessary multiplicity of the element of lowest level, the bottleneck analysis module calculates, according to each layer, a multiplicity set value and necessary multiplicity of each element of upper layer level and for each time band (Step1302), details of which will be explained later inFIG. 15. Next, the bottleneck analysis module compares the multiplicity set value and the necessary multiplicity and calculates a multiplicity lacking for each element and each time band (Step1303), details of which will be explained later inFIG. 16. The bottleneck analysis module next calculates a load state for each server/time band from the necessary multiplicity and a critical multiplicity, and analyzes a power lacking server and a power lacking time band (Step1304), details of which will be explained later inFIG. 17. From the sub-system internal arrangement definition group330, inter-system arrangement definition329, and bottleneck analysis result, the module creates bottleneck analysis result information for each layer/time band (Step1305). Finally, the module displays the bottleneck analysis result information on the terminal (Step1306).

FIG. 14shows a flowchart of details of Step1301(necessary multiplicity calculation process of an element of lowest level) inFIG. 13. In Step1301, the sub-system internal arrangement definition group330and the inter-system arrangement definition329(FIG.3) are used in subsequent sub-steps. InFIG. 14, Steps1401to1407are repeated by the number of time band (time divisions). That is, a time band is selected in Step1401, and it is decided whether or not there is another time bank (not selected) in Step1407(repetition decision). Steps1402to1406are repeated by the number of elements from an upper tier element toward a lower tier element. In other words, one of unprocessed elements having an upper (uppermost) layer is selected in Step1402, whereas, it is decided whether or not there is an unprocessed element in Step1406(repetition decision).

The bottleneck analysis module321first calculates an unarrived request generation rate from the upper tier (Step1403). More specifically, (1) the module identifies transmission destination element to be processed on the basis of unarrived request information1408(information stored in the request information database332in Step1204ofFIG. 12) of each upper tier element, and calculates the number of unprocessed requests for each request path. When the module fails to identify the transmission destination, calculates a distribution to each transmission destination element, and calculates the number of untransmitted requests for each request path as a weighting value from a predicted value or a past history. And the module calculates a request generation rate (untransmitted request generation rate) for each request path from the calculated request number and the generation time of each request. (2) Next, the module calculates a request generation rate (unprocessed request generation rate) for each request path from the calculated unprocessed request number and the generation time of each request. (3) The module calculates an unarrived request generation rate from the upper tier by summing the untransmitted request generation rate and the unprocessed request generation rate. And the module stores the calculated information in an unarrived request generation rate1412.

Next the module calculates a generation rate of a request processed in an element (Step1404). More specifically, the module calculates a generation rate of the request processed in the element on the basis of processed request information1409(information stored in the request information database332in Step1204ofFIG. 12) of the element to be calculated. And the module stores the calculated result in a processed request generation rate1413.

Finally, the module calculates a total requests generation rate for each request path of the element to be calculated a multiplicity necessary for processing it, from the request generation rates1412and1413calculated in Steps1403and1404and from the previously-measured average response1414(Step1405). More specifically, the module calculates a total requests generation rate for each request path by summing the request generation rates1412and1413. The module calculates a necessary multiplicity for each request path in accordance with the calculation equation1009ofFIG. 10, and sums necessary multiplicities for all request paths relating to the element to calculate a necessary multiplicity.

With it, the module can accurately find a necessary multiplicity for an element, can covert necessary multiplicities individually calculated in different request paths into a value (which can be used as a multiplicity set value) similar to a multiplicity set value as the parameter of an element. Thus this can assist the operator in his design work of deriving an optimum parameter value.

FIG. 15shows a flowchart of details of Step1302(process of calculating a multiplicity set value and a necessary multiplicity for a system element of upper layer level) inFIG. 13. In Step1302, the sub-system internal arrangement definition group330, inter-system arrangement definition329, inter-system arrangement definition329within a sub-system are used in subsequent sub-steps. Even in Step1302, similarly to Step1301inFIG. 14), Steps1501to1507are repeated by the number of time bands (time divisions); and Steps1503to1505are repeated by the number of elements from an upper tier element toward a lower tier element. Further, Steps1502to1506are repeated by the number of layers from an element of lower layer level toward an element of upper layer level. In other words, a layer of lower layer level (lowest layer level) in a time band is selected in Step1502; while it is decided whether or not there is an unprocessed layer in Step1506(repetition decision).

In Step1504, the bottleneck analysis module calculates a multiplicity set value, a necessary multiplicity, and a total requests generation rate. In Step1504, only ones of total requests generation rates1411, which are requests to a children element of an element (parent element) to be calculated and which are sent from outside of the parent element, are to be calculated. The bottleneck analysis module321sums multiplicity set values1509of the children elements included in the element to be calculated to calculate a multiplicity set value1508of the element in question, on the basis of the multiplicity set value1509(the necessary multiplicity1410of lowermost layer level found inFIG. 14) of the element, the average response1414previously measured, and the total requests generation rate1510(the total requests generation rate1411found inFIG. 14) of the children element. The module also sums all request generation rates for each request path of the children element to calculate the total requests generation rate1411of the element for each request path. The module further calculates the necessary multiplicity1410for each request path in accordance with the calculation equation1009shown inFIG. 10.

In Step1504, the multiplicity set value1508calculated for a layer is used as a multiplicity set value1509as input data of Step1504in an upper level layer. Similarly, the total requests generation rate1411calculated for a layer is used as the total requests generation rate1510of the children element as input data of Step1504in an upper level layer.

Through the process of Step1504, a request generation rate of an upper layer level necessary for the analysis result display area514can be derived, and a frequency of try and error for system tuning based on multiplicity can be reduced.

FIG. 16shows a flowchart of details of Step1303(process of calculating a lacking multiplicity) inFIG. 13. Even in Step1303, the sub-system internal arrangement definition group330and the inter-system arrangement definition329are used in subsequent sub-steps. Even in Step1303, similarly to Step1302inFIG. 15, Steps1601to1607are repeated by the number of time bands (time divisions), and Steps1602to1606are repeated by the number of layers from an element of lower layer level toward an element of upper layer level. Steps1603to1605are repeated by the number of elements from an element of upper tier toward an element of lower tier.

In Step1604, the multiplicity set value1508as an output result ofFIG. 15(Step1504) is compared with the necessary multiplicity1410. More in detail, the bottleneck analysis module decides to be normal when (necessary multiplicity)≦(multiplicity set value); whereas, the module decides that the presence of a bottleneck when (necessary multiplicity)>(multiplicity set value). And the module stores its comparison result as a multiplicity analysis result1608.

Through the process of Step1604, a necessary multiplicity of upper layer level necessary for the analysis result display area514can be derived and a frequency of try and error for system tuning based on multiplicity can be reduced advantageously.

FIG. 17shows a flowchart of details of Step1304(server load analysis process) inFIG. 13. Even in Step1304, the sub-system internal arrangement definition group330and the inter-system arrangement definition329are used in subsequent sub-steps. Even in Step1304, Steps1701to1706are repeated by the number of time bands (time divisions). Steps1702to1705are repeated by the number of servers (nodes). The module selects a server to be calculated in Step1702, whereas, the module decides whether or not there is another server not subjected to the load analysis process yet in Step1705(repetition decision).

The bottleneck analysis module first calculates a server load ratio (Step1703). More specifically, on the basis of the previously-measured critical multiplicity1707and critical CPU time1708for each request path and the necessary multiplicity1410(output result ofFIG. 15) for each request path corresponding to a server to be calculated, the module calculates a server load ratio for each request path in accordance with the critical CPU time1708(necessary multiplicity1410/critical multiplicity1707)×(critical CPU time1708), and sums calculation results for all request paths to calculate a load ratio1709of a server. And the module stores the calculation result as a server load ratio1709.

The server load ratio1709is compared (Step1704). More specifically, the module decides to be normal when (server load ratio)≦100%; whereas, the module decides the present of a bottleneck when (server load ratio)>100%. And the module stores the comparison result as a server load analysis result1710relating to multiplicity.

Through Step1304, information necessary for display of the state528, guide529and reason530in the analysis result display area514can be derived. This can assist the operator in his design work of an optimum system arrangement establishing compatibility between the performance security and the system running stability and deriving optimum parameter values. In Step1703(server load ratio analysis process), a relation between the multiplicity and the critical CPU time is used. However, the critical CPU time may be replaced by the memory system cache ((the use quantity of memory for the critical multiplicity) divided by (the full capacity of actual memory)), or by the critical IO rate ((a frequency of IO generation per unit time for the critical multiplicity) divided by (a frequency of IO issuance per unit time issuable when an IO-alone issuable program was executed for the critical multiplicity)). And when the analysis result is “bottleneck generation”; “memory addition”, “scale-out” or the like is displayed in the guide529.

Shown inFIG. 18is a flowchart of details of the multiplicity modification process (Step203inFIG. 2) to be carried out by the multiplicity modification module326.

The multiplicity modifying method first decides whether an element to be processed is modified manually or automatically (Step1801). More specifically, the module decides the above on the basis of the multiplicity modifying method1804(corresponding to the multiplicity modifying methods814,816, etc. shown inFIG. 8) for defining whether a multiplicity for each element is modified manually or automatically and a multiplicity modification application policy325(FIG. 3) for defining the range of a children element of the element to be automatically modified.

When the module decides the manual modification in Step1801, the module sets a multiplicity value1805entered from the terminal for a multiplicity set value of the element to be processed which is searched for based on the sub-system internal arrangement definition316and the inter-system arrangement definition329(Step1802).

When deciding the automatic modification in Step1801, the module sets the necessary multiplicity1410calculated in the bottleneck analysis process202or the influence analysis process204for the multiplicity set value1508of the processing element searched for based on the sub-system internal arrangement definition316and the inter-system arrangement definition329.

FIG. 19shows a flowchart of a summary of the influence analysis process (Step204inFIG. 2) to be carried out by the influence analysis module324.

The influence analysis module first recalculates a necessary multiplicity of lowest layer level (Step1901). In Step1901, the module recalculates a multiplicity for each other element of lowest layer level influenced by modifying the multiplicity of an element and for each time band. Details of the process of Step1901will be explained layer inFIGS. 20 to 22. Next, on the basis of the multiplicity set value of the element of lowest layer level and the necessary multiplicity recalculated in Step1901, the module recalculates a multiplicity set value and a necessary multiplicity for each element of upper layer level and for each time band (Step1902). The module then compares the multiplicity set value and necessary multiplicity recalculated in Step1901or Step1902to recalculate a multiplicity lacking for each element/time band (Step1903). On the basis of a critical multiplicity and the necessary multiplicity calculated in Step1902, the module calculates a load state for each server/time band to reanalyze power lacking server and time band (Step1904). On the basis of the sub-system internal arrangement definition group330, inter-system arrangement definition329, and the influence analysis result of Steps1901to1904, next, the module creates influence analysis result information for each layer/time band (Step1905). Finally, the module displays the influence analysis result information created in Step1905on the terminal (Step1906).

In the above process, Steps1902to1904are similar to Steps1302to1304of the bottleneck analysis process shown inFIG. 13, except that the multiplicity set value recalculated in Step1901and the necessary multiplicity are used as inputs. Steps1905and1906are similar to Steps1305and1306ofFIG. 13, except differences in items shown inFIG. 5(in particular, the influence analysis result area520). Accordingly, details of Step1902is shown inFIG. 15, details of Step1903is shown in Step1903, and details of Step1904is shown in Step1904.

FIG. 20shows a flowchart of details of Step1901(lowest layer level necessary multiplicity process) inFIG. 19. In Step1901, the sub-system internal arrangement definition group330and the inter-system arrangement definition329are used in subsequent sub-steps. In Step1901, similarly toFIG. 14, Steps2001to2007are repeated by the number of time bands (time divisions), and Steps2002to2006are repeated by the number of elements from an upper tier element toward lower tier element.

The influence analysis module first calculates an additional request generation rate taken into an upper tier (Step2003). More specifically, on the basis of the additional request generation rate2008(which will be explained later in Step2005) from each upper tier element, the module calculates, for request path, an additional request generation rate2012predicted to be additionally taken from the upper tier element into the element to be calculated; and stores the calculated result in a request generation rate323(FIG. 3) for each element/time band/request path. Details of the process of Step2003will be explained later inFIG. 21.

The module then recalculates a total request generation rate and a necessary multiplicity (Step2004). More specifically, on the basis of the unarrived request generation rate1412, processed request generation rate1413, and average response1414(any of which is similar to that used in Step1405ofFIG. 15); the module recalculates a total requests generation rate for each request path of the element to be calculated and a multiplicity necessary for processing all requests; and stores them in a total requests generation ratio2010after the recalculation and in a necessary multiplicity2009after the recalculation, respectively.

Next, the module calculates an additional request generation rate taken into a lower tier (Step2005). More specifically, on the basis of the total requests generation ratio2010after the calculation, recalculated in Step2004, the multiplicity327(necessary multiplicity modified by the multiplicity modification process ofFIG. 18) after the modification, the multiplicity set value1508, and the original total requests generation rate1411, the module calculates an additional request generation rate predicted to be additionally taken into a lower tier element by modifying the multiplicity set value of the calculation target element; and stores the calculated additional request generation rate as a lower tier additional request generation rate2011. And the lower tier additional request generation rate2011as the calculation result is used as the additional request generation rate2008from an upper tier in the process of Step2003for an element located at an lower tier of the target element.

Shown inFIGS. 21 and 22is how to calculate an additional request generation rate in Step2003(the process of calculating an additional request generation rate taken in from an upper tier element) ofFIG. 20.FIG. 21is when a multiplicity after modification fails to reach a necessary multiplicity; andFIG. 22is when the multiplicity after the modification exceeds the necessary multiplicity.

InFIG. 21, when an original total requests generation rate2104and an upper limit request generation rate2105calculated from a multiplicity set value have such a relation as shown in the drawing in State2101before multiplicity change of an upper tier; a difference between the above request generation rates becomes an unarrived request generation rate2103. In State2113after the multiplicity set value is changed, when an upper limit request generation rate2109is increased as shown, a difference from the original upper limit request generation rate2105becomes an additional request generation rate2107taken into a lower tier. A difference between an original total requests generation rate2108(=2104) and the upper limit request generation rate2109after the modification becomes an unarrived request generation rate2106after the recalculation.

Under such circumstances, if an original total requests generation rate2111of a lower tier has such a value as shown in the drawing, by changing the multiplicity of upper tier (State2113), the additional request generation rate2107becomes an additional request generation rate2110taken newly into the lower tier. When the multiplicity of an upper tier is further increased in future, the unarrived request generation rate2106after the recalculation of the upper tier may be taken into the lower tier. A sum of these request generation rates2107and2106is an additional request generation rate2112to be taken into the lower tier in future.

InFIG. 22, when an upper limit request generation rate2116calculated from the multiplicity set value has such a relation as shown in the drawing in State2102before change of the multiplicity of an upper tier, a difference therebetween becomes an unarrived request generation rate2114. In State2124after the change of the multiplicity set value, if an upper limit request generation rate2120is increased as shown in the drawing, a difference from the original upper limit request generation rate2116becomes an additional request generation rate2117taken into the lower tier. Further, since (original total requests generation rate2118(=2115))<(upper limit request generation rate2120), there is no unarrived request generation rate after recalculation (which point is different fromFIG. 21).

In such circumstances, when an original total requests generation rate2122of the lower tier has such a value as shown in the drawing, the additional request generation rate2117becomes an additional request generation rate2121newly taken into the lower tier by changing the multiplicity of the upper tier (State2124). When a request taken into the upper tier is increased in future, a difference2119between the upper limit request generation rate2120after the change of the upper tier (after the recalculation of the multiplicity) and the original total requests generation rate2118(=2115) may be additionally taken into the lower tier. Accordingly, a sum of the request generation rates2117and2119becomes an additional request generation rate2123possibly taken into the lower tier in future.

A “currently-estimated additional request generation rate” indicating a request generation rate newly taken in by changing the multiplicity of the upper tier or a “future estimated additional request generation rate” indicating a request generation rate possibly taken in in future by changing the multiplicity of the upper tier becomes “0” or minus in some cases. Such numeric value being “0” means “no generation of additional request”; whereas, such numeric value being minus means that “the request generation rate is decreased by an amount corresponding to a sum of the original total requests generation rate and the negative additional request generation rate”.

An example of how to calculate an additional request generation rate take into a lower tier for each request path after multiplicity modification in Step2005inFIG. 20will now be shown. It is assumed that an upper limit request generation rate Rka after multiplicity change for a request path ‘k’ is proportional to a ratio of total requests generation ratio for ‘k’ to total requests generation ratio. Or it can also be assumed that the upper limit request generation rate Rka is proportional to a ratio of processed total requests generation ratio for ‘k’ to processed total requests generation ratio, or to a ratio of unarrived total requests generation ratio for ‘k’ to unarrived total requests generation ratio. In other words, the upper limit request generation rate Rka after the multiplicity change for the request path ‘k’ is expressed as an equation,
Rka=α(Rkt/Rt)  (1)
Wherein α is a proportional constant (assuming to be common to all request paths), Rkt is total requests generation ratio for the request path ‘k’, and Rt is total requests generation ratio. Hence a multiplicity ‘mka’ for use in the request processing for the request path ‘k’ after the multiplicity change is expressed (by substituting Equation (1) into the calculation equation1009ofFIG. 10and Rka) as an equation,
mka=Rka·Tk=α(Rkt/Rt)Tk(2)
Wherein Tk is an average response for the request path ‘k’. When there are ‘n’ types of request paths, multiplicity (parameter to be actually set) Mta after total change is as follows.

Mta=mla+⋯+mna=∑k=1n⁢(mka)(3)
Substitution of Equation (2) into Equation (3) results in,

α=Mta/(∑k=1n⁢((Rkt/Rt)⁢Tk))(4)
Substitution of equation (4) into equation (1) results in,

Rke=Rka-Rkr=(Mta/(∑k=1n⁢(Rkt/Rt)⁢Tk))⁢(Rkt/Rt)-Rkr(5)
Wherein Rke is an additional request after multiplicity modification for the request path ‘k’, Rkr is a processed request generation rate (the request generation rate actually taken in before multiplicity change) for the request path ‘k’.

FIG. 23is a chart for explaining how an additional request generation rate calculated in Steps2003and2005inFIG. 20is transmitted to a lower tier element or an upper layer element. In the system arrangement inFIG. 23, similarly toFIG. 4, a DB server comprises a DBMS, a business AP is present in a thread and an instance, a process has a thread and an instant, and AP server has a process and an HTTP daemon, and a sub-system has a load balancer, an AP server and a DB server. And it is assumed that a request is transmitted through a system element of lowest layer level→load balancer→HTTP daemon→thread→instance→DBMS, in an order.

A flowchart2201show a manner that an additional request generation rate calculated for each element is transmitted to a lower tier. This corresponds to Step1901inFIG. 10and, for details thereof, refer toFIG. 20. Steps in the flowchart2201are processed by the influence analysis module (FIG. 3).

On the basis of an unarrived/processed request generation rate2203for an element in the upper tier of the load balancer, the influence analysis module first calculates a total requests generation ratio2205after recalculation of the load balancer an additional request generation rate2206to a lower tier (HTTP daemon) (Step2204). On the basis of the additional request generation rate2206from the load balancer and an unarrived/processed request generation rate2207in the load balancer, the module then calculates a total requests geration ratio2209after recalculation of the HTTP daemon and an additional request generation rate2210to a lower tier (thread) (Step2208). On the basis of the additional request generation rate2210from the HTTP daemon and an unarrived/processed request generation rate2211in the HTTP, next, the module calculates a total requests generation ratio2213after recalculation of the thread and an additional request generation rate2214to a lower tier (Step2212).

Subsequently, on the basis of the additional request generation rate2214from the thread and total requests generation ratio2215in the thread, the module calculates a total requests generation ratio2217after recalculation of an instance and an additional request generation rate2218to a lower tier (instance) (Step2216). Finally, on the basis of the additional request generation rate2218from the instance and an unarrived/processed request generation rate2219from the instance, the module calculates a total requests generation ratio2221after recalculation of a DBMS (Step2220).

In the flowchart2201, the unarrived/processed request generation rates2203,2207, etc. correspond to the unarrived request generation rate1412and the processed request generation rate1413inFIG. 20; the total requests generation ratios2205,2209, etc. after the recalculation correspond to the total requests generation ratio2010after the recalculation inFIG. 20; and the additional request generation rates2206,2210, etc. to a lower tier correspond to the lower tier additional request generation rate2011to a lower tier inFIG. 20.

A flowchart2202shows a manner that a total requests generation ratio for an element of upper layer level varies with recalculation. This corresponds to Step1902inFIG. 19and for details thereof, refer toFIG. 15. Respective steps in the flowchart2202are processed by the influence analysis module324(FIG. 3).

On the basis of the total requests generation ratio2221taken from outside the server into a DB server, the module first calculates a total requests generation ratio2223after recalculation of the DB server (Step2222). On the basis of the total requests generation ratio2213or2217taken from outside the business AP into the business AP, the module then calculates a total requests generation ratio2225after recalculation of the business AP (Step2224). In this connection, use of the total requests generation ratio2213means to calculate about the business AP in a thread; whereas, use of the total requests generation ratio2217means to calculate about the business AP in an instance.

On the basis of the total requests generation ratios2213and2217taken from outside of a process into the process, the module calculates a total requests generation ratio2227after recalculation of the process (Step2226). Subsequently, on the basis of the total requests generation ratio2209taken from outside a server into an AP server and the total requests generation ratio2227(calculated in Step2226), the module calculates a total requests generation ratio2229after recalculation of the AP server (Step2228). Finally, on the basis of the total requests generation ratio2205from outside of a sub-system into the sub-system and the total requests generation ratio2229(calculated in Step2228), the module calculates a total requests generation ratio2231after recalculation of the sub-system (Step2230).

FIG. 24shows a flowchart of details of Step205(multiplicity change process) inFIG. 2.

The multiplicity change module328first decides whether multiplicity change of an element to be changed is carried out manually or automatically (Step2301). More specifically, the multiplicity change module328decides the above on the basis of the multiplicity modifying method2306(corresponding to the multiplicity modifying methods815,817, etc. inFIG. 8) for defining the manual or automatic change of a multiplicity for each element and the multiplicity change application policy331(FIG. 3) for defining the range of the automatic change of a children element of the element.

When deciding the automatic change in Step2301, the multiplicity change module328change a multiplicity (Step2303). More specifically, the multiplicity change module328transmits information to instruct the multiplicity change to the multiplicity change instruction module315of the individual sub-system's multiplicity adjustment server105so that the multiplicity327after modification modified by the multiplicity modification process (Step203inFIG. 2) and the influence analysis process (Step204inFIG. 2) is changed to the multiplicity set value1508of the process target element searched for based on the sub-system internal arrangement definition316and the inter-system arrangement definition329.

The multiplicity change instruction module315when receiving the multiplicity change instruction information from the multiplicity change module328, instructs the target element to change a multiplicity set value (Step2305). More specifically, on the basis of the received multiplicity change instruction information, the sub-system internal arrangement definition316, and the multiplicity setting meta definition317; the module changes the multiplicity definition311for each element to instruct to reload the multiplicity definition311to the multiplicity adjustment agents110and112.

When deciding the manual change in Step2301, the multiplicity change module328accepts entry of the multiplicity after change from the monitored system operator/administrator, and transmits information relating to the change multiplicity to the multiplicity change instruction module315(Step2302). And the multiplicity change instruction module315performs the process of the above Step2305.

Through operations shown inFIG. 24, even in the case of any of the manual and automatic, definition information for setting multiplicities distributed to products can be managed at one location transversely, the need for the operator to troublesomely understand detailed specifications of the define files of individual products can be eliminated.

As an example of a method for calculating a necessary queue length when an input queue system is employed as a load balancing system, the reception multiplicity control module305(FIG. 3: multiplicity adjustment agent112) (1) integrates histories or sums the histories. Or the module (2) is considered to actually measure a queue length and find a necessary queue length from a standard deviation. The module (3) is considered to modelize the queue length according to an existing probability function, and find a necessary queue length from a normalized standard deviation. The module is considered to (4) first decide a probability and find it by certification, or find it by a similar method.

In accordance with Embodiment 1, by changing a multiplicity for a system element, the present system calculates how a request generation rate for another system element is changed and how this causes a necessary multiplicity (multiplicity necessary for processing all requests expected to be processed in the system element) to be changed, and its result is presented to the system user. Therefore, the user can advantageously examine the influence of a load or the like on the entire system caused by a newly added request path or by multiplicity change.

In a business using the Internet, in particular, it is common that, as a company grows and its service expands, the number of service users (customers) is increased. The need for design knowhow when the system increases a multiplicity according to a business scale in this way is high. Thus the present embodiment can advantageously offer a resolution to the need.

FIG. 25shows a system arrangement of an example when the present invention is applied to a grid computing. The word “grid computing” as used herein refers to a system wherein a plurality of computers are mutually connected by a network to form a virtual high-performance computer, a user can extract a necessary processing capability or memory capacity therefrom for use, and which can process a large amount of information at a high speed by causing the plurality of computers to perform parallel processing.

InFIG. 25, a grid scheduler2402is arranged to accept a request from a scientific and technological calculation request terminal2401, and relay the request to a plurality of calculation hosts2403, a calculation PC2404, and a calculation server2405in a server pool2406, while suitably balancing their loads. A multiplicity adjustment agent is provided to each of the calculation hosts2403, calculation PC2404and calculation server2405; and a function corresponding to an integrated multiplicity analysis server is provided to the grid scheduler2402. As a result, such a load balance process as to realize compatibility between the effective use of resource and the stable running of the server can be established. Other structure and processing are the same as those explained in Embodiment 1, except that a different target system is used.

As shown in the present embodiment, the present invention has an advantage that the invention can be applied even to the grid computing, and can offer a resolution to such system design as to increase the capacity (or multiplicity) of the system according to the business scale as in this example.