Part V -- Adding the Resource Manager

Michael Chen
August 23, 1996
Rewritten: H. Hildreth, 9-20-96
Revised: H. Hildreth, 9-30-96

PART V: ADDING THE RESOURCE MANAGER

Key Point: At the time of this project, the new poset viewing tool (pov) did not enable the display of event time parameters. The old poset viewing tool (pob) did. Additionally a pruning tool for pov did not exist. We, therefore, pruned the poset using an old pruning tool (pobpp) and viewed the poset with event times using pob. (man pages should still be available for pobpp and pob.)

Although the reference documentation speaks of a resource "layer", this early version of the resource manager is created as a component of the AIL server architecture. In later versions, it exists outside the AIL, more in-line with the "layer" concept.

Objective: A server should only be able to process a certain number of requests in a fixed amount of time. In addition, certain jobs may take a longer time to accomplish than others. This being the case, the next step in the evolution of our client/server model was to create a resource manager that kept track of time and the current server workload. (In this early version, only the HTTP server workload was calculated and monitored.)

Rapide concepts introduced: The use of "at ?t" on the left-hand-side of behavior rules, which captures the time of event occurrence (observance?). Also, this is the first use of functions---their definition, use, connections, etc. (Before this introduction of functions, representing synchronous communication, we had used only in/out actions, representing asynchronous communication.)

For reasons unknown, an older (simpler) AIL model was used as the baseline to which the resource manager was added. Thus, "difference" files are not useful.

When the HTTP server receives a job request, a call is made to the Latency function of the resource manager ("Latency" is defined in "type Res_Mang_Iface" in resource.rpd). This call returns a value representing the amount of time required for the server to perform the requested operation.

Server request types (RType) are passed as parameters to the Latency function. Each request type has a value associated with it that represents the amount of processing required to complete the request. The third parameter of the Latency function is the time of the request. The resource manager calculates server workload based on an internal clock (updated based on request times), processing requirements per request, and processing completed since the last request. The constant, PRate, represents the amount of processing the server can perform per unit of time.

The server response is delayed for the amount of time returned by the Latency function (using a Rapide "after" clause as shown below).


   (?C in Client, ?R in RType, ?I in Integer)InCommand(?C, ?R) at ?I ||>
      Response(?C) after Latency(?R,?I);;

Prune the log file using pobpp (e.g., select only the InCommand and Response events associated with the HTTPServer). Start pob via pobpp (select "pob" File menu option). Unselect "from dui" and select "departure time" in the "Labels" menu of pob. Select "out" in the "zoom" menu. With cursor on background type "c" for center, and the poset will be redrawn as specified.

[ Back to the Index | Next | Prev]