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

More documents

Recommendations

Info

Scheduler: The scheduler implements the resource allocation decisions required. For instance, if the decision is to maintain 15 and 5 resource units for A and B client classes respectively, this component implements these decisions until the next decision is made. It has the access to the Queue instances of each client class, resource units and other state variables. In each tick it executes the following algorithm for each client class. Say S i and i util are integer variables representing the allocated resources of i th client class and currently utilized resources by i th client class, respectively. Calculate the number of resources that can be allocated in this time instance, by Di f i = S i −i util . Get the Di f i amount of requests from the Queue corresponding to A client class and then the ResourceUnit instances are initialized with these requests. Further, the i util variable is updated at the same time. Here, we have taken the design decision of centralized scheduler, instead of each ResourceUnit class taking the responsibility of scheduling. This is because, it is easy to track and validate the resource utilizations compared to a distributed algorithm. StatisticCalulator: This is the component that computes the measurement required to implement the control systems. In particular, it calculates average response time, throughput and resource utilizations for each client class on specified time periods. It has a list of completed requests for each client class, which is populated by the ResourceUnit class after servicing the requests. The designer specifies the time interval to calculate the statistics, which we call as the sample instance. The statistic report generated will be used by the external entities for analysis and make runtime decisions. Afterwards, the request lists are cleared to accumulate the completed requests till the next sample instance. Following equations summarize how some of the statistics are calculated for client class i. Given the completed request list for client class List i , Throughput of the system T P i = Count(List i ), i.e, the number of items in the list. The response time of the j th request r i, j = r i, j .endtime − r i, j .starttime. The total response time of all requests in the list Tot i = Count(List ∑ i )−1 j=0 Average response time is calculated by R i = Tot i T P i r i, j (1) MainProgram: The designer can use this class to implement the required simulation depending on the requirements. Depending on the number of client classes Queue instance have to be created, then the required workload scripts have to be specified in client class specific workload generator objects. In addition, the number of resource units that is available in the system has to be specified in the scheduler. Further, probability distributions to simulate resource reservation time and sample period has to be given depending on the simulation objectives. Assumptions 1. Typically, the resource allocation decisions made by the management system are implemented at each sample instance. However, some of the resource units are maybe occupied by the requests that are being processed at that time instance. This may indicate that some classes have more than the resources they are allocated for that time instance. Hence, to implementation of the resource allocation decisions can be done in two different ways, including preemptive and non- preemptive. In the preemptive setting, the number of over utilized resources are forcefully taken away in order to allocate that resource to specified 4
class. This is a complex policy, which will cause jittery behavior in system measurements, inconsistent states in transaction and additional overhead on the shared resource system during the implementation at runtime [2, 3]. In contrast, in the non-preemptive setting, the resource is taken away once the request being processed is completed. The non-preemptive setting is a desirable configuration for shared resource environments [2]. Thus, we have implemented this non-preemptive setting in the scheduler process of the simulation model. However, the inaccuracy in decision implementation can be reduced by selecting the processing times comparatively smaller than the sample period. For instance, if the service time varies in ticks range, sample period can be selected in major ticks. This means the decision made will be implemented before the next decision made. In addition, a large amount of requests will be processed during a sample time so that the error due to incomplete requests during a sample period becomes insignificant. 2. End-to-end response time is not a consideration. 3. Time taken to reschedule the resource is assumed to be zero. 4. Overhead from the scheduler and the statistic calculator is zero. From the various simulations designed and executed from this implementation indicated that it can simulate consistent behavior under same settings and N number of clients. It also provides accurate measurements of the system outputs, correct implementations of resource allocation decisions and fast executions. The process-oriented design approach taken in this implementation provides modularity by delegating responsibilities among entities and extendibility. Therefore, this DES simulation model achieves many of the requirements mentioned in Section 2. What is left is verify and validate this DES model is capable to simulate the complex behavior of a multi-client class system. 4. Validation of the DES model After building a simulation, the next major step is to verify and validate the implementation. In this section we provide three forms of validations using queuing theory. It is noteworthy that to apply queuing theory, certain assumptions on the system structure, arrival workloads and processing time statistical distributions should hold. In the following sections, the required simulation systems are constructed using the DES model proposed in Section 3, adhering to the assumptions. 4.1. Conformant to Little’s law One of the fundamental results of queuing theory was developed by John Little in 1960’s, which is used as a basic building box in the development of theories of large scale queuing systems. Little’s law is defined as follows: For a queuing system in steady state, if the mean time waiting in the system is W = E(T), and the mean number of customers entering the system is λ, then the mean number of customers in the system is given by E(L) = W × λ. This result applies to any queuing system and even to systems within a system. However, system has to be in steady state, meaning that the arrival rate should be less than the service rate of the system. Therefore, the simulation model presented in this chapter can be validated using Little’s law. In order to do the validation, we constructed a queuing simulation using the constructs introduced in Section 3. We used two client class workload generators and queues with 5 resource 5
Page 1 and 2: A simulation model to implement mul
Page 3: is continued till the simulation en
Page 7 and 8: Table 2: A comparison based on sing
Page 9 and 10: of the widely used input signals to
Page 11 and 12: Response time (seconds) Response ti

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

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

Delete template?

Save as template?