Modeling and Simulation Analysis of the Performance of Application-Level Communication between Distributed Objects

Transcription

1 Modeling and Simulation Analysis of the Performance of -Level Communication between Distributed Objects Hiroshi Yamada Abstract--Almost all business es among enterprise activities use information technology (IT) systems. These days several s are integrated to implement more useful services. In addition, IT systems and networks are becoming larger and more complex in order to satisfy severe business requirements. The performance of a business is largely dependent on the IT system performance. Therefore, the performance design and management of the IT system are becoming more important issues. They must be viewed from an perspective, and transactions need to be tracked end-to-end through the entire infrastructure including client nodes, protocols, network configurations, architectures, and other components. In this paper, I introduce the performance design approach concept called ITAP (IT System Architecture Planning) approach by integrating and leveraging Business Process Modeling, Traffic Profiling, and Network Simulation, Benchmarking. As a case study, I evaluated the performance of three -level communication protocols: fan-out, pipeline, and ordered synchronous request/response communication protocols, using the ITAP approach. Given the activity diagrams that represent the ways for the initiating running on the broker to receive the sub services running on the remote s, I developed simulation modules that represent the dynamics of these -level communication protocols and performed simulation experiments. Index Terms --Communication management, Communication protocols, Information Technology, Simulation. A I. INTRODUCTION LMOST all business es in enterprise activities uses Information technology (IT) systems. These days several s are integrated to implement more useful services. This is called EAI (Enterprise Integration). In addition, the IT system and network are becoming larger and more complex in order to satisfy severe business requirements. The s running on IT systems are also becoming more complex and have a multi-tier structure to enable the distributed computing. For example, most web s have a complex multi-tier architecture and are ed in several computers. A client PC sends a request message to a web, which acts as a message broker. This web Hiroshi Yamada is with Nippon Telegraph and Telephone (NTT) Service Integration laboratories, 9-11, Midori-Cho 3-Chome Musashino-Shi Tokyo Japan (telephone: , yamada.hiroshi@lab.ntt.co.jp). ICITA2002 ISBN: analyzes the request message and invokes a suitable. The invoked may update data in a remote database, or send a remote procedure call (RPC) to receive services in the remote s. Finally, the web sends the response messages to the client, and the client receives them. When an involves accessing multiple es running on different s in the network, those es must communicate with each other. There are many types of communication between es running in different computers, depending on the content and purpose of the information that is exchanged in the business. Therefore, the performance of the business is largely dependent on the IT system performance. The performance design and management of the IT system are becoming more important issues. They must be viewed from an perspective, and transactions need to be tracked end-to-end through the entire infrastructure including client nodes, protocols, network configurations, architectures, and other components. As mentioned above, the architecture has become more complex. So, organizations, e.g., network service providers and network managers in companies, need to optimize the performance of s before implementing them. When we consider the performance of an that operates in a distributed computing environment, many issues arise that do not exist when all the data is stored and ed by a single central computer. In this case, the performance of an is affected by several factors, e.g., network resources, the or speed of each computer, middleware, traffic volume, and the communication path between objects. IT system managers must design the performance well and manage the and network performance, e.g., the response time, throughput, the number of committed transactions and so on in order to satisfy the business requirements. In this paper, first, I introduce the performance design approach concept called ITAP (IT System Architecture Planning) [1]. Next, I evaluate the performance of the -level communication protocol using this approach as a case study. In this paper, we consider the following situation. The service integrates several sub services running on the remote computers (Fig.1). All requests from the clients are received at a broker. This invokes the to receive suitable sub services. The invoked sends request messages to multiple remote s and database s, which may exist in a high-speed LAN or remote LAN connected by a slow WAN line. That is, this broker acts as a request broker.

2 To integrate the sub services, we consider the following three communication methods to connect these sub services as the -level communication protocol: Fan out parallelism, pipeline parallelism, and ordered. Their performances are evaluated and compared through simulation experiments. This paper is organized as follows. Section 2 introduces the ITAP approach and section 3 summarizes the -level protocol. Section 4 briefly explains the simulation modeling. Section 5 presents the simulation results. Section 6 summarizes the main points and mentions topics for further study. Client -level communication Invokes to receive a suitable service 1 N Figure 1 Multi-tier architecture using request broker. II. ITAP APPROACH In order to handle the performance issues of IT systems, methodology is being developed [1] to evaluate performance by integrating and leveraging: business modeling, traffic profiling, network simulation/benchmarking. We call this approach ITAP (IT System Architecture Planning). Figure 2 shows its concept maps. The business means all tasks and the flow of information in the business activity. A business activity using the IT system consists of several s that are executed according to the business. The business modeling is done using UML (Unified Model Language). The activity diagram and sequence diagram drawn by UML show the business activities for several aspects, for example: What are the successive stages or tasks of the business? What are sources and target data or ing objects? Where are sources and target data or ing objects? How do the data and ing objects communicate with each other? The above information is used to understand and improve the business itself and to model the traffic flow in the IT system: the destination/source, direction of the traffic flow, and the time when the transaction was generated, etc. In traffic profiling, the communication path should be considered. It is defined as the path among the identical 3-tier layers. According to [2], consider the theoretical three-tier architecture (Fig.3). This identical 3-tier architecture is represented by a 3 x 3 matrix: the rows are the physical tiers, i.e., client workstation,, and database, and the columns are the logical layers, i.e., presentation management, workflow/ logic management, and data management. The presentation management layer is an -related component that interacts with users and handles the presentation, preparation, and collection of information. The workflow and logic management layer accepts information requests, decomposes them, and directs them to the appropriate database management layer. The s that are implemented using this architecture model need several different types of inter- communications between the elements of this matrix. If there is a prototype of the, the communication path is defined using measurement data and analysis tools, for example, ACE ( Characterization Environment) [3]. By analyzing the communication path of the, we can understand how the integrated service communicates with the running on the remote s and where the traffic flow is concentrated on. In the network simulation, the virtual network is configured on the computer and virtual traffic data or real traffic data imported from the measurement tool flows on the configured network on the computer. Through the simulation experiments, we can obtain the performance of the and network devices. The simulation modules to represent the dynamics of the new or customized protocol are developed on demand. I used the hierarchical object oriented network simulation tool, OPNET [3] to model the simulation module and to execute the simulation experiments. It is very important to evaluate performance through the simulation experiments prior to implementations. This requires that: The IT system configuration representing the target IT platform is modeled on the computer, The target traffic flows along the communication path is revealed by the traffic profiling. Hereafter, we consider the -level communication protocols. These are implemented on the middleware. Because the enterprises need to develop more useful s as EAI, the importance of the performance evaluation of the level communication protocol is growing. Business Platform network IT system architecture Analysis based on traffic measurement Business modeling traffic profiling Network/business simulation (middleware, multi-tier, QoS, MPLS) Measurement and analysis of traffic data Simulation analysis of network and AP performance Solution approach Total performance solution

3 Presentation management Workflow management Database management Figure 2 Concept map of ITAP approach [1]. Client PC Presentation logic logic Database logic Database Figure 3 Communication paths in a distributed. [2] III. OVERVIEW APPLICATION-LEVEL CIMMUNICATION PROTOCOL This section briefly summarizes the -level communication protocol. It is very important to decide how each part of the should communicate with the other parts. This depends on the content and purpose of the. To communicate between es running in different computers, the objects that handle es should follow an agreed style of messages and protocol. Generally, for a simple client/ model, the communication is direct and synchronous. However, in a distributed, several [4], [5], [6], [7]. different styles of communication are possible: request/response, conversation, message queuing, publish and subscribe. In request/response communications, when communication is synchronous, the initiating sends a message and waits for a response message before it can continue ing. When the communication is asynchronous, the initiating continues ing after sending request messages. Let us consider an service that integrates two sub services running on remote computers. All requests from the clients are received at a broker, which invokes the to receive suitable sub services. The invoked sends request messages to multiple remote s and database s. In this case, there are three ways that the initiating running on the broker receives the sub services running on the remote s. The activity diagrams drawn by UML are shown in Fig. 4. This activity diagram is made in the Business Process Modeling phase. In order to implement these activity diagrams, there are several -level communication protocols. The initiating can also send different messages to different s in parallel. This is called Fan-out parallelism communication [4], [5]. A that receives the request from a client handles the request message and forwards it to other s, and this es it and forwards the request to other s; finally this last sends response messages back to the initiating client. The multiple tasks of the are ed in pipeline fashion like this, so this is called pipeline parallelism communication. If the broker sends the request messages to the remote in order, this is called ordered communication (See Fig. 5). In the next section, the simulation modules that represent this -level communication protocol are developed. In conversation, messages are exchanged between two communicating es. In the synchronous case, each one waits while the other takes its turn ing, and the procedure continues where it left off when the next message arrives. The message queuing is an asynchronous communication. The initiating places the message in a queue in the message queuing. The target retrieves the message later at its convenience. The response returns via a similar route. In message queuing protocol, the message is never blocked when the queue manager wants to receive it. Message queuing is very useful when an does not need to receive a response quickly. In publish and subscribe communication, an arbitrary client and es can subscribe to events and also publish events. When an event happens, a message is sent to the client or es that have subscribed to the event list. In designing a distributed, the designer should decide which communication method between distributed es running on remote computers is the best to fulfill the, considering the performance as well as the purpose and content of the. The service on the IT system is designed using a workflow editor. The workflow editor defines a workflow diagram that represents the successive stages or tasks of the business and the sub executed at each stage. So the simulation model that represents the above workflow diagram is very useful for evaluating the end-to-end performance. starts the integrated Invoke A in the 1 Invoke B in the 2 Process the responses in the broker The integrated ends Figure 4-1 Activity Diagram by UML (Fan out) starts the integrated Invoke A in the 1 Invoke B in the 2 Process the responses in the broker The integrated ends

4 Figure 4-2 Activity Diagram by UML (Pipeline) Figure 4-3 Activity Diagram by UML (Ordered) starts the integrated Invoke A in the 1 Process the response in the broker Invoke B in the 2 Process the response in the broker The integrated ends 1 Pipeline parallelism 1 1 Fan-out parallelism Ordered Figure 5 Comparison of fan-out, pipeline, and ordered IV. OPNET MODELING OF FAN-OUT COMMUNICATION In order to evaluate the performance of a multi-tier that communicates with several different s by fan-out parallelism communication, we need to modify the standard OPNET client/ model. This section briefly explains the simulation modeling by OPNET. A. Standard model OPNET is the network simulation tool that supports the hierarchical object-oriented model. In the OPNET model, to generate the traffic, several es are invoked according to tree structures, where the client/ manager is the root. The invoked child inherits the necessary information to perform the. In order to perform the layer protocol in the client node, the client/ manager invokes the profile manager and then the manager. Each manager invokes the client. The client works as follows. It establishes a TCP session between the client and the target. Then, this generates the message according to the traffic generating defined by the manager and sends it to the transport layer module. The transport layer handles the message and forwards it to the target remote. When the client has received all responses from the remote, it closes the TCP session. In the node, the client/ manager receives the request messages and handles them. In the standard OPNET ver.8.0.c client- model, the standard client s ( , ftp, http, etc.) can set a back-end custom attribute. The custom is a versatile model that enables us to model several tasks that are ed in one activity. In a task definition, we can define the source node, destination node, and the traffic volumes of the request and response messages between the source and destination nodes. When the backend custom name is set as a parameter, this information is involved in the request message from the client as the attribute. The receives the request and reads the attribute of the back-end custom name in the request message and invokes the appropriate custom. Therefore, this works as the request broker. When the invoked custom has finished, the response message is sent back to the initiating client. The client in the client node measures the round-trip request-response time. This statistical measure is very important in designing a multi-tier with the above features. Most web services have the above architecture. B. Addition of fan-out procedure to the standard OPNET client- model In the standard custom, client es can be invoked simultaneously to handle all the registered tasks. However, the standard custom manager that invoked the custom as the back-end does not care whether all simultaneously invoked tasks have finished or not. Therefore, a procedure for managing the status of all tasks invoked simultaneously should be added to the standard OPNET custom manager model to make the broker. In the modified broker model, the list is newly created to manage the status of the invoked tasks. When the broker receives a new request from the client, this list is created. Then, the data objects are also created for each task

5 to be invoked. These data objects have two properties: the task identifier and the task status flag. When a task is over, the broker manager accesses the entity in the list. When the entity with the same task identifier as that of the finished task is found in the list, this entity is removed and the memory allocated to it is released. When the broker removes all entities in the list, the list size becomes 0. This shows that all tasks invoked by the broker are over. Finally, the broker manager sends the response message back to the initiating client. (See Figure 6) In addition, in the modified model, when the broker sends request messages to s in parallel, this invokes the custom client es to handle the task continuously with a small lag, in order to avoid collisions in the network. client Figure 6 Modified broker model We added the above procedures to the standard OPNET models and simulated a back-end with fanout parallelism. Here, the client and manager models for requesting the back-end are also newly created. In this model, the client is waiting to receive the final response from the broker. After the client has received it and some thinking time has elapsed, the client sends the next request to the broker (See Fig. 7). The client cannot send another request until it has received all responses to the previous request. That is, the communication between the client and the broker is synchronous. Send the request Client/ manager Invoke manager client client When all tasks are over, interrupt the root in order to send the response back to the initiating client. Make the list Invoke simultaneously Receive the response task_identifier task_status task_identifier task_status task_identifier task_status Wait for the response Thinking time Figure 7 Generating a request by the fan-out client V. SIMULATION ANALYSIS When the task is over, the entity is removed. Using the modified broker model, we performed simulation experiments. This section explains the traffic model. The client node sends the request message and waits for the response from the broker ; that is, this is synchronous. The thinking time has an exponential distribution with mean of 30 seconds. The client generates a request message with a fixed size of 1024 bytes, and receives a response message with a fixed size of 8192 bytes from the broker. The broker generates a request message with a fixed size of 512 bytes and sends it to the. The es the request message and sends a response message with the fixed size of 4096 bytes back to the broker. The number of tasks that can be invoked by the back-end s varies. The time to generate the request message in the broker and node is fixed to 1. The time to the request message and generate the response message in the is defined as follows. In the, contention mode is chosen the job scheme. In this mode, when there is only one job to be handled, the request is ed in the and the service time of this job is explicitly fixed to 1 second. But when multiple jobs are simultaneously ed in the during congestion, the CPU power in the is equally allocated among all ing jobs. Therefore, the service time of a job may exceed 1 second during congestion. The TCP parameters of the client and nodes and other parameters of the other nodes and links are set to the OPNET default values. In addition, in using fan-out parallelism, the broker invokes the custom client es to handle the task continuously with a fixed time lag, 1 second, in order to avoid collisions in the network. In using the pipeline parallelism, the broker sends a request message with a fixed size of 512 bytes, and forwards a request message of the same size to the next. The second sends an acknowledgement back to the forwarding, and the final sends the response message with a fixed size of 4096 bytes, back to the broker. Therefore, in this simulation example, the total traffic volume flowing in the network using pipeline parallelism is the smallest among all cases. The traffic flow in this example is summarized in Fig. 8. Greq:1 Greq: 1+Proc:1 Proc: bytes 512 bytes S2 () (App) (App 8 bytes 8 bytes 4096 bytes Pipeline parallelism Greq:1 512 bytes S2 Proc: bytes (App) Fan-out () 4096 bytes parallelism Proc: bytes (App) Greq: 1+ Lag:1 Figure 8 Traffic model. Greq: Time to generate the request message Proc: Time to and generate the response Lag: Time lag to invoke the task in fan-out parallelism A. Comparison of fan-out parallelism, pipeline parallelism, and ordered communication Standard model Consider a network configured as shown in Fig. 9. The client and nodes are connected via a 100Base-T switch.

6 The broker () invokes the back-end when requests from the clients (W to WS5) are received. In the back-end, multiple tasks are ed. They are defined as follows. First, the broker sends a request message to the s, which handle it using the contention mode mentioned above; finally the broker receives the response messages from the. Here, we compare the three types of communication between the broker and es: fan-out parallelism, pipeline parallelism, and ordered. The response times are shown in Figs. 10 and 11. There are two s in Fig. 10 and four in Fig. 11. The response time as the performance measure is defined by the time difference between when the client receives the response and when it sent the request. In this case, the response time of fan-out parallelism is the shortest. When there are four s, the response time of the pipeline is smaller than that of the ordered. In this network configuration, contention among jobs in the broker and s and traffic congestion in the LAN switch affect the response time. Our simulation analysis showed that the communication path between es running in different computers improves the response time performance of the. VI. CONCLUSION AND FURTHER STUDY In this paper, I introduced the performance design approach concept called ITAP (IT System Architecture Planning) by integrating and leveraging Business Process Modeling, Traffic Profiling, and Network Simulation/Benchmarking. And as a case study, I evaluated the performance of the fan-out, pipeline, and ordered synchronous request/response communication protocol. Given the activity diagram that represents the way where the initiating running on the broker receives the sub services running on the remote s, a simulation module representing the dynamics of the above activity diagram was developed and simulation experiments were done. The type of communication between the broker and the depends on the purpose and content of the s information. If possible, the fan-out parallelism is a good choice for communication between es in order to improve the response time. In this simulation model, the communication between the client and the broker is synchronous. Therefore, when the s are busy, or the network or Internet provider s network cloud is congested, the response time is longer. In such a case, users will not be satisfied with the service quality of the. One solution is to use asynchronous communication and a message queuing protocol [2], [4], [7], [8]. I have also developed a simulation module representing the message queuing (MQ) communication model [9]. Furthermore, web services are now proposed as a technology that can integrate multiple s. In the web service, a remote procedure call RPC to the running in the remote is done using SOAP protocol [10]. In the future, communication paths will become more complex and the -level protocol will be very important. Therefore, it is important to evaluate the performance prior to implementation using several such protocol simulation models. Such an approach can reduce the risk of implementing an that subsequently shows poor performance. REFERENCES [1] Hiroshi Yamada, Yada Takeshi, Information Technology System Architecture Planning Platform (ITAP), NTT Review, Vol. 13, No. 5, Sep., pp.78 94, 2001 [2] Chris Loosley, Frank Douglas, High-Performance Client/Server A Guide to Building and Managing Robust Distributed Systems, John Wiley & Sons, Inc., 1998 [3] OPNET Technology, Inc., [4] Carl L. Hall, Building Client/Server s Using TUXEDO, John & Wiley & Sons, Inc., 1996 [5] Jeri Edwards, 3-Tier Client/Server at Work, John Wiley & Sons, Inc., [6] Juan M. Andrade, et al., The TUXEDO System, Software for Constructing and Managing Distributed Business s, Addison- Wesley Publishing Company, Inc., 1996 [7] IBM, Architecting e-business Solutions with IBM s Business Transformation & Integration Middleware, 3.ibm.com/software/ts/mqseries/library/index.html. [8] Chris Britton, IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Pearson Education, Inc., [9] Hiroshi Yamada, OPNET Modeling of Message Queuing Protocol, to appear in the Proceedings of OPNETWORK2002, [10] Sun Microsystems, Implementing Services on Demand With the Sun Open Net Environment SUN ONE - A Sun Professional Services White Paper, Client W Client WS2 Client WS3 Client WS4 Client WS5 time (seconds) Server Figure 9 Network model Download time Fan Out (mean:4.17) Ethernet SW Server 1 Pipeline (mean:5.15) Ordered (mean:5.23) Elapsed time (seconds) Figure 10 time (For two s) Server 2 Server 3 Server 4

7 time (seconds) Download time Pipeline (mean:9.78) Fan Out (mean:7.76) Ordered (mean:11.9) Elapsed time (seconds) Figure 11 time (For four s)