Performance

A number of factors can affect the performance of a distributed application. Some examples are factors outside the software system, such as network speed, network traffic, and other hardware issues local to specific machines, such as CPUs, I/O subsystems, and memory size and speed.

Given the current state of distributed application technologies, performance and interoperability are mutually exclusive goals. If your distributed application absolutely needs to perform as fast as possible, you usually have to constrain the application to run inside the firewall, and you have to use the same platform for both client and server. This way, the distributed application can use an efficient network protocol such as TCP and send data by using a proprietary binary format. These formats are far more efficient that the text-based formats usually required for open-standard support.

Assuming a distributed system's hardware (including the network) is optimally configured, proper coding techniques are essential to a scalable high-performance application. The best optimization is to avoid making distributed calls wherever possible. This optimization is usually referred to as the chatty ys. chunky trade-off. Most traditional object-oriented programming techniques and texts focus on designing elegant solutions to common programming problems. These solutions are usually most appropriate when collaborating objects are very close to each other (probably in the same process, or with .NET, in the same application domain).

For example, if you're working with a partner who sits beside you in the office, you two can chat as often as you want to solve problems. You can bounce ideas off each other, change your minds, and generally talk throughout the workday. On the other hand, if you're working with a buddy who lives on another continent, your work style needs to change dramatically. In this scenario, you do as much work as possible on your own, check it carefully, and try to make the most of your infrequent communication with your partner. Working this way isn't as elegant as working with a partner who sits beside you, and it requires you to learn a new approach to stay productive. For efficiency, you wind up sending back and forth bigger chunks of work more infrequently when distance becomes a factor.

Thus, if you're using local objects, you can perform tasks such as the following:

• Use properties at will You can set the state of an object by setting many properties on it, each of which requires a round-trip to that object. This way, the client has the flexibility to change as few or as many properties as a scenario requires.

• Use callbacks at will Because the communication time of local objects is negligible, an object can walk a list of client objects and call them even to update a trivial piece of status information. These client objects can call each other to update and retrieve any information they want, without too much worry about a performance hit.

If you're using remote objects, you need to adhere to these stipulations:

• Avoid heavy use of properties Instead of using many properties, you should set remote object state by combining a number of these properties as parameters to one or a few methods. In fact, some very scalable distributed applications have methods with large parameter lists that seem ridiculous for local calls.

• Think carefully about callbacks In the interest of avoiding expensive remote calls, many callbacks could be aggregated into a single or a few method calls with many parameters.

The bottom line is that good remote application design can frequently seem like poor object-oriented design. You simply can't apply every local object metaphor to distributed object scenarios without considering performance.

Note Of course, you should always avoid writing sloppy, wasteful code. Thus, it's good object-oriented practice for objects to limit their communications where appropriate. Because of the chunky vs. chatty trade-off, scalable remote object design frequently means avoiding many patterns you might have grown accustomed to when dealing with local objects.

0 0

Post a comment