Once you have finished the first cut of your application you will
almost always feel the need to improve performance. The general pattern for this is a bit
too abstract to offer real help. Simply the fact that you would have a hard time to assign
a name other than performance optimization to it is an indicator that this a general rule
- and not a pattern.
| Problem How do you
optimize performance in an application using a database?
Forces
The forces here are your wish for optimal performance on the
one hand and the complexity and cost of an optimal access layer on the other hand. Other
tradeoffs include memory usage (caching) versus use of slow I/O. See [Kel97] or [Kel+98a]
for extensive lists.
Solution
Try to reduce database traffic and disk I/O to a minimum that still
yields a maintainable application at reasonable cost |
The above "solution" contains balancing of forces as the
solution - it is therefore no ready solution. A deeper analysis of the factors that cause
bad performance leads to a series of patterns that can be split into two categories.
- Optimizing Table Structures and Queries:
Can be achieved by a series of performance
patterns that you use to tune performance depending on your business objects' structure
and access behavior. These patterns deal with optimizing table structures and access
behavior. The result of applying them is usually lost for the next project.
- Optimizing General Design:
Is a set of performance patterns that you incorporate in
the static design and architecture of the access layer itself. These patterns deal with
optimizing the access layer's structural design for performance If you take the layer to
the next project, that kind of tuning will be already done.
Pattern List
The first category Optimizing Table Structures and Queries has
been documented in [Kel+97]:
- Denormalization
: How can you manage to read and write object clusters with a single
page database access when you have a parent/child relation?
- Overflow Table
: You have followed the Denormalization pattern’s advice
and have denormalized a relation. What do you do with those objects that have more
dependent objects than the number that you integrated into the parent object's table?
- Controlled Redundancy
: How can you manage to read object clusters with a single page
database access when you need to read data from a parent object's table?
- Narrow Views
: What kind of database or object level views should you use for filling
list boxes?
- Short Views
: How do you speed up filling of list boxes and prevent unnecessary data
from being loaded into the list box?
The other category Optimizing General Design has been Published
in a 1998 PLoP article:
- Cluster Read
: How do you provide high performance access to large chunks of data via
an object/relational access layer?
- Bundled Write
: How do you speed up the process of writing dirty objects to the
database?
- Store for Forward
: If you have too much data to wait for the transfer to a remote
database, how do you shorten waiting time?
- Flat File Write
: How do you write a large volume of data when you cannot wait for
the database insertion?
-> on to Web Ressources
-> up to the Contents Page