Because it affects such things as the degree to which logical concurrency can be realized by physically concurrent devices, the concurrency architecture of software can have a large impact on performance. Architectural decisions such as concurrency are typically made early in the development of software, and are difficult to change once the software has begun to be fleshed out. It is therefore useful to be able to evaluate the feasibility of software concurrency architectures proposed for a set of scenarios and a set of response-time requirements which, in part. define a particular software project. Such evaluation. however, is difficult because it is hard to predict the effects of pre-emption. the amount of concurrency-related overhead generated, and which portions of scenarios will actually be performed in parallel and which will for some reason end up serialized. So that one can discover possible ways to improve a concurrency architecture. it is also useful to diagnose an architecture for causes of performance shortfalls.

This thesis describes an approach (and a tool) called PERFECT which performs such evaluations and diagnoses by automatically constructing and simulating an instrumented virtual implementation which conforms to a behaviour and concurrency architecture easily specified by supplying a Use Case Map supplemented with performance information. This work focuses on software for servers.

An evaluation reports. for each type of response. the fraction of responses which finish within the specified delay time. Also reported is the utilization of each device. Diagnoses include measurements of the cumulative effect of priority inversion at each point where messages are sent to a software process, lost opportunities to concurrently use multiple devices by the most urgent work, and the amounts of different types of concurrency-related overhead such as context switching.

To demonstrate how the whole approach works, a number of cycles of proposing, evaluating, and diagnosing a concurrency architecture for a group communication server are presented. The first architecture cannot process requests as fast as they arrive. By remedying the diagnosed causes of performance shortfalls. an architecture is derived which meets all performance requirements. Adding concurrency not suggested by diagnoses causes performance to decline.