In the classic client-server (CS) computing paradigm, one or more clients and one or more servers, along with the underlying operating system, interprocess communication system, and network protocols, form a composite system allowing distributed computation [1, 18]. A client is defined as a requester of services and a server as the provider of services. A client is a process that interacts with the user and is responsible for 1) implementing the user interface, 2) generating requests to the server based on user requests, 3) transmitting the requests to the server via a suitable interprocess communication mechanism, and 4) receiving the results from the server and presenting them to the user. A server is a process, or set of processes, that collectively provide services to the clients in a manner that shields the client from the details of the architecture of the server's hardware/software environment. A server does not initiate any dialogue with a client; it only responds to requests . Servers control access to shared resources, such as file systems, databases, gateways to wide area networks (WANs), and mail systems. Remote Procedure Calls (RPCs) or structured query language (SQL) statements are typically used by clients to request services from servers in a client-server system. Usually, clients and servers are located on different machines interconnected by a LAN or WAN. Figure 14.2 shows a request generated at the client and serviced by the server.
Figure 14.2. Client-server interaction.
For instance, a file service request (e.g., "read block x from file foo") is invoked at the client as an RPC. The RPC obtains service from a file server and returns the result, via the network, to the calling client. Several network messages may be necessary to send the result from the server to the client.
14.2.1 Client-Server Performance
Several factors influence the performance of a client-server application. One of them is the network latency, which directly affects end-user performance. As depicted in Figure 14.3, the response time of a transaction in a CS system can be decomposed as
Figure 14.3. Client-server architecture.
The client delay includes processor time at the client workstation plus any disk time at the client workstation. The client processor time accounts for the time necessary to execute the user interface code, plus local preparation of the service request at the application level, plus the time necessary to process all protocol levels from the session layer down to the transport/network layer (e.g., TCP/IP ). Usually, client workstations have local disks, for operating system purposes, to hold temporary files, and to cache files in order to reduce traffic with the server. The delay at the client is independent of the total system load and consists only of the service demands at the client.
The network delay is composed of 1) the time necessary to get access to the network through the appropriate medium access protocol (MAC), such as token-ring or CSMA/CD (Ethernet) , and 2) the time necessary to transmit the service request packets through the network. The first component of the network delay (network access time) is clearly dependent on the network load. For instance, the number of collisions in a CSMA/CD network increases as more stations attempt to transmit at the same time. This activity is appropriately modeled using a load-dependent server. Similarly, the time for the token to return to a station, in a token-ring network, increases with the number of stations. Also, the server delay is decomposed into server processor time plus disk service time. Queues may form at these devices since the server is a shared resource being used by all clients. The service demand at the server accounts for the time necessary to process the incoming requests from the clients plus the time necessary to process all the protocol layers at the server side. The service demands at the server disks depend on the type of service provided by the server. For instance, a file server may provide services such as reading or writing a block to a file, while a database server may provide a service such as executing an SQL query involving joining two or more database tables, which could result in numerous physical I/Os. The performance of CS systems is greatly influenced by the congestion levels at the shared resources (e.g., network, server processor, and server disks).
14.2.2 Design Questions for a CS Application
Consider a company that is designing a data center to process credit inquiries. To support the business, the CS application should provide timely information to its customers. Good performance (e.g., response time) is a necessity for the company to attract customers. The company is planning an architecture that scales to serve several thousands of requests without sacrificing performance. The data center has other QoS goals, such as 24x7 operation, 99% availability, and high reliability. The center consists of a CS system with a relational database. Clients generate financial requests. Each financial request generates SQL requests to the database. Client workstations are connected to the database server via a 100 Mbps LAN network. The queuing model that represents the CS system is depicted in Figure 14.4. For the sake of simplicity, assume that all financial requests have similar resource demands and can be characterized by a single class. The queuing model has a total of M customers in the population (the number of client workstations) that generate a single class of requests. It is also assumed that each client workstation cannot submit a new SQL request until it receives the response to the previous request. The client workstations are represented by a single delay device with service demand equal to Dcl. This represents the time a client spends before submitting the next request to the server. The LAN is modeled by a load-dependent device and the database server by two load independent devices. Typical design questions that could be answered with the help of a performance model are:
Figure 14.4. Client-server queuing model.
14.2.3 System and Workload Specification
After building a prototype for the new application, service demands are measured for the various devices. The work unit for the workload characterization is an SQL request generated by financial requests. Consider the following SQL request-related parameters:
Consider the following network-related parameters:
The average number of packets, NPsql, generated per SQL request can be computed as follows. Assume that the request from the client to the server consists of a single packet. The number of packets necessary to send the result from the server to the client is given by [Lsql/Ld]. Thus,
Table 14.1 shows the values of all measured and computed parameters for the CS model.
Queuing devices represent the processor and disk at the DB server. The service time per packet at the network is dependent on the number of workstations contending for it. As shown in Figure 14.4, the LAN is represented by a load-dependent device to indicate that, as the load on the network increases, the throughput on the LAN decreases due to the additional number of collisions experienced on the network medium.