THREE-TIER CLIENT/SERVER EXAMPLE: AN ONLINE BOOKSELLER SYSTEM

14.4 THREE-TIER CLIENT/SERVER EXAMPLE: AN ONLINE BOOKSELLER SYSTEM

Consider a bookseller’s e-business network, configured as a three-tier client/server system, as shown in Figure 14.14. The system consists of a cluster of two server nodes,

linked by a transmission network and governed by TP middleware that dynamically balances the queue sizes of server processes in the cluster.

Each server node is depicted in Figure 14.14 by a circle that houses a number of server processes (in our case, two server processes per node). Server processes provide a number of services, and each server–process queue is a priority queue (requests are served FIFO within priority classes). The elapsed time for each service is random. The elapsed-time distributions are displayed in Table 14.4 along with priority information (smaller priority numbers indicate higher priorities).

Server Node 1

Transmission Network

Figure 14.14 Layout of a bookseller’s e-business network.

Modeling Computer Information Systems 385

Table 14.4 Service data by server node

Service Service Name

Elapsed Time at Server Elapsed Time at Server Number

Service

Node 2 (milliseconds) 1 best sellers (BS)

Priority

Node 1 (milliseconds)

Unif(18, 28) 2 new releases (NR)

5 Unif(10, 20)

Unif(21, 31) 3 book search (BE)

4 Unif(13, 23)

Unif(10, 20) 4 view cart (VC)

3 Unif(4, 14)

Unif(7, 17) 5 go to cashier (GC)

A number of client nodes are connected to each server node. However, when a service request arrives at a server node, it is not necessarily processed there. Rather, the TP monitor decides where it is to be processed by selecting a server process (anywhere in the system) with the minimal queue size. In reality, dynamic load balancing aims to equalize the queue workload (the total service time needed to serve all transactions in the queue, usually excluding the one in service). However, for the sake of simplicity, this model will balance only queue sizes.

Letting SP_ij denote server process j at node i (i, j ¼ 1,2), Table 14.5 displays the allocation of services to each of the two server processes at each server node, and consequently, the workload distribution in the system.

The arrival streams of service requests are multiplexed into two arrival streams, one for each server node (see Figure 14.14). Request interarrival times are iid, exponentially distributed with service-dependent rates. Every request message is assumed to have a fixed size of 1024 bytes. The service discipline is FIFO within priority classes, that is, requests queue up for service at a server process according to their arrival times within their priority class (recall that smaller priority values represent higher priorities). Table 14.6 displays the interarrival time distributions of service requests and their mix at each server node.

Once a service request completes processing, a reply is sent back to the client node. Reply messages have a random size (1024 bytes or 8096 bytes). The reply size distribution is DISC({(0.45, 1024), (0.55, 8096)}). Finally, we are interested in the response times of service requests by type, and delays in server process queues.

In reality, the system’s architecture is considerably more complicated; thus, Figure

14.14 is a simplified abstraction of the real system, suitable for the Arena student version. Nevertheless, the simplified model captures sufficient real-life detail to be useful.

Next, we will walk through an Arena model of the bookseller’s e-business system. The model consists of three segments: request arrivals, the transmission network, and

Table 14.5 Allocation of services to server nodes

Client Node / Server Process Service Name node 1 / SP_11

BS, NR ,BE node 1 / SP_12

VC, GC node 2 / SP_21

BS, NR node 2 / SP_22

BE, VC, GC

386 Modeling Computer Information Systems Table 14.6

Request interarrival time distributions and mix distributions by server node

Node 2 Distribution of Request Interarrival Times

Node 1

Expo(1/18) (milliseconds) Distribution of Requests in Arrival Streams (percentages in mix):

Expo(1/12)

BS 0.20 0.23 NR

0.15 0.25 BE 0.30 0.25 VC 0.05 0.07 GC 0.30 0.20

server nodes (all server nodes have an identical structure). We now proceed to describe each segment of the model, along with its simulation results.

14.4.1 R EQUEST A RRIVALS AND T RANSMISSION N ETWORK S EGMENT

An Arena model of the request arrivals and transmission network segment is depicted in Figure 14.15. Client service requests are generated by the Create modules, called Client Requests Node 1 and Client Requests Node 2, as two multiplexed streams.

Figure 14.16 displays the dialog box of the first Create module. Note that here and elsewhere, the base time unit of the model is seconds in lieu of milliseconds (again for convenience). Note further that the interarrival times are iid and exponentially distrib- uted, so that the arrival streams constitute Poisson processes. Recall also that the multiplexing of Poisson processes yields aggregate Poisson process (see Section

Figure 14.15 Arena model of the request arrivals and transmission network segment for the bookseller’s e-business system.

Modeling Computer Information Systems 387

Figure 14.16 Dialog box of the Create module Client Requests Node 1.

3.9.2). Thus, each of the two Create modules may be validly defined to generate a combined Poisson stream of requests from multiple client nodes.

Generated request transaction entities proceed to the corresponding Assign module, called Request Attributes 1 or Request Attributes 2, to assign values to a number of attributes. Figure 14.17 displays the dialog box of the second Assign module. Each arriving request entity is independently assigned a service type from a discrete distri- bution in attribute Svc (from Table 14.6), a corresponding priority (from Table 14.4) in attribute Priority, the arrival time (Tnow) in attribute Arr_Time, a message type (variable

Figure 14.17 Dialog box of the Assign module Request Attributes 2.

388 Modeling Computer Information Systems Req for request or variable Rep for reply) in attribute Type, and the appropriate message

sizes from a discrete distribution in attributes Req_Mes_Size and Rep_Mes_Size. Finally, the attributes Dispatched and Destination maintain routing information for each transaction entity during its sojourn in the system. To understand their role in the model, recall that each transaction entity is affiliated on arrival with a particular server node, and this information is assigned to attribute Destination (1 codes for node 1, and 2 for node 2). These values subsequently serve as station numbers in the Route module called Message Transmission. When referencing station numbers in the model, the modeler should fetch the right numbers from the Stations element in the corresponding experiment file filename.exp. Stations are listed in ascending order and their index starts at 1. The Dispatched attribute maintains routing information of an arriving transaction entity. Initially (at the client node), the Dispatched attribute is assigned the value 0 (see Figure 14.17); subsequently, if the transaction entity is dispatched to receive service in another server node, then the Dispatched attribute is assigned the value 1. On each entry in a server node, the Dispatched attribute is examined by the node’s TP monitor to determine whether the transaction entity was dispatched from another node. If it was, then the transaction entity will be served in the current node, and will not be dispatched again (otherwise, a transaction might be dispatched forever, possibly creat- ing an “infinite loop” problem). The variable Req is initialized to 1 (to code for a request), while Rep is initialized to 2 (to code for a reply). Additionally, the variable BWC (representing the bandwidth capacity) is initialized to 1250 bytes/msec. These initializations are made in the Variable module spreadsheet.

14.4.2 T RANSMISSION N ETWORK S EGMENT

The Arena model of the transmission network segment is depicted in Figure 14.15. Once the transaction entity leaves the Assign module (Request Attributes 1 or Request Attributes 2), it enters the transmission network by proceeding to the Station module, called Com_Net Entrance, whose dialog box is displayed in Figure 14.18. While entities often enter a Station module from a Route module (via a “long jump”), here client nodes are directly connected to the Station module Com_Net Entrance to reduce the number of modules in the model. To model a transmission delay in the network, the transaction entity next enters the Process module, called Network, whose dialog box is displayed in Figure 14.19. Transmission is modeled as FIFO contention for the resource, called Net_server, via the usual Seize Delay Release option in the Action field to obtain network delay statistics per transaction entity. Since transmission times are size depend- ent, the transmission delay is computed as an expression utilizing the attributes Req_Mes_Size and Rep_Mes_Size, which hold the requisite message size. Thus, the expression in the Expression field specifies the transmission time as

ððType ¼¼ ReqÞ Req_ Mes_ Size þ ðType ¼¼ RepÞ Rep_ Mes_ Size Þ=BWC=0:8: Here the message size is selected by message type, and the requisite service time is

obtained by dividing the message size by the effective bandwidth capacity BWC * 0.80, where 0.80 is the MTE parameter.

Modeling Computer Information Systems 389

Figure 14.18 Dialog box of the Station module Com_Net Entrance.

Figure 14.19 Dialog box of the Process module Network.

390 Modeling Computer Information Systems

Figure 14.20 Dialog box of the Decide module Routing Map.

Since both requests and replies are transmitted across the network, transactions are routed to their destinations based on their type by the Decide module, called Routing Map, whose dialog box is displayed in Figure 14.20. The 2-Way by Condition option in the Type field specifies two branches. If the entity is a reply transaction, then it is dispatched to the Record module, called Response Time Tally, to record its response time, from which it proceeds to a Dispose module. (We mentioned earlier that in reality,

a reply transaction is dispatched back to its original client node before tallying its response time, but here we use a simplified model to economize on model size.) If the entity is a request transaction, then it is dispatched to the Route module called Message Transmission, whose dialog box is displayed in Figure 14.21. Here,

Figure 14.21 Dialog box of the Route module Message Transmission.

Modeling Computer Information Systems 391

Figure 14.22 Dialog box of the Record module Response Time Tally.

Figure 14.23 Dialog spreadsheet of the Set module (left) of the Members dialog spreadsheet for specifying the set Response Times (right).

a request transaction entity is routed to its destination station whose ID is stored in the Destination attribute of the entity. Note carefully that the zero routing time in the Route Time field does not represent transmission delay. The actual transmission delay is modeled in the Process module Network as explained earlier.

The Record module, called Response Time Tally, records transaction entities , response times into a tally set, called Response Times, whose dialog box is displayed in Figure 14.22. Note that response times are collected by service type in the tally set, called Response Times, and the Set Index field specifies the service type attribute Svc as an index to access the requisite tally.

The specification of the tally set is made in the Set module whose spreadsheet view is displayed in Figure 14.23 (left) and its Members dialog spreadsheet (right).

14.4.3 S ERVER N ODES S EGMENT

The remaining segment models server nodes, but since they are analogous, we will only review one of them. Accordingly, Figure 14.24 depicts an Arena model of server node 1.

392 Modeling Computer Information Systems

Figure 14.24 Arena model of server node 1 of the bookseller’s e-business system.

Figure 14.25 Dialog box of the Decide module Is It a Dispatched Job_1.

Transaction entities enter the server node at the Station module, called Server- Node_1, and then proceed to the Decide module, called Is It a Dispatched Job_1,

whose dialog box is displayed in Figure 14.25. The role of this module is to examine incoming transaction entities and to separate those arriving directly from client nodes from those dispatched from server node 2 by the TP monitor. This separation is

Modeling Computer Information Systems 393

Figure 14.26 Dialog box of the Process module TPM_1.

necessary, since the corresponding logic sequences are different, as explained below (see also the discussion at the end of Section 14.4.1).

Suppose the value of the Dispatched attribute of the incoming transaction entity is zero. Then the entity is a request transaction arriving from a client node. This transac- tion entity is immediately routed to the corresponding TP monitor at the Process module, called TPM_1, whose dialog box is displayed in Figure 14.26. Note that this Process module represents the initial TP monitor processing, but does not model contention, since the Action field setting is the Delay option. The modeling justification for this choice is that the processing time of a routing decision is just 0.5 milliseconds, which is tiny relative to the means of interarrival times. Consequently, queueing delays here are highly unlikely and can be ignored for all practical purposes.

Following the initial TP monitor processing, a request transaction entity proceeds with the main routing processing by entering a Search module (from the Advanced Process template panel), which specifies a search for the optimal server process (one with the minimal queue size in the cluster to be assigned to this request trans- action). Figure 14.27 displays the dialog box of the corresponding Search module, called BB_1, commonly known as the bulletin board in middleware parlance. Here, the Type field specifies a search type option (available options are Search a Batch, Search a Queue, or Search an Expression). The Search Condition field is used to specify a search criterion, while the Starting Value and Ending Value fields specify

394 Modeling Computer Information Systems

Figure 14.27 Dialog box of the Search module BB_1.

the search range; these values also determine if the range is searched in ascending (increasing) or descending (decreasing) order. Thus, a search succeeds if the search condition is satisfied for some item in the search range, and it fails otherwise. The search result is always an integer assigned to the system variable J, and its interpretation depends on the search type as follows:

If the search fails, then J is set to 0. For the Search a Batch option, a batch (group) of entities is searched for compliance with the search condition over the range of ranks specified by the Starting Value and Ending Value fields. If the search succeeds, then J is set to the rank of the first entity found in the batch. For the Search a Queue option, a queue of entities is searched for compliance with the search condition over the range of ranks specified by the Starting Value and Ending Value fields. If the search succeeds, then J is set to the rank of the first entity found in the queue. For the Search an Expression option, a vector of expressions (such as in the Expression Values column of the Expression module spreadsheet or in the Members column of the Advanced Set module spreadsheet) is searched for compliance with the search condi- tion over the range of indices specified by the Starting Value and Ending Value fields. If the search succeeds, then J is set to the index value of the first expression found in the module. See Figures 14.27 and 14.28 for an example.

The search procedure itself unfolds as follows. When an entity arrives in a Search module, the system variable J is set to the value in the Starting Value field. The search criterion in the Search Condition field is then checked. If true, the search ends and the variable J returns the search result. Otherwise, J is incremented (or decremented) by 1, and the search condition is rechecked as before. If the search reaches the value in the

Modeling Computer Information Systems 395

Figure 14.28 Dialog spreadsheet of the Expression module (bottom) and the Expression Values dialog spreadsheet for specifying the expression vector SP_Queue_Occupancy (top).

Ending Value field, without finding an entry that satisfies the search condition, the variable J is set to 0 to indicate that the search failed. For example, an ascending search of a queue for the entity with the highest Age attribute is specified by the search condition MAX(Age) over the rank range 1 to NQ (the name of the queue is specified in the Queue Name field). As another example, a descending expression search for reordering a product in an inventory is specified by the search condition

Inventory Level ðJÞ < Reorder PointðJÞ

over the index range 8, . . . , 2. In our model, Figure 14.27 specifies an ascending expression search for a server process with the minimal occupancy, via the search condition expression

MIN ðSP_ Queue_ OccupancyðJÞÞ;

where SP_Queue_Occupancy is an expression. As shown at the bottom of Figure 14.28, the expression vector SP_Queue_Occupancy is a vector of four rows, each holding

a separate expression. Consequently, the search procedure will scan the rows (with the J variable holding the current row index) and return the row index with the minimal value. It can be seen that all rows are similarly structured. Each row returns the queue size of a specific server process, provided that the service request of a transaction entity belongs to a specific subset of services; otherwise, it returns a large number (1000), which is larger than any queue size. Consequently, if the transaction entity’s service request (in its Svc attribute) is not in that subset, the MIN search condition for that row will deliberately fail. For instance, the second row returns the queue size of server process S_Proc_12 for service types 4 and 5, and 1000 for all other services. When the search over the rows of SP_Queue_Occupancy is terminated, the variable J will contain the index of the destination server process with the smallest queue size, as required.

Next, the request transaction entity moves from the Search module to the Assign module, called Assign Dest_1, whose dialog box is displayed in Figure 14.29. Here, the system variable J is assigned to the transaction entity’s attribute Dest, to be used in dispatching that transaction entity to the requisite server process (which may reside in either of the server nodes).

396 Modeling Computer Information Systems

Figure 14.29 Dialog box of the Assign module Assign Dest_1.

Figure 14.30 Dialog box of the Decide module Process Here_1.

The actual dispatching is carried out next in the Decide module, called Process Here_1, whose dialog box is displayed in Figure 14.30. If the value of the Dest attribute of a request transaction entity is 1 or 2, then this module dispatches it to Process module S_Proc_11 (modeling SP_11) or to Process module S_Proc_12 (modeling SP_12), respectively. However, if Dest > 2 is true, then this indicates that the requisite server process is in the other server node (in our case, Server Node 2), and this module dispatches the transaction entity to the Assign module, called Destination_1, where its Destination attribute is set to 2.

Figure 14.31 displays the dialog box of the Process module S_Proc_11. Contention for the server process resource SP_11 is modeled by the Seize Delay Release option in the Action field. The service-dependent elapsed time is specified by the expression

Modeling Computer Information Systems 397

Figure 14.31 Dialog box of the Process module S_Proc_11.

UNIF ð10; 20Þ ðSvc ¼¼ 1Þ þ UNIFð13; 23Þ ðSvc ¼¼ 2Þ þ UNIFð4; 14Þ ðSvc ¼¼ 3Þ; which implements the relevant data from Table 14.4.

Recall that the transmission network queue is served in FIFO order, while the order of service in the server process queues is governed by a priority discipline (see Table

14.4 and Figure 14.17). These service disciplines are specified in the Queue module spreadsheet by selecting the appropriate options in the Type column and the Attribute Name column, as shown in Figure 14.32.

Recall that once the service request completes execution, the requesting transaction needs to be sent back to the origination client as a reply. To this end, the transaction entity first enters the Assign module, called Change Type_1, whose dialog box is displayed in Figure 14.33. The Type attribute is set here to the variable Rep to indicate

a change of the transaction type from request to reply. Next, to model the transmission to its associated client node, the reply transaction entity proceeds to the Route module, called Route to Network_1, whose dialog box is displayed in Figure 14.34. It is then routed in zero time to Station module Com_Net Entrance, from which it proceeds to the Process module Network for the actual network contention and transmission delay, as described in Section 14.4.2. Recall again that the seconds time unit actually stands for milliseconds.

398 Modeling Computer Information Systems

Figure 14.32 Dialog spreadsheet of the Queue module specifying the server process queues and transmission network queue properties.

Figure 14.33 Dialog box of the Assign module Change Type_1.

Modeling Computer Information Systems 399

14.4.4 S IMULATION R ESULTS

The Arena model of the bookseller’s e-business system was simulated for a 1-hour period (3,600,000 milliseconds) of operation. The simulation results are displayed in

Figure 14.35. Observe that the network resource Net_Server is busy about 84% of the time, resulting in average network delay of around 13 milliseconds across all transaction entities. These delays are quite insignificant, and entirely acceptable.

Figure 14.35 Simulation results for the Arena model of the bookseller’s e-business system.

400 Modeling Computer Information Systems The utilizations of server processes SP_11 through SP_22 vary widely. Note that

each first server process at each server node (SP_11 and SP_21) is much busier (over 58% utilization) than the second process in that node (SP_12 and SP_22). This is due to the fact that service types with longer elapsed times are allocated to the first server process at each server node.

Delays in server process queues are fairly proportional to the corresponding server process utilization. The average delay in the queue of server process SP_21 is about

21 milliseconds, while the average delay in server process SP_22 is a mere 2.65 milliseconds. These delays directly affect the response times of customer requests. For example, best seller (BS) and new releases (NR) services have longer elapsed times than the other services. Consequently, the server processes providing these services are the busiest, and the corresponding response times (about 71 and 62 milliseconds, respectively) are significantly larger than those of the other services.

This bookseller’s e-business example clearly shows the importance of workload allocation in client/server systems, and especially in mission-critical applications.

Delays in server process queues and transmission network queues constitute major components of response times. Clearly, it is desirable to minimize these delays in order to reduce overall response times. A more balanced allocation of workload to servers would help reduce server process delays, and in turn reduce response times. On the other hand, to improve the transmission network performance, one may have to upgrade the network by adding additional equipment (routers, switches, etc.) to reduce network delays—a far more expensive proposition.