21.01.2014 Views

A simulation model to implement multiple client class server-client ...

A simulation model to implement multiple client class server-client ...

A simulation model to implement multiple client class server-client ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

is continued till the <strong>simulation</strong> end condition is reached. During the <strong>simulation</strong> or at the end of<br />

the <strong>simulation</strong> statistics are gathered <strong>to</strong> analyze the results of the <strong>simulation</strong>. Generally, DES<br />

<strong>model</strong> can be designed in an event-oriented and a process-oriented point of view. In the even<strong>to</strong>riented<br />

technique the DES <strong>model</strong> designer takes the events of the system and how they affect the<br />

system state variables of the <strong>model</strong> as major concerns. On the other hand, process oriented point<br />

of view enables <strong>to</strong> <strong>model</strong> the entities, their processes and how the inter-process communicates<br />

take place. The event-oriented design produces <strong>simulation</strong>s that can execute faster compared<br />

<strong>to</strong> process-oriented design, however, modularity extendibility and the understandability of the<br />

system is a trade-off. Both of these design techniques can be used, however process-oriented<br />

design is popular among the commercial <strong>simulation</strong> products [1]. Further, a DES <strong>simulation</strong><br />

can be designed with deterministic and s<strong>to</strong>chastic inputs and variables. For instance, a resource<br />

utilization time is precisely 5 seconds for any request is deterministic, where as the utilization<br />

time is determined by a probabilistic distribution is s<strong>to</strong>chastic.<br />

3.2. DES <strong>model</strong> of a multi-<strong>client</strong> <strong>class</strong> system<br />

In this section, we provide <strong>implement</strong>ation details of the <strong>simulation</strong> environments developed<br />

following the guidelines provided in [1]. Here, we have taken the process oriented design<br />

technique because it provides modularity, extendibility and convenience <strong>to</strong> design using general<br />

purpose object-orient programming languages like Java and C#.Net. Further, we use s<strong>to</strong>chastic<br />

inputs and variables in this <strong>simulation</strong> <strong>to</strong> represent the variability in multi-<strong>client</strong> <strong>class</strong> systems.<br />

The DES <strong>simulation</strong> <strong>model</strong> constructed has following entities (components) in the architecture<br />

corresponding <strong>to</strong> the characteristic architecture of Figure 1.<br />

MasterClock: This component keeps track of the current time instance of the system and<br />

advances the time after all events and activities specific <strong>to</strong> the current time instance have taken<br />

place. It triggers events on the tick (smallest time unit) and major tick (which is 1000 ticks).<br />

Request: This represents a <strong>client</strong> request flowing through the <strong>simulation</strong> <strong>model</strong>. It has the<br />

properties of <strong>client</strong> <strong>class</strong> Id, start time, end time and processing time. The processing time is<br />

determined by a probabilistic distribution specified by the designer.<br />

ClientClassWorkloadGenera<strong>to</strong>r: This component generates workloads for a specific <strong>client</strong><br />

<strong>class</strong>. It needs a <strong>client</strong> <strong>class</strong> id, workload script and the corresponding queue instance at the<br />

initialization. Then the process of this component is at each tick the workload script is analyzed<br />

and generates the required number of requests that have <strong>to</strong> be sent <strong>to</strong> the system. Then, the<br />

requests are initialized with the <strong>class</strong> id and the start time and enqueued <strong>to</strong> the corresponding<br />

queue. Currently it can simulate deterministic time varying and s<strong>to</strong>chastic (e.g., Poisson process)<br />

workloads.<br />

Queue: In a multi-<strong>client</strong> <strong>class</strong> system there is a corresponding queue <strong>to</strong> each <strong>client</strong> <strong>class</strong><br />

(see Figure 1). The Queue component is used for this purpose. It is a container of the requests<br />

generated by the ClientClassWorkloadGenera<strong>to</strong>r and ordered in a first-come-first-out fashion.<br />

The <strong>simulation</strong> <strong>model</strong> needs N Queue instances <strong>to</strong> represent N queues.<br />

ResourceUnit: The ResourceUnit entity is an abstraction of a resource unit in a multi-<strong>client</strong><br />

<strong>class</strong> system. It simulates the time period a resource is reserved/occupied/provisioned <strong>to</strong> serve a<br />

request of a <strong>client</strong> <strong>class</strong>. It has the currently served request, serviced <strong>client</strong> <strong>class</strong>, status (idle or<br />

working) as attributes. The process of this entity is at each tick, it simulates the processing time<br />

specified on the request it is serving. When the request has utilized the resource for the specified<br />

period of time it is assumed <strong>to</strong> be sent back <strong>to</strong> the <strong>client</strong> after stamping the end time. However,<br />

in this <strong>simulation</strong> the copy of the served request is also sent <strong>to</strong> the statistical analysis component<br />

<strong>to</strong> compute measurements such as response times.<br />

3

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!