Database Reference
In-Depth Information
C H A P T E R 10
Designing for High Performance
This chapter focuses on a few key topics that can help you design high-performance applications that
consume data in SQL Azure and SQL Server databases. The approach used in this chapter builds a
simple but effective WinForms application that consumes data from both on-premises and cloud data.
You first explore a few general concepts and then quickly go into the design and development of a shard
library that reads data from multiple databases. Finally you see how to add multithreading to the shard
library using the Task Parallel Library (TPL) and caching using the Enterprise Library (formally known as
application blocks).
General Performance Concepts
Before diving into the details, let's discuss a few concepts related to performance. The first thing you
should know is that achieving high performance is difficult. Although making sure applications perform
to acceptable levels is important, advanced performance tuning requires careful planning and should be
included as a design goal only if requirements drive you to believe that high performance is necessary.
For example, if you expect your application to be used by thousands of concurrent users, then you may
need to use caching and even multithreading. On the other hand, certain high-performance techniques
can make code difficult to read and maintain, and in such cases knowledge transfer may be difficult.
Chatty vs. Chunky
The encrypted network connection to SQL Azure yields slower applications and may impact your
application design significantly. An application that opens a database connection for every database call
and performs a roundtrip for every update (that is, a chatty application) performs slower than an
application that loads data for multiple objects in a single call and sends changes in bulk (a chunky
application). LINQ to SQL and the Entity Framework are data access layers that provide good control
over the use of bulk operations (the SaveChanges method on the object context).
For example, if you design a data access layer that contains a lot of business rules, your code may
perform many roundtrips to the database to load the data needed to execute the business rules. If this is
the case, you can implement certain data-intensive business rules in stored procedures (close to the
data) and/or use caching to avoid unnecessary roundtrips.
Lazy Loading
On the other hand, although it's good to have fewer roundtrips from a performance standpoint, you
should load only the data you need, for two reasons: the more data you load, the more you pay for the
SQL Azure service; and loading more data than necessary can slow down your applications. So, you may
Search WWH ::




Custom Search