TWO-TIER CLIENT/SERVER EXAMPLE: A HUMAN RESOURCES SYSTEM

14.3 TWO-TIER CLIENT/SERVER EXAMPLE: A HUMAN RESOURCES SYSTEM

Consider a human resources (HR) application, configured as a two-tier client/server system, consisting of four client nodes and one server node, with traffic flows as shown in the schematic representation of Figure 14.5. This HR application supports a number of services (request types) related to the company employees, using a database server that maintains an HR database (HRDB) of employee-related information. Database transactions types have the attributes displayed in Table 14.1.

Service requests belong to the following types:

1. A request of type Add adds a new employee with all his/her information (name, address, phone, expertise, etc.) to the HRDB in a message size of 1024 bytes, and the system returns a confirmation message of size 256 bytes.

2. A request of type Delete deletes an employee entry (with all the related information) from the HRDB. The system returns a confirmation message of size 512 bytes.

3. A transaction of type Find finds the complete employee information in the HRDB, based on partial data (e.g., the name alone). The system returns a reply message of size 512 bytes.

376 Modeling Computer Information Systems Client

Nodes Server Node

Monitor

Network

Server Requests

Replies

Processes

Figure 14.5 Schematic representation of the HR client/server system.

Table 14.1 Transaction attributes of the HR application

Request Type Request Type

Reply Size (bytes) Number

Service Requested

Request Size

Add employee

512 3 Find

Delete employee

512 4 Search

Find employee

Search for employees

Disc({(0.2, 64), (0.3, 512), (0.3, 1024), (0.2, 2048)})

Table 14.2 Client-side service request profile

Client Node Request Interarrival Distribution Request Type Distribution (messages/millisecond)

4. A transaction of type Search searches the HRDB for all employees with common characteristics (e.g., same expertise, same department, etc.). The system returns a reply of random size; its (discrete) distribution is given in Table 14.1.

To characterize the traffic patterns in the system, we need to specify the arrival processes of all request types at each client node. Table 14.2 provides service request profiles. Note that the second column specifies the multiplexed request streams from each client node as Poisson processes with associated exponential interarrival time distributions. The type of any request in the corresponding multiplexed stream is specified by an associated discrete distribution in the third column.

The server node has a TP monitor that receives requests and routes them to the server process providing the requested service. There are two server processes, called sp1 and

Modeling Computer Information Systems 377 sp2; the former provides services of types Add and Delete, and the latter provides

services of types Find and Search. The elapsed times for each service request type (including all CPU times and database-related times) are displayed in Table 14.3.

On service completion, replies to service requests are returned to the TP monitor, which in turn sends them back to their respective clients over the transmission network. The service time at the TP monitor is 1 millisecond per visit, while the BWC of the transmission network is 200 bytes/msec at 70% MTE.

Table 14.3 Elapsed times for service request types

Request Type

Elapsed Time (milliseconds) Number

Request Type Name

Figure 14.6 Arena model of the HR client/server system.

378 Modeling Computer Information Systems An Arena model of the system in Figure 14.5 is displayed in Figure 14.6. The Arena

model consists of three labeled segments: client nodes, transmission network, and server node. We now proceed to describe each segment of the model, along with its simulation results.

14.3.1 C LIENT N ODES S EGMENT

Client nodes are modeled by the four Create modules, called Client 1, Client 2, Client 3, and Client 4, with the associated interarrival times specified in Table 14.2. Each Create module is connected to a corresponding Assign module, which sets the request entity attributes ArrTime (arrival time), Service Requested (request type number), and Type (1 codes for requests and 2 for replies).

The dialog box of the Assign module, called Assign Service Requested_1 (for client node 1), is displayed in Figure 14.7. As usual, the arriving transaction entity , s ArrTime attribute is set to Tnow (its arrival time). Its Service_Requested attribute is sampled from the discrete distribution specified in Table 14.2, with service coded by the integers 1, 2,

3, and 4; these integers correspond to the request type numbers in Tables 14.1 through

14.3. Finally, the Type field is set to 1 to indicate that it is a service request. Once the request is processed, the transaction entity would change its Type attribute to 2 to indicate its reply status.

14.3.2 C OMMUNICATIONS N ETWORK S EGMENT

The transmission network segment provides a simplified model of the entire com- munications network. It consists of a Process module to model transmission delay, and a Decide module to model transaction routing.

Figure 14.7 Dialog box of the Assign module Assign Service Requested_1.

Modeling Computer Information Systems 379

Figure 14.8 Dialog box of the Process module Com_Network.

Figure 14.8 displays the dialog box of the Process module, called Com_Network, which receives transaction entities from the two other segments. Here, the selected Action field option, Seize Delay Release, models the contention for the transmission resource, called Network (Resources field), and its seizure models the onset of actual transmission, which lasts until this resource’s release.

Since both requests (on their way to the server node) and replies (on their way back to the client nodes) use this module for transmission, the corresponding message lengths (and subsequently transmission times) depend on both their service type and their transaction type (request or reply). For this reason, the Expression option was selected in the Delay Type field, and the Expression field specifies the delay time as

ð ðType ¼¼ 1Þ Request_ Size ðService_ Requested Þ þ ðType ¼¼ 2Þ Reply_ Size ðService_ RequestedÞÞ

ð0:7 200 Þ In this expression, the first two lines determine the appropriate message size as a

function of the attributes Type (request or reply) and Service_Requested (service type). Finally, in the third line, the message size is divided by the product of MTE (70%) and BWC (200 bytes/msec), thereby yielding the effective transmission rate. Arena

380 Modeling Computer Information Systems

Figure 14.9 Dialog spreadsheet of the Expression module spreadsheet (left) and the Expressions Values dialog spreadsheet for specifying message sizes by type and service type (right).

does not support time units smaller than seconds, so for convenience, the model uses the minute unit as a millisecond unit.

Note that Request_Size and Reply_Size are used in the previous expression to retrieve the associated request size and reply size, respectively, as function of service type. Figure 14.9 displays the spreadsheet view of these expressions, using the Expression module from the Advanced Process template panel. The Expression module spreadsheet view at the left declares each of the two expressions, Request_Size and Reply_Size, to be

a table with four rows (one for each service type) and one column (for the correspond- ing message size). The specification of the table corresponding to the expression

Request_Size is displayed as an example on the right. After its transmission delay at module Com_Network, each transaction entity proceeds to the Decide module, called Dispatch Requests and Replies in Network, to

be dispatched to its requisite type-dependent destination. More specifically, the Type attribute is checked, and a service request (Type ¼ 1) is dispatched to the server node for service, while a reply (Type ¼ 2) is dispatched to the Record module, called Record Response Times, in the client nodes segment to tally its response time. The transaction entity then leaves the model via a Dispose module. In more realistic modeling scenarios, the replies would be routed back to their client node of origination to be processed, record their response times, and then be disposed of.

14.3.3 S ERVER N ODE S EGMENT

The server node segment processes service requests. It executes service requests brought in by request transactions, and dispatches them to the client nodes segment as reply transactions.

An incoming service request entity first enters the Process module, called Transac- tion Monitor, whose dialog box is displayed in Figure 14.10. Recall that the task of the TP monitor is to dispatch an incoming request to an appropriate server process, depending on the service type requested. All incoming request entities contend for the resource, called Monitor, which is governed by the now familiar Seize Delay Release option in the Action field. The delay time that models monitor processing time is precisely 1 millisecond, as indicated by the Constant option in the Delay Type field and the Value field.

Note carefully that the TP monitor handles both requests and replies — it dispatches requests to server processes and replies to the transmission network. The task of

dispatching requests to the appropriate server process is carried out in the Decide module, called Dispatch Requests for Services in Server Node, whose dialog box is displayed in Figure 14.11.

Modeling Computer Information Systems 381

Figure 14.10 Dialog box of the Process module Transaction Monitor.

Figure 14.11 Dialog box of the Decide module Dispatch Requests for Services in Server Node.

382 Modeling Computer Information Systems The N-Way by Condition option in the Type field of the Decide module serves as

a switch for dispatching incoming transaction entities. The dispatching decision computed in the Conditions field is as follows:

1. The Type attribute is checked first. If the predicate Type ¼¼ 2 is true, then this entity is a reply transaction to be sent to the transmission network. Otherwise, if Type ¼¼ 1 is true, then the entity is a request transaction, and the Service_Requested attribute is checked in the 4 items below.

2. If Service_Requested ¼¼ 1 is true (Add request), then the transaction entity is dispatched to server process 1.

3. If Service_Requested ¼¼ 2 is true (Delete request), then the transaction entity is dispatched to server process 1.

4. If Service_Requested ¼¼ 3 is true (Find request), then the transaction entity is dispatched to server process 2.

5. If Service_Requested ¼¼ 4 is true (Search request), then the transaction entity is dispatched to server process 2.

The server processes are modeled by the Process modules, called Server Process_1 and Server Process_2, with respective resources SP_1 and SP_2. The dialog box of module Server Process_1 is displayed in Figure 14.12. Here again, the Seize Delay Release option was selected in the Action field, where incoming transactions entities contend for resource SP_1. Since the processing time is request dependent,

Figure 14.12 Dialog box of the Process module Server Process_1.

Modeling Computer Information Systems 383 the processing delay is specified by an expression that assigns a 10-millisecond delay

to Add requests (service type 1) and an 8-millisecond delay to Delete requests (service type 2). The dialog box of module Server Process_2 is analogous.

Following service completion, the transaction entity enters the Assign module, called Change Type, where its Type attribute is changed from 1 (request) to 2 (reply). It then proceeds to the Process module, called Transaction Monitor, and after a brief process- ing delay, it enters the Decide module, called Dispatch Requests for Services in Server Node, which sends it to the transmission network segment for transmission back to the client nodes segment.

14.3.4 S IMULATION R ESULTS

The model of Figure 14.6 was simulated for 1 hour (3,600,000 milliseconds) of operation. The simulation results are displayed in Figure 14.13. An examination of the

Figure 14.13 Simulation results for the Arena model of the HR client/server system.

384 Modeling Computer Information Systems simulation statistics reveals that the transmission network is busy 60% of the time, with

an average buffer delay of 4.4 milliseconds. The TP monitor utilization of 14% shows that it is not congested.

Note that server process SP_2 is more than twice busier than server process SP_1. This is due to the much longer elapsed times of services of type Find and Search as compared to services of type Add and Delete. Consequently, the average buffer delay at the queue of SP_2 is over 35 milliseconds as compared to a fraction of a millisecond at the queue of SP_1.

The pooled response time of transactions varied between 16 milliseconds and 462 milliseconds with an average of 53.1 milliseconds and a tight confidence interval with

a half-width of some 0.80 milliseconds. Clearly, some transactions experienced un- acceptably long response times. To identify the system bottleneck, we recommend that response time statistics be collected and examined by service type (using the Set module to obtain statistics for each service type separately). Once the bottleneck is identified, additional service capacity can be added in the form of additional server processes and

a modified allocation scheme of service types. For example, increasing the server capacity of resource SP_2 from 1 to 2 would reduce the average pooled response time from 53.1 milliseconds to 36.3 milliseconds. Any further analysis is left to the reader.