Database Reference
In-Depth Information
Not only do some of these characteristics conflict with each other, but budgets are usually limited (and
sometimes are
very
limited). It seems reasonable then that more often than not it is necessary to prioritize these
characteristics and find a good balance of achieving the desired requirements within the available budget.
preMatUre OptIMIZatION
premature optimization, (probably) because of Donald Knuth's famous line “premature optimization is the root
of all evil,” is, at the very least, a controversial topic. the misconception based on that particular quote is that a
programmer, while writing code, should ignore optimization altogether. In my opinion this is wrong. to put the
quote in context, let's have a look at the text that precedes and follows it:
“There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time
thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at
efficiency actually have a strong negative impact when debugging and maintenance are considered. We should
forget about small efficiencies, say
about 97% of the time: premature optimization is the root of all evil. Yet we
should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by
such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It
is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal
experience of programmers who have been using measurement tools has been that their intuitive guesses fail.”
my take on Knuth's paper is that programmers, when writing code, should not care about micro optimization that
has local impact only. Instead, they should care about optimizations that have global impact, like the design of a
system, the algorithms used to implement the required functionality, or in which layer (sQl, pl/sQl, application
language) and with which features a specific processing should be performed. local optimizations are deferred till
a measurement tool points out that a specific part of the code is spending too much time executing. and because
the optimization is local, there is no impact on the overall design of the system.
Integration and Acceptance Testing
The purpose of integration and acceptance testing is to verify functional and performance requirements as well as
the stability of an application. It can never be stressed enough that performance tests have the same importance
as function tests. For all intents and purposes, an application experiencing poor performance is no worse than an
application failing to fulfill its functional requirements. In both situations, the application is useless. Still, it is possible
to verify the performance requirements only once they have been clearly defined.
The lack of formal performance requirements leads to two major problems. First, the chances are quite high that
no serious and methodical stress tests will be performed during integration and acceptance testing. The application
will then go to production without knowing whether it will support the expected workload. Second, it will not always
be obvious to determine what is acceptable and what is not in terms of performance. Usually only the extreme cases
(in other words, when the performance is very good or very poor) are judged in the same way by different people. And
if an agreement is not found, long, bothersome, and unproductive meetings and interpersonal conflicts follow.
In practice, designing, implementing, and performing good integration and acceptance testing to validate the
performance of an application are not trivial tasks. You have to deal with three major challenges to be successful:
•
Stress tests should be designed to generate a representative workload. To do so, two main
approaches exist. The first is to get real users to do real work. The second is to use a tool that
simulates the users. Both approaches have pros and cons, and their use should be evaluated
on a case-by-case basis. In some situations, both can be used to stress different parts of the
application or in a complementary way.
