Distributed applications partition functionality into separate components that can be deployed on the network in a wide variety of physical configurations. The key performance issue for these distributed components is not tuning raw code execution, but determining the optimum network topology for a distributed solution.
The first and most important question that you must answer in considering how best to take advantage of the potential for distributed computing — and whether a specific application task should in fact be remotely executed — is this: Is the overhead associated with the remote component worth the benefit?
If you choose distributed component architecture for your enterprise application, then you must determine the appropriate component granularity and physical deployment. Granularity has to do with how objects and logical services are sized and grouped into physical components. Deployment considers where each component should be located in order to achieve the required performance.
You can directly examine the performance effects of component granularity and deployment by exploring alternative design questions such as:
With Application Performance Explorer you can answer these design performance questions by quickly setting up test cases with differing granularity and deployment options.
At a detailed design level, the question of whether or not to use remote component deployment for a particular task requires consideration of the following general design parameters.
| Design parameter | Consideration |
| Task size | How big is the task being considered for remoting? |
| Request frequency | How often does the task need to be executed? This includes requests from all users, not just a single desktop machine. |
| Network bandwidth | What is the raw speed of the network cable, network interface card(s), network protocol, RPC, and drivers, as well as the collision/retry overhead caused by network traffic? |
| Data transfer requirements | How much data needs to be transferred to and from the task? In some cases this value may be negative because the location of the task on a remote server may actually reduce data transfer requirements to the desktop. |
| Desktop capacity | What is the raw bandwidth of the desktop system's CPU(s), memory, disk I/O, and other resources and devices that are needed to process the task? |
| Remote capacity | What is the raw bandwidth of the remote system's CPU(s), memory, disk I/O, and other resources and devices that are needed to process the task? |
| Desktop opportunity cost | What could the desktop machine be doing if it were not running the task? |
| Server opportunity cost | What could the server being doing if it were not running the task? |
| Desktop resource burden | What resource burdens do the operating system and other concurrent applications impose on the desktop system? |
| Shared resource burden | What resource burdens do the operating system and other concurrent applications impose on the shared system? |
| Application design and implementation | How efficiently are these factors considered in the design and implementation of an application? |
| Centralized administration | What is the benefit of administering or updating the task from a centralized location rather than each desktop? |
From the design parameters listed above, it should be obvious that there is no simple quantitative answer to distributed component deployment. Because each target installation has a unique resource infrastructure that is not duplicated anywhere else, every application needs a different deployment design answer. No tool can answer all of these questions, but Application Performance Explorer can provide meaningful insights and measurable answers to many of these deployment and performance questions.