CLIENT/SERVER SYSTEM ARCHITECTURES

14.1 CLIENT/SERVER SYSTEM ARCHITECTURES

Recall that in a client/server system, a client computer sends requests for specific services, while a server computer listens to client requests, processes them, and sends the response back to the client. The associated application program and its computa- tional tasks are split between client and server so as to speed up response times by reducing communications overhead or achieving a degree of parallelism. Accordingly, the generally less-powerful client machine might be assigned some query preprocessing and post-processing tasks, while the generally more powerful server machine usually performs the core computational tasks. A client may request the services of multiple servers sequentially or in parallel. Examples of common servers include file servers and database servers, while examples of widely deployed client/server systems include trans- action processing (TP) systems, such as online banking systems, Web-based online shop- ping software, inventory management software, and many others (see Gray and Reuter [1993], Hennessy and Patterson [1996], Menasce and Almeida [1998], Orfali et al. [1996]).

A client/server system is said to have an n-tier architecture depending on how clients and servers interact with each other. For instance, in a two-tier architecture, the client side utilizes a user interface that permits direct communication with the server host. Even though there may be more than one server, clients maintain direct connections with remote servers over the underlying communications network. Two-tier architec- tures seem to be appropriate for systems with up to about 100 clients.

Three-tier architectures emerged to overcome the limitations of two-tier architectures (Menasce and Almeida [1998]). In this architecture, a middle tier is added between the client side and the server side, which typically involves transaction processing, or

372 Modeling Computer Information Systems Client Nodes

Server Nodes

TP Monitor

Transmission

Network

Request Reply

Figure 14.1 Schematic representation of a three-tier client/server system.

monitoring functionality. This middle tier may implement message queueing, task sched- uling, prioritization of work in progress and application processing, or some combination of these. The middle tier thus interfaces the client side to the server side, but this interfacing is transparent to clients. The software implementing three-tier architectures is commonly known as middleware.

Figure 14.1 depicts a simple three-tier architecture in which the outer layers host computer processes and transaction queues while the middle layer monitors and routes transactions. Here, the TP monitor receives the transactions, queues them up for service, manages their path to completion, and finally, sends the reply back to the client.

For more information on client/server architectures and middleware, see, for example, Andrade et al. (1996) and Comer (1997). The elements of client/server systems will be described next.

14.1.1 M ESSAGE -B ASED C OMMUNICATIONS

Clients and servers communicate via messages, which constitute client requests and server replies. Each message has origination and destination information, as well as a message body. A client message issues a request for a specific service from a server host (e.g., a database service). The reply from the server is packaged as another message, and sent back to the client. Thus, there are as many request types as there are services. However, in the course of serving a request, a server may itself act as a client by requesting services from other servers. For simplicity, we will not consider such secondary requests in this chapter.

Online banking is a common example involving message-based communications. Users might query their account status at an ATM (automatic teller machine) or access a secure website for the same. Such a query might be “show me the balance of my account” or “show me the last 15 cashed checks.” The reply may be printed on paper or displayed on a computer monitor.

14.1.2 C LIENT H OSTS

Client hosts are computers that issue service requests initiated by computer programs or by customers connected to the host. As shown in Figure 14.2, requests emanating

Modeling Computer Information Systems 373

Client Local Process

CPU

Message CPU Traffic

Queue

Figure 14.2 Schematic representation of a client host.

from a client host are generated by one or more client processes residing on the client host.

The request traffic stream generated by client processes may consist of a single request type, or more generally, a mix of types k ¼ 1, . . . , N, where the rate of the stream of type k requests is l k . For modeling purposes, it is common to merge (multiplex) all request streams into a single stream. In that case, the probability q k that

a request in the multiplexed stream is of type k is given by

that is, as the relative rate of stream k in the multiplexed stream.

A generated request undergoes local preprocessing at the client host, and then is transmitted to a server host (usually over a communications network, unless the client and server are on the same host). On service completion, the reply is transmitted back to the client host and undergoes local post-processing, thereby completing the request/ reply cycle. The response time of a request is the total time elapsed from the moment of submitting it (just before local pre-processing) until the moment the reply becomes available (just after local post-processing). Response times constitute the most critical performance measure in client/server systems.

14.1.3 S ERVER H OSTS

The bulk of request processing is typically performed at the server host. In addition to maintaining application code there, servers also call for a large amount of adminis- trative operations. Figure 14.3 depicts a schematic representation of a typical server node.

Transaction Monitor CPU

Message Traffic

Server Processes

Figure 14.3 Schematic representation of a server host.

374 Modeling Computer Information Systems In its simplest form, a server node consists of one or more CPUs and a number of

server processes that actually execute the code for the services requested by clients. The server processes and the CPU each have a message queue in front of them. Each server process is enabled to perform a specific set of services.

A transaction processing (TP) monitor process (TP monitor, for short) directs the incoming message traffic to the appropriate server process depending on the type of service requested. Since there may be other transactions (requests) awaiting their turn at the server process, incoming requests may have to be queued for service. When an incoming request eventually gets hold of the server process, it is immediately moved to the CPU queue for execution. Internally, such execution may follow a complex scenario. For example, the service of a request may generate read and/or write requests to local disks (I/O in computer jargon), or it may request information from a local or remote database. Eventually, the request transaction completes its service, and the server process sends the appropriate reply back to the monitor. The monitor then arranges to transmit the reply back to the client over the underlying network. The elapsed time of the request transaction at the server process is the total time elapsed from the moment it starts executing at the server’s CPU until the moment it proceeds to the monitor for transmission back to the client. During the service time of a request the server process does not start serving another one.

A detailed model of the server host would have to account for the sequence of I/O requests and CPU processing, including service disciplines such as FIFO or round robin (see Section 8.2.3). This kind of detailed modeling will not be employed here. Rather, we will collapse all of this detail into a service time distribution for the sake of simplicity. Service distributions will be given as input parameters.

In reality, servers are considerably more complicated in the sense that they have software components to monitor each other and transmit client requests among them- selves for secondary services. However, this complexity is transparent to the client. Since the objective here is to model client/server systems for Monte Carlo discrete- event simulation, we will be content to use this simplified representation in order to construct Arena models that can be simulated in the student version of Arena.