JP2003186707A - Performance evaluation method for distributed computer system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a low-cost method of performance evaluation for a distributed computer system, capable of evaluating remote call performance in the whole system with such high precision as required particularly in a real-time based system having limited system resources. <P>SOLUTION: An evaluation environment model having an information processing server (for measurement), a control server (for measurement) B, a control server (for load) C, an HMI server (for measurement) D, and an HMI server (for load) is constructed. Each one of CORBA objects (clients and servers) corresponding to the HMI servers 10, 20, 30 and the control servers 1 to 5 in a real system as an object of evaluation is placed in the HMI server (for measurement) D or the control server (for measurement) B of the evaluation environment model. Remote call performance only among the servers for measurement is measured, switching placement of each CORBA object. Performance measurement processing is repeated as many times as needed. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for evaluating the performance of a remote call between a client and a server in a distributed computer system. In particular, the present invention is a Common Object Request Broker Architecture (CORBA).
Evaluate the real-time performance of remote call between client and server in a distributed computer system that executes a service request between client and server via an object request broker (ORB: Object Request Broker) based on On how to do.

[0002]

CORBA is a technical standard that provides a mechanism for a client to access an object existing in a server in a distributed computing environment.
There are specifications. The CORBA specification is widely used as a means for easily realizing a remote call between a client and a server. Initially, the CORBA specifications were mainly conscious of application to enterprise-type (business processing type) client-server systems, but have been gradually expanded so as to widely support a wide range of applications.

As one of extended CORBA specifications, a real-time CORBA specification has been established. The real-time CORBA specifications are used for real-time applications that are becoming more distributed like business processing systems.
It is a standard for giving a request that sets the processing priority. In addition, the CORBA specification allows for the construction of various types of applications, and in addition to the "request / reply" type, which is a relatively simple communication method, there are many other types. The implementation method by the communication method is defined.

By appropriately selecting the communication system between the client and the server in accordance with the application, the communication model required by the application can be implemented straightforwardly. As a result, it is possible to eliminate programming restrictions, facilitate system construction using CORBA, and facilitate functional requirements.

By the way, in order to construct a desired system by using CORBA, an ORB product conforming to these specifications will be used. However, OR
The internal operation of the B product depends on the implementation of various ORB products.
Further, in the technical field, various ORB products are provided from software vendors in the form of middleware in which the internal operation is hidden to some extent. Therefore, CORBA
Therefore, it is difficult for a person who designs a system to have a clear guideline as to which method in the CORBA specifications that are defined in large numbers and which method should be combined. This is especially noticeable from the standpoint of constructing a system that requires real-time response time and delay time.

Under such circumstances, a system for remotely calling various request frequencies and data amounts has been developed.
When constructing using ORBA, build the system based on assumptions (in most cases, poor support), evaluate the performance after the entire system is almost completed, and go back to the process if the performance is insufficient. There is no choice but to take the approach of modifying the design. When such a situation occurs, there is a problem in that the burden on the work process and particularly the burden on the cost is very large.

Particularly, in a real-time system, a CP that can be used as compared with a business processing system.
U (Central Processing Unit) performance, memory capacity,
Or, there are large restrictions on system resources such as communication bandwidth.
Therefore, it is more difficult to obtain desired performance while appropriately allocating system resources by means such as setting the processing priority for a request. Therefore, it is more and more necessary to go back and work, and the above-mentioned defects become more serious.

On the other hand, if it is attempted to evaluate the performance of the entire system in advance in order to minimize the backtracking work, the work itself requires a great deal of labor and cost. as mentioned above,
In this technical field, there are various communication systems and combinations thereof, and there are various request frequencies, data amounts, and processing priorities. Therefore, if a user tries to implement an evaluation environment that suits the system to be built from scratch, the amount of work must be increased in proportion to the scale of the system, and the scale of required equipment is also large. This is because it is unavoidable.

FIG. 9 is a diagram showing a general configuration example of a real-time system. As shown in FIG. 9, in a real-time system, the relationship between computers is equal and the data flow is comparable, as compared with a business processing system in which the master-slave relationship between the computers that make up the system is relatively clear. More complicated. This is a factor that further increases the amount of work when performing performance pre-estimation. To evaluate a real-time system, U
It is necessary to use highly specialized equipment such as a built-in CPU board and real-time OS, instead of highly versatile equipment such as a NIX (registered trademark) server or PC server. For this reason, the required equipment cost also increases.

In order to avoid such a problem, there are the following methods (1) and (2) as conventional methods used when performing the preliminary evaluation. (1) A benchmark test is conducted under limited conditions in which the communication method, request frequency, and data amount are changed. Then, based on the response time and delay time obtained as a result, the performance of the entire system is accumulated and estimated, and the result is evaluated. (2) A modeling and simulation method is used to create a communication model of the entire system, perform simulation, measure data such as response time and delay time, and evaluate the performance of the entire system.

However, these methods have the following problems. In the method (1), it is difficult to estimate the worst value because dynamic behavior (change) such as request timing cannot be reproduced. Further, as shown in FIG. 9, there are cases where a plurality of remote calls are simultaneously made between a plurality of constituent devices, and these influence each other in processing and communication. However, with the method (1), it is difficult to reproduce the operation of the entire system.

On the other hand, in the method (2), it is difficult to take into account processing by an ORB product whose internal operation is provided in the form of middleware in which the internal operation is hidden to some extent and communication overhead. Further, in both the methods (1) and (2), it is difficult to estimate / measure the reflection of the processing priority.

For this reason, in the conventional method, particularly in the case of evaluating the performance of the dynamic remote call for the entire system in advance in consideration of the overhead added by the middleware and the priority of processing, It is considered that the required accuracy cannot be obtained in many cases. For this reason,
It is difficult to minimize the backtracking of the work process, which is the purpose of evaluation. Further, if the system is evaluated and the feasibility is judged based on the result obtained by the conventional evaluation method, it is inevitable to evaluate the system including a large margin.

Further, when constructing a system having a limited system resource and requiring real-time response time and delay time, it is necessary to measure and evaluate with higher accuracy. In such a case, the above problem becomes more remarkable.

[0015]

[Problems to be Solved by the Invention] As described above,
In the conventional distributed computer system, the lack of performance is often found only after the entire system to be constructed is almost completed, so that it is often necessary to backtrack the work process. For this reason, there is a problem that the burden on the work process and especially the burden on the cost are very large.

In particular, it is difficult to obtain the required accuracy in order to evaluate the performance of remote call in a real-time system with limited system resources over the entire system.

The present invention has been made under the above circumstances.
The purpose is to provide a performance evaluation method for a distributed computer system that can evaluate the remote call performance of the entire system with the high accuracy that is particularly required for a real-time system with limited system resources at low cost. To do.

[0018]

In order to achieve the above object, the present invention is a performance evaluation method for evaluating the performance of a remote call executed between each server of a distributed computer system comprising a plurality of servers. Therefore, an evaluation modeling the configuration of the distributed computer system including a plurality of measurement server models for measuring the performance of the remote call, and a load server model that behaves as a load for the measurement server models. Build an environmental model,
A distributed object component corresponding to each of the plurality of servers is generated, a distributed object component corresponding to the server is arranged in the measurement server model in the evaluation environment model, and distributed object components corresponding to the remaining servers are arranged. The first step of arranging the load server model, the second step of measuring the performance of the remote call between the measurement server models in the evaluation environment model, and the arrangement state of the distributed object parts in the evaluation environment model are performed. And a third step of switching.

By taking such means, object parts corresponding to a plurality of servers belonging to the distributed computer system are generated in the first step. These object components are arranged in either the measurement server model or the load server model provided in the evaluation environment model that models the configuration of the distributed computer system. Then, only the performance of the remote call between the measurement server models is measured in the second step. Then, the arrangement state of the distributed object parts in the evaluation environment model is switched in the third step, and the performance of the remote call in this state is measured again in the second step.

Therefore, it is possible to measure the performance of the remote call in the entire system by using the evaluation environment model that models the actual system without constructing the evaluation environment that imitates the actual system. From this, the performance of remote call in the entire system is
It becomes possible to provide at a low cost a performance evaluation method for a distributed computer system that can be evaluated with high accuracy, which is particularly required in a real-time system having system resource restrictions.

[0021]

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a diagram showing a configuration example of a distributed computer system which is a target of a performance evaluation method according to an embodiment of the present invention. This system includes a plurality of control servers 1 to 5 and a plurality of HMIs (Human Machine Interfaces).
ace) servers 10 to 30 and one information processing server 100. Then, for example, a LAN (Local Area N)
Each server makes a remote call to each other via a communication network (not shown) such as etwork). In FIG. 1, remote calling is not performed between all the servers. For example, remote calling is not performed between the HMI server 10 and the control server 3. As described above, the section in which the remote call is performed is appropriately set according to the specifications of the system.

FIG. 2 shows the CO of each component shown in FIG.
It is a matrix diagram which shows the presence or absence of the remote call which can be set between RBA objects (client and server), and its direction. A remote call in the designated direction is set to the component device indicated by a circle in FIG. In FIG. 2, for example, circles are marked at two places where the HMI server 20 and the control server 3 intersect, and the HMI server 20 is provided between these servers.
Indicates that a remote call is set in which the client is the client and the control server 3 is the server, and a remote call in which the control server 3 is the client and the HMI server 20 is the server is set. On the contrary, in FIG. 2, there is no circle mark in the cell where the HMI server 20 and the control server 4 intersect, and remote call is not set between these servers. These things also correspond to FIG. That is, the part marked with a circle in FIG. 2 changes depending on the system specifications.

As described above, the constituent devices of the system affect each other in processing and communication by remote calling. Therefore, reproducing the operation of the entire system is one of the important points in order to accurately measure the performance of the entire system.

However, when the scale of the system to be evaluated becomes large, it is unrealistic to prepare an evaluation environment having the same configuration as that of the system to perform the preliminary evaluation, particularly in terms of equipment cost. Therefore, in this embodiment, an evaluation environment model as shown in FIG. 3 is used.

FIG. 3 is a diagram showing a configuration example of an evaluation environment model corresponding to the system shown in FIG. In the model shown in FIG. 3, one information processing server (reference numeral A) is provided as in the case of FIG.

On the other hand, in the model shown in FIG. 3, two control servers and two HMI servers are provided. One of the two control servers and the two HMI servers is set for measurement, and the other is set for load. The control server (for measurement) is indicated by adding the symbol B. The control server (for load) is indicated by the reference character C. The HMI server (for measurement) is shown with reference numeral D. The HMI server (for load) is shown with the reference symbol E.

FIG. 4 is a block diagram showing a more specific structure of the system shown in FIG. In FIG.
Information processing server 100, control servers B and C, and HM
The I servers D and E are built on a real-time ORB / real-time OS (Operating System).

In FIG. 4, the information processing server 100 is
A user interface unit 11 and a measurement operation control unit 12 are provided. User interface unit 11
Notifies the measurement operation control unit 12 of a request given by an operator, such as a request to start a CORBA object to be evaluated or a request to start a measurement operation, and specifies an operation according to the request. The user interface unit 11 includes a human-machine interface such as a monitor that displays various windows, a keyboard, a mouse (all not shown), and the above request is input through the human-machine interface.

The information processing server 100 also includes a time synchronization unit 14. The control servers B and C and the HMI servers D and E include a time synchronization unit 22. Time synchronization unit 14,
22 cooperates with each other based on a predetermined protocol such as NTP (Network Time Protocol) or other means, and makes the information processing server 100 and the control servers B and C and the HMI servers D and E the system. It is synchronized with a given reference time (hereinafter referred to as system time).

Further, the information processing server 100 includes a measurement status monitoring unit 15. The measurement status monitoring unit 15 monitors the status of CPU load, memory load, or communication load.

When activating the CORBA object to be evaluated by the measurement operation control unit 12 of FIG. 4 or starting the measurement operation, the parameters for defining the system to be evaluated (hereinafter referred to as evaluation parameters) are set. Will be needed. The evaluation parameter 13 is given to the system by loading an electronic file prepared in advance or by an input operation using a monitor window.

FIG. 5 is a schematic diagram showing the structure of the evaluation parameter 13. The evaluation parameter 13 includes a task definition section in which unique parameters are defined for each remote call, and an overall configuration definition section in which parameters related to the entire system are defined. Of these, the task definition part contains the CORBA object (server) to be evaluated shown in FIG.
The behavior content is defined for a pair of CORBA object and client (client). In the task definition section, an arbitrary number corresponding to the number of object instances required for the evaluation purpose can be defined.

In FIG. 5, the task definition section includes (task number), (server name), (client name),
(Operating device identifier), (CORBA communication method), (CORBA priority), (cycle / event category), (cycle),
Items such as (event timing), (data length), (whether or not time measurement is performed), and (whether or not a user-defined transmission / reception unit is used) are defined.

In (task number), a unique integer given to a pair of CORBA object (server) and CORBA object (client) is defined.
A unique name given to each of the CORBA object (server) and the CORBA object (client) belonging to the pair defined by the task number is defined in (server name) and (client name). The name defined here is convenient for referring to the measurement result, and it is also used for CORBA object (client) to COR.
CORBA to get a reference to the BA object (server)
It is used as a name given to a naming service generally used in system construction. Note that the naming service is not indispensable, as there is a method of acquiring an object reference by another communication means,
Not shown in FIG.

The (operating device identifier) defines on which device each of the CORBA object (client) and the CORBA object (server) operates. That is, it is defined whether the CORBA object (client) or the CORBA object (server) runs on the information processing server 100, the control servers B and C, or the HMI servers D and E. (CORB
A communication method) defines which communication method of CORBA is used. In the present embodiment, as the CORBA communication method, <request reply type>, <one way request type>, <asynchronous method call type>, or
Any one of <event service type> is selectively designated.

In (CORBA priority), the priority of the CORBA request is defined. (Cycle / event classification)
Defines whether the CORBA request is made periodically or as an event. In (cycle), the calling frequency of a periodic request executed from the CORBA object (client) to the CORBA object (server) is defined. The call interval is given in milliseconds, for example. In (data length), the data length of the request argument is defined.

In (event timing), an amount representing an event-like request invocation timing executed from a CORBA object (client) to a CORBA object (server) is defined. As one method of generating event-like timing, there is a method of realizing it as a cycle including variations. To use this method, the basic call interval and its variation are given in units of milliseconds, for example. Instead of including (event timing) in the task definition part, the basic call interval may be specified as (cycle), and the variation may be a fixed amount with respect to (cycle).

In (whether to measure time), a CORBA object that measures time and a CORBA object that does not measure time are defined. In a real-time type application, when time measurement is simultaneously performed on a large number of objects (tasks), the error due to the measurement operation is generally large. Therefore, as in the present embodiment, when more accurate measurement is required by separately defining a task that measures time and a task that does not measure time,
Alternatively, the task can be configured according to the purpose of the evaluation, such as when the load of the system to be evaluated is to be easily measured. Further, it is also possible to use a task whose execution time is not measured, for example, as a load on the evaluation environment.

(Whether or not the user-defined transmitting / receiving unit is used)
It is defined whether or not to use the transmission / reception unit additionally defined on the user (that is, user) side. In this way, by making it possible to incorporate the transmission / reception unit additionally defined on the user side as necessary, the system to be evaluated, such as the detailed definition of request arguments and the addition of processing contents for giving a load to the CPU. Can be defined more strictly by the user, and an evaluation closer to the actual operating state of the evaluation target system can be performed.

In FIG. 5, (measurement time) and (real-time POA policy definition) are included in the overall configuration definition section.
Is defined. For (measurement time), each CORBA object (client) described in the task definition section
Defines the time at which the request will be fulfilled. Ie each
CORBA object (client) is (measurement time /
Remote calls are performed with the CORBA object (server) for the number of times calculated in (cycle). The value defined in (measurement time) is input by the operator at the start of the measurement operation.

(Real-time POA policy definition) In the real-time CORBA specifications, as a method of giving a priority to a request, a server-declared model in which the priority is fixedly defined on the server side and a priority is given to the request from the client side. You are supposed to choose one of the client-propagated models to wear. This selection is defined as a real-time CORBA specification that is defined by specifying a policy in a predetermined procedure at the time of construction of an element object that constitutes a CORBA object (server) called POA (Portable Object Adapter). POA policy definition) specifies this.

In FIG. 4, first, the information processing server 10
At 0, the measurement operation control unit 12 is activated, and at the control servers B, C and HMI servers D, E, the control server activation unit 21 is activated. The measurement operation control unit 12 activates the CORBA object to be evaluated according to the designation of the evaluation parameter 13 by the activation instruction given from the user interface unit 11.
In addition, the measurement operation control unit 12 includes the control servers B,
The control server activation unit 21 of the C, HMI servers D, E is instructed to activate the object defined by the evaluation parameter 13.

When confirming the completion of the activation of all CORBA objects (client and server), the system operator issues a measurement start instruction to the measurement operation control unit 12 via the user interface unit 11. As a result, all the clients of each CORBA object are requested to start measurement.

Then, the measurement process is started. In the measurement processing, the CORBA request is called during the measurement time given by the overall configuration definition part of the evaluation parameter 13, and the CORBA object specified as having time measurement in the task definition part of the evaluation parameter 13 (hereinafter referred to as the measurement target). CORBA
The response time of the request, the delay time, and the jitter time are repeatedly measured for the object).

The measurement result is obtained by the measurement operation control unit 12
Returned to. In this embodiment, the measurement operation control unit 12 is configured as a CORBA object (server). As a result, not only the CORBA object to be measured on the main system but also all control servers B, C, HM
It is possible to obtain the measurement result from the CORBA object to be measured on the I servers D and E. Finally, the measurement result is returned to the user interface section 11 to inform the operator.

Next, a procedure for measuring the performance of the entire system using the evaluation environment shown in FIG. 3 will be described. FIG. 6 is a flowchart showing an example of the measurement procedure in this embodiment. The procedure shown in FIG. 6 does not depend on the system configuration shown in FIGS. 1 to 4, for example.

In step S1 of FIG. 6, first, as shown in FIG.
A CORBA object is placed in each server of. Here, the COR associated with the information processing server 100
BA objects (client and server) are arranged in the information processing server (for measurement) A.

CORBA objects (client and server) associated with the HMI server 10
Are placed on the HMI server (for measurement) D. further,
CORBA objects (client and server) associated with the control server 1 are arranged in the control server (for measurement) B.

Furthermore, the COR corresponding to each of the remaining servers
The BA object is arranged in the HMI server (for load) E or the control server (for load) C, respectively. That is, in step S1, C corresponding to the control servers 2 to 5 is used.
The ORBA object is placed on the control server (for load) C. In addition, the CO corresponding to the HMI server 20, 30
The RBA object is placed on the HMI server (for load) E. The arrangement of the CORBA objects is defined by the (operating device identifier) of the evaluation parameter shown in FIG.

At the next step S2, the entire system is operated in the object arrangement state at step S1.
Information processing server (for measurement) A, HMI server (for measurement)
Only the performance of the remote call made between D and the control server (for measurement) B is measured. Whether or not to perform the measurement is defined by setting the item (whether or not to perform time measurement) of the evaluation parameters in FIG.

Then, in the next step S3, it is determined whether or not there is any measurement that has not been performed. If Yes (the next measurement is present) in this step, the CORBA object arranged in each server is switched by changing the evaluation parameter in FIG. 5 in the next step S4, and then the processing procedure returns to step S2. Then, the performance of the remote call under the following object placement is measured.

FIG. 7 is a correspondence diagram showing which server in FIG. 3 the CORBA objects (client and server) associated with each server shown in FIG. 1 are arranged. In the present embodiment, while arranging the arrangement of CORBA objects (client and server), the measurement for evaluating the performance of remote invocation is performed multiple times. Each measurement is given a measurement number of. When all the measurements of are completed, all the remote calls between the servers shown in FIGS. 1 and 2 will be measured.

FIG. 8 is a diagram showing CORBA objects (client and server) to be measured in the object arrangement shown in FIG. When all the measurements by the combination of FIG. 7 are completed, as shown in FIG.
The performance measurements for all remote calls in Figure 2 have been completed,
As a result, it becomes possible to evaluate the performance of the entire system.

As described above, in the present embodiment, the information processing server 100, the HMI servers 10, 20, 30 and the control servers 1 to 5 are individually arranged in the measurement server in any of the measurements 1 to 5, and their CORBA is set. The objects (client and server) will all operate including the exchange of requests with the CORBA objects located in the load server. Therefore, the operating state of the CORBA objects (client and server) of these constituent devices in the evaluation environment can be considered to be almost the same as the operating state of the system to be evaluated. Similarly, the load on the computer can be considered to be almost the same as the operating state of the system under evaluation.

On the other hand, the CO installed in the load server
Since the RBA object uses a single computer (server) to operate for a plurality of devices, it obviously differs from the operating state in the system to be evaluated, and naturally the load on the computer also increases.

Here, the real-time performance such as the response time and the delay time of the remote call is determined by the sum of the performances of the CORBA object on the client side and the server side. Therefore, the remote call made between the measurement servers accurately reproduces the performance in the system under evaluation, but the remote call made between the measurement server and the load server is performed in the system under evaluation. Will not be reproduced correctly.

Therefore, in the measurement of FIG. 7, the performance of the remote call (shown in FIG. 8) among the information processing server 100, the HMI server 10 and the control server 1 can be measured with higher accuracy. it can.

In the subsequent processing, even if only the evaluation parameters are changed, the information processing server (for measurement), the HMI
CO to be placed on the server (measurement server and load server) and control server (measurement server and load server)
The performance of the entire system can be measured by repeatedly measuring the performance of the remote call between the measurement servers while switching the RBA objects sequentially as shown in FIG.

By the above method, it is possible to measure the performance of the entire system to be evaluated with higher accuracy by using an evaluation environment with a smaller configuration.

In the above embodiment, the evaluation environment has three measurement server computers and two load server computers, but the number of measurements increases and the load server load increases. If you consider the two measurement servers,
It is also possible to perform measurement with the minimum configuration in which one load server is used. On the contrary, it is also possible to perform measurement with a configuration in which the number of computers for the measurement server and the load server is increased. Furthermore, although the system to be evaluated has a relatively simple configuration in the above-described embodiment, the present invention can be applied to a system having various configurations such as a larger-scale and more complex system.

[0061]

As described above in detail, according to the present invention, it is possible to evaluate the remote call performance in the entire system with a high degree of accuracy, which is particularly required in a real-time system having a limited system resource. A performance evaluation method for a personal computer system can be provided at low cost.

[Brief description of drawings]

FIG. 1 is a diagram showing a configuration example of a distributed computer system which is a target of a performance evaluation method according to an embodiment of the present invention.

FIG. 2 is a matrix diagram showing the presence / absence of a remote call that can be set between CORBA objects (client and server) of each component shown in FIG. 1 and its direction.

FIG. 3 is a diagram showing a configuration example of an evaluation environment model corresponding to the system shown in FIG.

FIG. 4 is a block diagram showing a more specific configuration of the system shown in FIG.

5 is a schematic diagram showing the configuration of the evaluation parameter 13 shown in FIG.

FIG. 6 is a flowchart showing an example of a measurement procedure according to the embodiment of the present invention.

FIG. 7 is a C associated with each server shown in FIG.
ORBA object (client and server)
FIG. 4 is a correspondence diagram showing which server of FIG.

8 is a diagram showing a CORBA object (client and server) to be measured in the object arrangement shown in FIG.

FIG. 9 is a diagram showing a general configuration example of a real-time system.

[Explanation of symbols]

A: Information processing server (for measurement) B ... Control server (for measurement) C ... Control server (for load) D ... HMI server (for measurement) E ... HMI server (for load) 1 to 5 ... Control server 10, 20, 30 ... HMI server 100 ... Information processing server 11 ... User interface section 12 ... Measurement operation control unit 13 ... Evaluation parameter 14, 22 ... Time synchronization unit 15 ... Measurement status monitoring unit 21 ... Control server starting unit 22 ... Time synchronization unit

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Koichi Shimohara             1st Komukai Toshiba-cho, Sachi-ku, Kawasaki-shi, Kanagawa             Ceremony Company Toshiba Komukai Factory F-term (reference) 5B042 GA08 GA12 HH20                 5B045 BB28 BB42 GG01                 5B098 AA10 GA04 GC01 JJ05

Claims (2)

[Claims] 1. A performance evaluation method for evaluating the performance of a remote call carried out between the servers in a distributed computer system comprising a plurality of servers, wherein a plurality of performance evaluation methods for measuring the performance of the remote call are provided. A measurement server model and a load server model that behaves as a load for this measurement server model are provided to build an evaluation environment model that models the configuration of the distributed computer system, and is associated with each of the plurality of servers. A first step of generating a distributed object component, arranging a distributed object component corresponding to the server in the measurement server model in the evaluation environment model, and arranging a distributed object component corresponding to the remaining servers in the load server model; Between the step and the measurement server model in the evaluation environment model The second step and the performance evaluation method of a distributed computer system, characterized by comprising a third step of switching the arrangement of the distributed object components in the evaluation environment model which takes measure the performance of remote calls. 2. The second step is a step of measuring remote call performance between the measurement server models based on a plurality of communication methods applied to remote call in the distributed computer system. The performance evaluation method for a distributed computer system according to claim 1.