Performance models can help in the design process by locating bottlenecks in the system that may not be visible during the development of the software and for determining capacities. However making models is not a trivial task and its ability to capture performance related detail is a concern. This work introduces an automated method to construct models from traces of a running distributed application. In this model tasks exhibit internal concurrency, specifically asynchronous remote procedure calls and early replies by a server. The trace information is transformed into a layered queuing network (LQN) model where behaviours of tasks are modeled using activity graphs (AGs) with fork and join activities.

Locating performance bottlenecks in modern distributed systems can be difficult because direct measurement is often not available. Performance models are often very beneficial in these situations because far more information can be extracted as a result. This work demonstrates the generation of a Layered Queueing Network performance model through the analysis of trace information from a live system. The model can then be analyzed to locate bottlenecks in both the hardware and software.

Layered Queueing Networks (LQN) have been used successfully by numerous researchers to solve performance models of multi-tier client server systems. A common approach for solving a LQN is to split the model up into a set of submodels, then employ approximate mean value analysis (AMVA) on each of these submodels in an interactive fashion and using the results from the solution of one submodel as inputs to the others. This paper addresses the performance of the layered queueing network solver, LQNS, in terms of submodel construction and in terms of changes to Bard-Schweitzer and Linearizer AMVA, in order to improve performance. In some of the models described in this paper, there is a difference in four orders of magnitude between the fastest and slowest approaches.

Performance models can be built at early stages of software development cycle to aid software designers to assess design alternatives and identify fundamental design pitfalls before the implementation phase starts. These models are flexible for varying operational conditions and design alternatives; however, their creation is not trivial and requires considerable efforts. This paper addresses this problem by introducing automation in process of Layered Queuing Network (LQN) performance model creation for traces of events generated from instrumented software programs in the nodes of a distributed parallel software application. The event-traces are created based on a new timestamp format, which is independent of physical time and uses extremely low count elements. A set of post-mortem methodologies have been introduced to identify the interactions between the service nodes of the parallel distributed software application and determine their workload activities, while supporting concurrent executions in the nodes. It can capture Forward, Asynchronous, Synchronous and loops of Asynchronous or Forward interactions. The final result is a framework of methodologies, specifications and tools which is appropriate for model-based performance evaluation parallel distributed software applications.

Fair-share scheduling attempts to grant access to a resource based on the amount of “share” that a task possesses. It is widely used in places such as Internet routing, and recently, in the Linux kernel. Software performance engineering is concerned with creating responsive applications and often uses modeling to predict the behaviour of a system before the system is built. This work extends the Layered Queueing Network (LQN) performance model used to model distributed software systems by including hierarchical fair-share scheduling with both guarantees and caps. To exercise the model, the Completely Fair Scheduler, found in recent Linux kernels, is incorporated into PARASOL, the underlying simulation engine of the LQN simulator, lqsim. This simulator is then used to study the effects of fair-share scheduling on a multi-tier implementation of a building security system. The results here show that fair-share scheduling with guarantees is not sufficient when an application is layered into multiple tiers because of contention at lower layers in the system. Fair-share scheduling with caps must be used instead.

Layered queues are a canonical form of extended queueing network for systems with nested multiple resource possession, in which successive depths of nesting define the layers. The model has been applied to most modern distributed systems, which use different kinds of client-server and master-slave relationships, and scales up well. The layered queueing network (LQN) model is described here in a unified fashion, including its many more extensions to match the semantics of sophisticated practical distributed and parallel systems. These include efficient representation of replicated services, parallel and quorum execution, and dependability analysis under failure and reconfiguration. The full LQN model is defined here and its solver is described. A substantial case study to an air traffic control system shows errors (compared to simulation) of a few percent. The LQN model is compared to other models and solutions, and is shown to cover all their features.

The use of parallelism in enhancing protocol execution performance is examined. In particular the use of a separate concurrent task for each protocol layer is discussed. Two layers of the OSI protocol system were implemented and run on a multiprocessor, with from one to five processors at each end of the connection. Potentially concurrent entities included user tasks as data source and sink, the OSI session layer (kernel functional unit only), the OSI transport layer (classes 0 and 2), vestigial network tasks, and tasks to buffer data between layers. Three substantially different design architectures with from nine to twelve tasks at each end of the connection were compared. The design differences centered on different ways to provide interlayer coordination and buffering; the protocol code was kept identical. The implementation used a real-time kernel which provides synchronous (request-reply) interprocess communication. The variation in throughput between designs covered a range of approximately two to one. The best design is found to be symmetrical decentralized two-way pipeline with courier communications.>