Summary

The data tier will make or break most distributed applications. This chapter considered some principles that no distributed programmer can afford to ignore, including connection pooling, caching, and optimization. All of these techniques are useful ingredients in the programmer's toolbox, but it's not always obvious when you should use them. As with any performance-optimization strategy, the only way to gauge the value of a change is to perform stress testing and profiling. Without this step, you might spend a great deal of time perfecting code that will achieve only a minor improvement in performance or scalability, at the expense of more effective changes. Chapter 14 introduces the art and science of profiling.

Finally, every programmer would do well to consider three basic tips for ensuring good database performance:

• Optimize the SQL in your stored procedures. Writing SQL might not be as exciting as writing .NET code, but you ignore doing so at your own risk. Excessive joins or misuse of data types can exert a performance toll.

• Although hardware can't solve poor design or coding, the database server is generally one of the best places to spend your hardware budget. A database should have the fastest possible hard drive and enough cache memory to optimize reads. SQL Server optimizes its cache automatically, but other RDBMS products might benefit from fine-tuning and manual enlargement of in-memory cache sizes.

Learn the enhancement techniques for your RDBMS. Database products almost always support standardized SQL syntax and similar features, but they differ widely in performance optimization techniques. You need to understand these to coax the best possible performance from them.