Performance Checklist Distributed Computing

- 281 - o Ensuring that you deallocate resources when finished with them o Reducing round trips by batching requests Several articles cover JDBC optimizations in more detail: • Best Practices for JDBC Programming, by Derek C. Ashmore, Java Developers Journal, April 2000, available at http:www.JavaDevelopersJournal.com . • Optimizing Database Transactions with the JDBC, by Chad Darby, Java Report, May 1998. • Object Persistence Beyond Serialization, by a group of software engineers from IBMs VisualAge Group, Dr. Dobbs Journal, May 1999. This is a higher-level, non-Java-specific view.

12.11 Performance Checklist

• Use a relay server to examine data transfers. • Reduce the number of messages transferred. o Cache data and objects to change distributed requests to local ones. o Batch messages to reduce the number of messages transferred. o Compress large transfers. o Partition the application so that methods execute where their data is held. o Multiplex communications to reduce connection overhead. o Stub out data links to reduce the amount of data required to be transferred. • Design the various components so that they can execute asynchronously from each other. o Anticipate data requirements so that data is transferred earlier. o Split up data so that partial results can be displayed. o Avoid creating distributed garbage. • Optimize database communications. Application partitioning is especially important with databases. o Use statically defined database queries. o Avoid database transactional modes if possible. o Use JDBC optimizations such as prepared statements, specific SQL requests, etc.

Chapter 13. When to Optimize

Faster, better, cheaper—choose two of the above. —Old engineering proverb When developing an application, it is important to consider performance optimizations and apply these where appropriate in the development cycle. Forgetting these optimizations or getting them wrong can be expensive to correct later in development. [1] In this chapter, we follow the various stages of the full product life cycle and consider when and why you might need to include some performance optimizations. [1] When I talk about expense, I mean cost in both time and money. Performance tuning is frequently a matter of tradeoffs . Occasionally, you have the wonderful situation that a change to the application is better in every way: it provides better performance, cleaner code, and a more maintainable product. But more often, the performance of parts of an application are interrelated. Tuning one part of the application affects other parts, and not necessarily for the better. The more complicated the application, the more often this is true. You