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 ...
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