For the selection of an appropriate solution approach to be applied for the requirements previously stated, the methods described in subsubsection 3.3.1.2 where considered.
Although Petri nets, especially Queued Petri nets are able to not only model perfor-mance but also functional aspects and their accuracy has been found to be higher, compared to Layered Queuing Networks (LQNs), they are solved with Markov chains.
These result in an exponential growth of the model with increasing software complexity, e.g. when additional layers are added. Another limiting factor is the number of concur-rent requests, as they result in an explosion of the state space. In comparison, LQNs can model any number of concurrent requests as they are analytically solved using ap-proximate mean value analysis and the addition of layers does not result in a significant growth of the model. Furthermore, Queued Petri nets have been found only to support synchronous calls, while for the LQNs extensions for asynchronous calls are available as well. [30] Likewise, stochastic process algebra suffers the problem of state change explosion, as it is also a state based modelling technique. However, some counter mea-sures have been developed to overcome this problem, such as continuous state space approximation. [7] Nevertheless, during the preliminary research for the purpose of this thesis Petri nets and stochastic process algebra were deemed to be more complex to define and to solve. For this reason only queuing networks and simulation models where examined in more detail. Overall, both of them seem to cover the necessary requirements. In the end it was decided for queuing networks, as they are already well researched, better supported by existing literature, and were successfully applied in similar applications, such as for modelling a Java based SAP application [21]. On the other hand simulation models seemed to require more effort in building up the individual application models and it was uncertain if a meaningful model could be created with this approach in the given time frame.
LQNs are an extension to queuing networks which were designed for modelling dis-tributed software systems [1]. They are organised in multiple layers, whereas in most implementations the lower layer serves the next upper layer. They are able to fulfil the basic requirements, such as providing throughputs, response times, and utilisations for software and hardware components for different applications connected to each other.
Extensions allow to model not only single threaded applications, but also parallel execu-tions (multi-servers) [26]. Queuing networks in general allow to model multiple customer classes. In this context a customer class is a specific workload applied to the model, e.g. a request. Multiple customer classes mean that different workloads may be applied with an arbitrary user distribution per class.
Independently of the solution to be implemented, for achieving adequate accuracies, the following information has to be provided: data and workload parameters, system archi-tecture and flow, demands on the CPU and IO by the system components, and latency values [34]. For internally developed applications to some degree these parameters
Chapter 4: Advanced requirements analysis and solution selection 29
may be more easy to obtain, in case of third party applications, the knowledge is typi-cally more limited. While system demands for executions may be measurable, e.g. by measuring the demands for single requests, inner workflows can often only be assumed.
In such cases the provided data may still be sufficient for "bottleneck analysis", which only requires the total demand for every device [34]. At least for third party applications such a "bottleneck analysis" may be sufficient, as the goal of the solution should be a qualitative deduction on the expected performance of the overall system. Especially for internally developed applications good approximations for the software flows should be able to be created if not available already. For obtaining demands on the CPU and IO and latencies, log outputs can be implemented or enabled, as well as system monitoring or profiling tools, such as JProfiler for Java applications, can be used.
As for network latency, another extension to LQN may need to be applied. In this regards research has been found to have been previously performed [15, 17], but it may also be modelled as a "pseudo task" which just causes pure delays [33].
For parameter variation, a LQN model requires the definition of demands on software and hardware components, which can be easily adapted in the model.
As for the appliance of the technique, research did not conclude with a framework ready to be used which corresponded to the list of requirements. For this reason it was decided to implement an own framework, mostly based on the Method of Layers [26] for this thesis, which is supposed to be able to cover all of the basic requirements and is planned to be extended as needed in the future. Hence, the non-functional requirements can be applied during the implementation of the framework. However, for the long term goal of making the framework available to the end users separate research will be required.
30
Chapter 5: Implementation of a Layered Queuing Network Modelling Framework 31
5 Implementation of a Layered Queuing Network Modelling Framework
To create Layered Queuing Network models, a framework for it needed to be imple-mented, which then could be used on demand by the overall platform. This implemen-tation is mainly based on the Method of Layers as introduced by J. Rolia [26]. Hence, this chapter starts with depicting basics as well as the algorithm on which the method is based on, then continues to outline the implementation as it was performed for this thesis. Finally it concludes with the description on how the framework is supposed to be embedded in other applications by discussing the usage of the required classes.