A Distributed Connection Manager Interface for Web ... - CiteSeerX

Download PDF
7 downloads 16575 Views 184KB Size Report
Comment
processes and a round-robin dynamic name server, we can provide Web ... ting up its own socket for CGI script processes to talk to and ... ated using \CMDadmin -b" (b for build) before the CM. Daemon ... A dedicated open socket connection between the. Connection ..... 19] A. Koopman and S. Hay, \Swim at your own risk.
A Distributed Connection Manager Interface for Web Services on IBM SP systems Yew-Huey Liu, Paul Dantzig, C. Eric Wu

Lionel M. Ni

IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532

Computer Science Dept. Michigan State University E. Lansing, MI 48823

Abstract

In essence, the World Wide Web is a worldwide string of computer databases using a common information retrieval architecture. With the increasing popularity of the World Wide Web, more and more functions have been added to retrieve not only documents written in HTML (Hypertext Markup Language), but also those in other forms through the Common Gateway Interface (CGI), by constructing HTML documents dynamically. Dynamic construction of HTML documents for handling information such as digital libraries is slow and requires much more computer power. A signi cant performance bottleneck is the initialization and setup phase for a CGI process to gain access to the system containing the data. In this paper we describe the design and implementation of a Connection Manager Interface on IBM SP systems. The Connection Manager provides cliette processes to serve CGI requests and eliminates such bottlenecks. An IBM SP system is used for this emerging area to show that our design and implementation is exible enough to take advantage of the High-Performance Switch in an IBM SP system. We trace and monitor this scalable Web services using UTE (Uni ed Trace Environment) tools, and present its performance analysis and visualization.

1 Introduction

The scalability of the current World Wide Web [1] is mostly accomplished through the distribution of les across a series of decentralized servers. This form of load distribution is both costly and resource intensive. Given the exponential growth of the internet in recent years, and the Web in particular, it is increasingly more dicult for organizations and information system sta s to properly anticipate future Web service needs, both in human resources and hardware requirements. The basic approach for a HyperText Transfer Protocol (HTTP) server (a.k.a. Web server or HTTPD) to retrieve an existing HyperText Markup Language (HTML) documentation is to simply get it from the documentation tree. As the Web is getting more popular, additional functions have been added to retrieve data more eciently [2]. The virtual server concept

was introduced [2, 3] to add scalability by dynamically rotating through a pool of HTTP servers. It uses a round-robin dynamic name server (DNS) to distribute Web requests across a cluster of identically con gured http servers. This type of design reduces single point failures and increases its availability. In addition, data stored in other forms can be retrieved through the Common Gateway Interface (CGI). The CGI provides an interface to dynamically construct a HTML documentation for an HTTP server, so that data and documents need not be stored in the documentation tree. This allows the use of various tools such as relational databases to provide easy maintenance and manipulation of the documents and data. For example, by storing data in a relational database, one can generate query language scripts in CGI processes to retrieve data from the database and construct HTML documentations on the y. A CGI process needs to gain access to its backend server after it receives a Web request. The initialization and setup phase may be a time-consuming step, especially for simple requests. Unfortunately this initialization step has to be repeated many times for many CGI requests, since each CGI process is created to serve just one Web request. Several papers were published in the past on how to improve HTTP server performance [4, 5, 6]. However, none had addressed the bottleneck associated with the initialization and setup phase. This bottleneck becomes signi cant and wastes resources especially when most web requests are simple. This costly initialization phase motivates us to design and implement a Connection Manager Daemon (CMD) interface to speedup the time for serving CGI requests. The CMD interface provides multiple long-running cliette processes to serve CGI requests and to reduce the initialization/setup time for gaining accesses to the underlining software systems. These cliette processes are virtual users who logon to various applications such as Visual Info [7] and database systems. Multiple cliette processes may be used for each software system. For example, a number of cliettes may connect to a DB2 database at the same time, and a roundrobin dynamic name server can be used to distribute the requests.

The main function of the Connection Manager Daemon is to schedule cliette processes to serve requests coming from various CGI processes. Cliette processes can be dynamically started or terminated according to the load of the HTTP server to increase its scalability. By combining the load distribution of cliette processes and a round-robin dynamic name server, we can provide Web services with greater exibility and scalability. A IBM SP system is a general-purpose scalable parallel system based on a distributed memory architecture [8]. Scalable parallel systems are increasingly being used today to address existing and emerging application areas that require performance levels significantly beyond what symmetric multiprocessors are capable of providing. These areas include technical computing, transaction processing, and emerging areas such as digital libraries and Web services. The heart of an IBM SP system is the HighPerformance Switch, a low-latency, high-bandwidth switching network that binds together IBM RS/6000 processors [9]. Since the High-Performance Switch supports IP as well as other message passing interfaces, an IBM SP system can be viewed as a cluster of RS/6000 workstations with fast IP connections and provides a migration path for Web services. The fast IP connection provides a message latency of 319 micro seconds and e ective point-to-point bandwidth of 8.3 MBytes per second for MPL/UDP on a IBM SP2 with RS/6000 model 390 nodes [10]. In this paper, we will describe our design and implementation of the CMD interface on IBM SP systems. Scalable Web services are provided through the use of a CMD server and its cliette processes, along with CGI processes and HTTP/DNS servers. In addition, we modify the Uni ed Trace Environment [11] (UTE) to generate trace events of the connection manager daemon and cliette processes. All events can be visualized, not only to understand the communication behavior of the connection manager daemon and cliette processes, but also to understand system responses to the application. In Section 2 we will explain the design and implementation of the CGI connection manager interface and how the scalability is achieved. The trace environment and its tools are described in Section 3, and program visualization/performance analysis of the daemon and cliette processes is shown in Section 4. Concluding remarks are given in Section 5.

2 A Distributed Connection Manager for Web Services

At the center of our design for scalable Web services is the Connection Manager Daemon (CM Daemon or CMD for short). After setting up its wellknown socket, the Connection Manager Daemon starts up a number of processes locally or remotely to serve as cliette processes. The number of cliette processes and their identities are de ned in a con guration le. A cliette process can be created on a remote machine. It can be created on a di erent platform with a di erent operating system as long as TCP/IP socket interface is available.

Requesting Cliette Connection Manager Daemon

CGI

Cliette

Informing Cliette Connection Manager Daemon

Assign Cliette

CGI

Connection Manager Daemon

CGI

Connection Manager Daemon

CGI

Connection Manager Daemon

Cliette

Forward request Cliette

Returning results

Cliette Free

Cliette

Cliette

Figure 1: How service is established between the cliette and CGI processes Initialization steps of the cliette process include setting up its own socket for CGI script processes to talk to and informing the Connection Manager Daemon of its socket ID and process ID. The daemon process keeps the returned values (i.e. socket number and process ID) in a queue. This queue is used by the CMD to choose a free cliette process and to return the cliette's socket number to the requesting CGI process. After initialization, a cliette process logs on to its application service provider using information passed from the Connection Manager Daemon. A cliette process stays logged on until the Connection Manager Daemon either re-initializes or terminates it. Figure 1 shows the event sequence of serving Web requests through CGI processes. A CGI process forwards Web requests to a cliette process and receives results from a cliette process on behalf of Web clients. The shaded area indicates steps which are repeated for each request. When a web request comes in, a CGI process is started and sends a request to the Connection Manager Daemon asking for a cliette process through the Daemon's well-known socket. The daemon chooses a free cliette process and forwards the cliette's public socket number to the CGI process. The CGI process then forwards the request (i.e. the Uniform Resource Locator(URL) string) to the corresponding cliette process. If no cliette process is available, the CGI process goes into a wait state. In this case the Connection Manager Daemon is responsible to wake up the waiting CGI process when a cliette process becomes available. The CGI process then forwards the request and goes to sleep until the response is ready. Two timeout values are used by a CGI process during the interaction between the CGI and cliette processes. The CGI process sets a timeout value when it starts waiting for a free cliette. After receiving a free cliette, the CGI process sets another timeout value and starts waiting for the HTML documentation. Note that the

Visual Info Cliette Processes

DB2 Cliette Processes

Connection Manager Daemon Requesting Cliette WEB Server

CGI

Forward URL string

Sending HTML

Process

Cloud

A dedicated open socket connection between the Connection Manager Daemon and each cliette process is also used for maintenance purposes. The open socket connection supports the following activities:  The CM Daemon sends maintenance requests to cliette processes.  The CM Daemon gets an interrupt when a cliette process dies.  A cliette process announces that it is free to serve more requests.  A cliette process announces that it has performed certain maintenance steps.  Dynamic trace generation and termination. This will be discussed in more detail in sections 3.1.

2.2 Cliette Processes

Figure 2: Connection Manager Daemon being used by an HTTP (Web) server Connection Manager Daemon and CGI processes can be executed on di erent machines or nodes. In addition to request services from the service provider, the cliette process is responsible to construct HTML documents dynamically and return it to the CGI process. Figure 2 shows the snap-shot of a running system.

2.1 Connection Manager Daemon

The Connection Manager Daemon reads a startup con guration le (/etc/CMDaemon.conf if no con guration le is provided) for information about how cliette processes should be created. A system utility CMDadmin is developed to create con guration les interactively. A con guration le is usually created using \CMDadmin -b" (b for build) before the CM Daemon starts to run. All cliette passwords are stored in the con guration le using an encrypted format to protect them from being misused. A system administrator can use commands such as \kill -1 CMDaemon process id" or \CMDadmin -i" to re-initialize the CM Daemon and to re-read a con guration le. Rereading the con guration le will cause all existing cliette processes to terminate. The Connection Manager Daemon has a wellknown socket for interaction with CGI and cliette processes. This well-known socket is used  for a cliette process to announce its socket number for CGI processes to talk to,  for a CGI script process to request a cliette process, and  for a system administrator to issue commands to start a new cliette process, stop a cliette process or debug a cliette process. The system utility CMDadmin is also used for this purpose.

Cliette processes can be dynamically created on machines/nodes either local or remote to the CMD, depending on current system loads. A remote cliette is created by the CM Daemon using rexec() on the remote host speci ed in the con guration le. After the cliette is created it initiates the dedicated socket connection with the CM Daemon. If the remote cliette process resides on a host outside a rewall in the open internet environment and the CM daemon resides inside the rewall, connection between the CM Daemon and the cliette is made through the rewall host using the SOCKS [12] service. In this case the cliette process will not initiate the socket connection with the CM Daemon, because the rewall will block any connection request from outside. Instead, the CM daemon initiates the connection with the remote cliette process through the cliette's pre-de ned socket port. If the CM daemon fails to make the connection with a remote cliette process, no automatic retry will be made. However, a system administrator can use the CMDadmin utility to force the CM daemon to retry the connection request at a later time. After initialization a cliette process listens to the CM Daemon through its dedicated socket connection for maintenance commands such as cliette stop to stop a cliette process or cliette trace to trace a cliette process. An active (not-terminated) cliette can be in one of the following states: Cliette STARTUP, Cliette ZOMBIE, Cliette AVAIL and Cliette BUSY.  Cliette STARTUP: The cliette process is being initialized.  Cliette ZOMBIE: The cliette process encounters an error and is waiting for the connection manager daemon's action.  Cliette AVAIL: The cliette process is available for service.  Cliette BUSY: The cliette process is currently serving a request.

cliette_ayt

Cliette_BUSY cliette_kill

Terminated

finish serving CGI cliette_kill cliette_stop

Cliette_AVAIL

cliette_kill cliette_kill

Cliette _reinit

Error

cliette _ayt traceon/off debugon/off

initialization/login

Error Cliette_ZOMBIE

Error

Cliette_STARTUP

Figure 3: State Transition Diagram for a Cliette process Figure 3 shows the state transition diagram of a cliette process. A cliette is in its Cliette STARTUP state when it is being initialized by the CM Daemon. Subsequently it enters the Cliette AVAIL state. The cliette process changes state to Cliette BUSY when a Cliette dojob request is received from the CM Daemon. This tells the cliette process to expect a URL string coming from a CGI process whose ID is speci ed in the request block's sender id eld. The cliette process then sets up a timeout value waiting for the CGI process. If the time expires before a URL string was received, the cliette process changes its status back to Cliette AVAIL and ignores any connection requests coming from its public socket port. A cliette process won't change its Cliette BUSY state until the request is served, or unless it is terminated by the connection manger daemon's Cliette kill command. After initialization a cliette process listens to the CM Daemon through its dedicated socket connection for maintenance commands such as cliette stop to stop a cliette process or cliette trace to trace a cliette process. During cliette initialization a dedicated connection is made between the cliette process and the CM Daemon, and the information listed in the con guration le is passed to the cliette process as environment variables through the dedicated socket. A cliette process can retrieve the passed information using the getenv() subroutine call. The passed environment variables are used by the cliette's login subroutine to login to a service provider such as Visual Info or DB2. Each cliette process needs to provide a login routine and logout routine for service initialization and termination. The login subroutine is called automatically by the initialization routine InitSelf() or when the cliette process receives a Cliette reinit command from the CM Daemon. The logout subroutine is called when the cliette receives a Cliette stop request from the CM Dameon to terminate its service. Upon receiving a request from a CGI process, the CM Daemon nds a free cliette and tells the CGI process what the cliette's public socket is. The CM Daemon also provides the cliette process with the CGI

process' process ID. Once receiving the Cliette dojob request from the CM Daemon, the cliette process sets its own timeout value and starts listening on its public socket port for connection request from the CGI process. The cliette process will ignore a URL request if it is from an unexpected CGI process. If the timeout expires before it receives any URL request from the CGI process, the cliette puts itself back to the Cliette AVAIL state and informs the CM Daemon its new status. The rst message, an identi cation packet, sent by the requesting CGI process to the cliette process contains the CGI process ID, a subset of CGI environment variables and some URL-related information (such as the size of the complete URL string). These environment variables and URL-related information are set dynamically after receiving the identi cation message using the getenv() subroutine call by the cliette process, and reset when the cliette process nishes serving the current CGI request. In such a design for Web services, adding additional Web services can be achieved by simply adding a machine/node to run additional cliette processes, provided that the application service provider such as DB2 and Visual Info can keep up with the requests. This signi cantly improves the scalability and exibility of the Web services.

2.3 CGI Processes

An HTTP server provides dynamic HTML document generation through CGI processes. Upon receiving a URL string containing a CGI request from a Web client, the httpd forks a child process to run the CGI script. The newly created CGI script inherents a number of environment variables [1], which indicate how the Web server is setup and how to communicate with the Web client. The CGI process terminates after serving the URL request. In order to communicate with the cliette processes eciently, we design an application programming interfaces (API) for a CGI process to use. They are GetCliette(), ConnectCliette(), PutURL() and WaitForHTML(). When a CGI process is ready to request a cliette process, it uses the GetCliette() subroutine to ask the CM daemon for a free cliette process. The subroutine will return with the cliette's public socket address and the cliette's machine name. If no free cliette process is available, the CGI process is forced to wait. The CGI process can also tell the CM daemon how long it intends to wait for a free cliette. If the timeout period expires before a cliette process becomes available, the GetCliette() returns a -1 to the CGI process. If a free cliette process is available, the CGI process uses ConnectCliette() to connect to the public socket port of the free cliette. After the connection is made, the CGI process forwards an identi cation packet to the cliette process. This identi cation packet also contains a subset of the CGI environment variables, including request method, content type, con-

tent length, script name, path info, path translated, query string, remote host, remote addr, server name and server port. These environment variables are set

by the cliette process dynamically for each CGI re-

quest. The cliette process then sends an acknowledgement packet and issues GetURL() to get the URL string. After receiving the acknowledge packet along with the request for the URL string, the CGI process issues the PutURL() to send the URL string to the cliette process. Note that the CGI process is passive since the CGI process won't send any URL string until the cliette requests it. The CGI process then issues the WaitForHTML(), and start reading the dynamic generated HTML documentation when it is sent by the cliette using SendHTML(). Both the PutURL() / GetURL() and WaitForHTML() / SendHTML() pairs are implemented in a way similar to stream le I/O, i.e. the reader waits until the writer puts something in the channel. Both the reader and writer can specify how much information it is reading or writing. The CGI process sends the requested information back to the Web client as it receives the dynamically generated HTML document. Depending on the design of the Web clients, some Web clients may start processing the HTML information before the entire documentation is received. In the current design for the scalable Web servers, the CGI processes are individual processes forked by the HTTP server. Each Web CGI request will create a new CGI process. Although we wish to make CGI processes as small as possible, the forking of a CGI process is still very costly. Since our goal is to provide a generic CGI interface without modifying existing HTTP servers, we have little control on how CGI processes are created. Two approaches may be combined to reduce the bottleneck of the HTTP server. One is to use a threaded HTTP server to reduce the overhead associated with creating CGI processes, and the other is to allocate the HTTP server, connection manager daemon, and cliette processes on di erent machines/nodes.

3 UTE Trace Library and Trace Generation Several UTE trace libraries have been built for scienti c applications on IBM SP systems [13, 11]: the UTE/MPL and UTE/MPLp libraries for IBM's Message Passing Library and the UTE/MPIF library for the standard Message Passing Interface. Built on top of the AIX trace facility, these UTE trace libraries instrument message passing routines to provide detailed information on message passing and system activities. The AIX trace facility is capable of capturing a sequential ow of time-stamped system events to provide a ne or coarse level of detail on system activities. This is because the AIX operating system is instrumented to provide general visibility of system events, including process dispatch, page fault, system call, and I/O. The Uni ed Trace Environment has been shown with great extension capabilities. In addition to trace libraries for message passing layers in scienti c applications, trace hooks have been inserted in parallel software systems such as HPF (High Performance Fortran) [14], and PIOFS [15], to generate events in various software layers.

We choose nupshot [16, 17], a public domain visualization tool developed at Argonne National Laboratory and distributed through MPICH to visualize UTE trace events. Nupshot provides a graphical interface to display timelines of process state information. Nupshot is modi ed to display additional information, such as message size for IP Send and IP Recv states, and process name and ID for other processes, in the dynamic pop-up information window. A source code browsier was also added for corelating visulalizaed events to lines in the course code [11].

3.1 UTE Extensions

In this study we modify UTE in multiple ways to support tracing the scalable Web server:  A UTE trace library is built to trace the CM Daemon and its cliettes. Possible trace events include message passing through IP such as begin and end events for IP Send and IP Recv, phase markers such as begin and end events for serving CGI requests (servCGI).  Trace generation is enhanced so that it can be initialized and/or terminated dynamically.  A CM Daemon and its cliettes may be executed in the same SP node. The trace facility must be able to support multiple trace channels.  Previous UTE trace libraries require the POE (Parallel Operating Environment) on an SP machine to schedule tasks and assign a unique ID for each collaborating process. Since a scalable Web server should be able to run on a cluster of workstations, the CM daemon is responsible to assign a unique task ID for each traced process (i.e., the CM Daemon and its cliettes). Thus, the scalable Web server does not require POE, making it portable in multiple platforms and environments.

3.2 Dynamic Trace Generation on IBM SP Systems

The original UTE trace libraries were developed for scienti c applications, and trace generation normally starts at the start-up time and ends when a process exits. A client/server application is very di erent from a scienti c application, in that a server may be idle (and ready for clients) for a long time between incoming requests. The load of a Web server may vary widely in a day or a week. Obviously, tracing the entire session of the scalable Web server will cause unnecessary tracing information being generated, and terminating the server merely for collecting trace events does not make sense in a real-world client/server application. Dynamic trace generation, which allows a Web service administrator to turn on/o trace whenever necessary, is achieved through the use of the CMDadmin utility. Upon receiving a Trace start request the connection manager daemon will call the TraceCliette routine which asks each active cliette process to turn on its trace. An acknowledgement is sent back to the connection manager daemon after the cliette process turns on its trace. If a cliette process is busy serving a CGI

request, a ag is posted on the cliette queue. When a busy cliette process returns to the cliette AVAIL state, this ag is checked and corresponding trace action will be performed. This delay makes sure that cliette trace events are generated on a CGI-request basis and prevents trace initialization when serving a CGI request. The connection manager daemon turns on its own trace only after it has received con rmation messages from all cliette processes. If a cliette process fails to turn on its trace, an error for tracing will be sent back to the connection manager daemon. In this case the CM Daemon may abort trace generation by sending a Trace stop command to those cliette processes whose traces are already on. Another useful option is to turn on some cliette processes' traces while others are running without tracing. This allows system administrator to monitor problematic cliette processes. The tracing of the connection manger daemon is always on as long as some cliette processes are being traced. Thus, dynamic trace generation of selected cliettes may be a powerful choice for debugging interactions between the CM Daemon and a newly developed cliette. Trace generation is terminated when the traced process exits or the system administrator issues a stop-tracing request using the CMDadmin utility. The CM Daemon has a task ID of zero, and assigns a unique, positive task ID to each cliette process. A trace le is generated for each traced process, with the unique task ID as the le name extension. This saves one word per trace record in raw trace les, since a trace record does not need a eld to indicate which task it is generated from. Special precaution is taken to avoid existing trace les being accidentally overwritten by repeated requests of turning on tracing. Each trace on/o request pair generates a set of trace les, and multiple trace on/o requests can be issued during the entire course of the distributed scalable Web server. After the traces are successfully generated, UTE utilities are used to merge and analyze the trace events.

4 Performance Analysis on IBM SP Systems

The World Wide Web is a signi cant transformational tool for digital libraries. Many Web pioneers are exploring the use of the Web by implementing innovative services for information retrieval and discovery [18, 19]. In a joint study between IBM and Florida Center for Library Automation (FCLA), the distributed CMD interface is used as a gateway between the FCLA state of the art Bibliography Search server and the Visual Info system. IBM Visual Info is used to store electronic collection of journal articles and class notes. It consists three basic subsystems - a OS/2 Library server, one or more OS/2 Object server(s) and the client subsystem. Our special purpose SP/2 cliette processes form the Visual Info client subsystem. We will present the performance tracing of our scalable web server in the FCLA digital library environment. Two data sets are collected, one on a cluster of workstations (in fact an IBM SP2 without using the

High-Performance Switch), and the other on an IBM SP/2 system using the High-Performance Switch.

4.1 Cliettes on An IBM SP system

In this setting, we run the scalable Web services on an IBM SP2 without using the High-Performance Switch. The httpd runs on one SP node, the connection manager daemon runs on another SP node with all CGI processes, while its cliette processes run on three additional SP nodes. Each node in the IBM SP system has a 66.5 MHz Power2 processor. By allocating a dedicated SP node for the Connection manager daemon, we can schedule CGI requests to their cliette processes in a timely fashion. Its corresponding elapsed time statistics are shown in Table 1 and 2. Table 1: Elapsed Time Statistics ID

0 1 2 3 4 5 6

Total 0.020 0.027 0.031 0.025 0.027 0.036 0.033

IP Send

# 124 177 183 167 179 195 189

Average 0.000162 0.000154 0.000169 0.000154 0.000152 0.000189 0.000174

Total 0.019 0.033 0.033 0.029 0.034 0.030 0.048

IP Recv

# 231 136 148 130 138 166 154

Average 0.000083 0.000247 0.000224 0.000228 0.000250 0.000181 0.000312

Table 2: Elapsed Time Statistics

TaskID

1 2 3 4 5 6

servCGI

Total #calls Average 146.854 21 6.993 159.266 18 8.848 157.562 19 8.292 161.608 21 7.695 184.155 15 12.277 169.787 18 9.432

4.2 Cliettes on An IBM SP system Using High-Performance Switch

In this example we take advantage of the highperformance switch for sending and receiving messages among the CM Daemon, its cliettes, and all CGI processes. The platform and environment is the same as in the previous sub-section, except that the High-Performance Switch is used in this example. The elapsed time statistics are shown in Table 3 and Table 4. The average time for IP Send is slightly improved, from roughly 0.16 ms to 0.14 ms. The average time for IP Recv in cliette traces is improved from roughly 0.2 ms to 0.085 ms, indicating that the High-Performance Switch does help. Table 5 shows the average sending and receiving times of matched messages between the CM Daemon (task 0) and its cliettes (tasks 1 to 6). A matched

Figure 4: Cliettes on An IBM SP system message is a message whoes send and receive events have been found in the trace les. Table 3: Elapsed Time Statistics ID

0 1 2 3 4 5 6

Total 0.017 0.028 0.026 0.028 0.026 0.027 0.024

IP Send

# 128 191 183 195 177 187 179

Average 0.000135 0.000150 0.000145 0.000148 0.000151 0.000145 0.000137

Total 0.019 0.014 0.011 0.014 0.011 0.012 0.011

IP Recv

# 239 152 144 158 144 148 140

Table 4: Elapsed Time Statistics

TaskID

1 2 3 4 5 6

servCGI

Total #calls Average 150.024 20 7.501 141.592 20 7.079 159.060 19 8.371 163.552 17 9.620 161.147 20 8.057 142.344 20 7.117

Average 0.000083 0.000094 0.000083 0.000092 0.000080 0.000084 0.000082

Table 5: IP Send and IP Recv for messages between the CM Daemon and its Cliettes Task ID IP Recv IP Send No. Avg. Time No. Avg. Time task 0 122 0.000092 128 0.000135 task 1 22 0.000101 21 0.000136 task 2 22 0.000103 21 0.000136 task 3 21 0.000109 20 0.000130 task 4 19 0.000113 18 0.000138 task 5 22 0.000083 21 0.000134 task 6 22 0.000082 21 0.000139 When a CGI process requests a cliette process, it sends a GetCliette message to the CM Daemon. This rst message sent by the CGI process is recorded in the CM Daemon's trace le (an IP Recv whose sender has no unique task id yet) but the corresponding IP Send is not recorded. Again, the subsequent message from the CM Daemon to the CGI process is only recorded in the CM Daemon's trace le (an IP Send). There are other messages such as the ones between a cliette process and its CGI processes, and those between the CM Daemon and the CMDadmin utility. Table 5 shows only the matched sent/received mes-

sages. The number of IP Recv (IP Send) in the CM Dameon's trace le is equal to the total number of IP Send (IP Recv) recorded by its cliette processes. Table 5 also shows the average IP Send and IP Recv times for messages between the CM Daemon and its cliette processes. By comparing Table 3 and Table 5, we show that the CM Daemon received 117 (239 minus 122) messages from CGI processes and the CMDadmin utility. Since there are 116 CGI requests in total (from Table 3), the remaining message is sent by the CMDadmin utility which requests the CM Daemon to turn o all the traces.

5 Conclusion

In this paper, we presented a distributed Connection Manager daemon and a number of cliette processes on IBM SP systems. It is designed to improve the scalability and portability of existing Web servers. We also demonstrated an innovative tracing facility for the distributed Connection Manager and its cliettes. The events obtained from the trace facility help a Web administrator to monitor the behavior of the Web services and analyze its performance. It also helps identify the bottleneck of the Web services. The dynamic tracing feature improves the exibility to gather trace records, and thus extend the tracing scope from scienti c codes to client/server applications. Several improvements are underway for the interface design and implementation. A cache manager has been designed to help a cliette process maintain its information more eciently, and to help a CGI process return previously acquired information back to the Web client instead of requesting it again from cliette processes. In addition, the on-line timing routines in the trace library will be exploited for program steering and load balancing to achieve automatic scalability across multiple platforms. A multi-threaded connection manger daemon is also under development to reduce CGI request overhead.

References

[1] A. Ford, Spinning The Web - How to Provide Information on the Internet. VNR Communications Library, 1995. [2] S. Lewontin, \The dce web toolkit: Enhancing www protocols with lower-layer services," Third International World Wide Web Conference., 1995. [3] E. D. Katz, M. Butler, and R. McGrath, \A scalable http server: The ncsa prototype," Proc. 1994 World Wide Web Conference, 1994. [4] R. B. Denny, \Website performance analysis," tech. rep., http: //www. Stars. com/, 1995. [5] S. E. Spero, \Analysis of http performance problems.," WWW Conference '94, 1994. [6] V. N. Padmanabhan and J. C. Mogul, \Technical document: Improving http latency," tech. rep., http://www.ncsa.edu/SDG/ IT94/ Proceedings/ DDay/mogul/ HTTPLatency.html, 1995.

[7] I. B. Machines, ImagePlus VisualInfo - An integrated desktop solution for document management and beyond. IBM Publication G221-401100, 1995. [8] T. Agerwala, J. Martin, J. Mirza, D. Sadler, and M. Snir, \Sp2 system architecture," IBM System Journal, vol. 34, no. 2, pp. 152{184, 1995. [9] C.Stunkel, D. Shea, B. Abali, M.Atkins, C. Bender, D. Grice, P. Hochschild, D. Joseph, B. Nathanson, R. Swetz, R. Stucke, T. Tsao, and P. Varker, \The sp2 high-performance switch," IBM Systems Journal, vol. 34, no. 2, 1995. [10] M. Snir, P. Hochschild, D. Frye, and K. Gildea, \The communication software and parallel environment of the ibm sp2.," IBM System Journal, vol. 34, no. 2, pp. 205{221, 1995. [11] C. E. Wu, H. Franke, and Y.-H. Liu, \Ute: A uni ed trace environment for ibm sp systems," Proc. 1995 International Conference on Parallel and Distributed Computing Systems, September 1995. [12] D. Koblas and M. R. Koblas, \Socks," Proc. of 1992 USENIX Security Symposium, 1992. [13] C. E. Wu, Y.-H. Liu, and Y. Hsu, \Timestamp consistency and trace-driven analysis for distributed parallel systems," Proc. 1995 Int'l Parallel Processing Symposium, April 1995. [14] D. K. et. al, \Visualizing the execution of high performance fortran (hpf) programs," Proc. of 1995 Int'l Parallel Processing Symposium, April 1995. [15] P. C. et. al, \Parallel le systems for ibm sp computers," IBM System Journal, 1995. [16] V. Herrarte and E. Lusk, \Studying parallel program behavior with upshot," Tech. Rep. ANL{ 91/15, Mathematics and Computer Science Division, Argonne National Laboratory, 1991. [17] E. Karrels and E. Lusk, \Performance analysis of mpi programs," Proc. of the Workshop on Environments and Tools for Parallel Scienti c Computing, 1994. [18] M. Ridley, \Innovation and implementation: Adoptin and managing world wide web services in academic libraries," tech. rep., http: //www. Stars. com/, 1995. [19] A. Koopman and S. Hay, \Swim at your own risk - no librarian on duty: Large-scale application of mosaic in an academic library," tech. rep., http: //www. Stars. com/, 1995.