Databases Reference
In-Depth Information
meant an additional five million Commit statements were being issued across the
network, and every inserted row was written to disk immediately following the
execution of the insert. When auto-commit mode was turned off in the applica-
tion, the number of statements issued by the driver and executed on the database
server was reduced from ten million (five million Inserts + five million
Commits ) to five million and one (five million Inserts + one Commit ). As a con-
sequence, application processing was reduced from eight hours to ten minutes.
Why such a dramatic difference in time? Significantly less disk input/output
(I/O) was required by the database server, and 50% fewer network round trips
were needed.
In general, your database application should be written to do the following:
Reduce network traffic
Limit disk I/O
Optimize application-to-driver interaction
Simplify queries
See the following chapters to learn about some general guidelines for good
coding practices that improve database application performance:
For ODBC users, see Chapter 5, “ODBC Applications: Writing Good Code.”
For JDBC users, see Chapter 6, “JDBC Applications: Writing Good Code.”
For ADO.NET users, see Chapter 7, “.NET Applications: Writing Good
Code.”
Our Goal for This Topic
The goal of this topic is to equip you, as software architects and developers, with
techniques and knowledge to predict, diagnose, and solve performance issues in
your database applications. Specifically, this topic provides information that will
help you achieve the following tasks:
Understand the different components of database middleware that can cause
performance issues.
Design for optimal performance.
Write good application code.
Develop good benchmarks, tests that measure the performance of a database
application on a well-defined task or set of tasks.
Troubleshoot performance issues.
Set realistic performance expectations.
 
Search WWH ::




Custom Search