Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

17.1 What Is Good Performance?

Most developers have had the
unfortunate experience of building a slow application. Obviously,
developers don't set out to create slow
applications, and there probably isn't a user group
asking, "Could you please make the application run
slower?" Too often, bad performance
isn't discovered until the application is finished
and installed into a production environment. But why does this
happen?

The simple truth is that it happens because not enough attention is
given to performance matters during design and construction. This is
not to say that performance should be the primary focus at all
timesif you focus on performance too exclusively or too soon,
it may negatively affect the design and code. On the other hand, if
you wait too long, you may find yourself with upset users complaining
about poor performance, and you'll be left wondering
what went wrong.

You may have heard the axiom "Test soon, test
often." This is a good principle to follow to help
ensure that you are not surprised at the end of construction with a
poorly performing application. The sooner you can detect a
performance problem, the more likely it is that
you'll get a chance to fix it before the application
goes into production. Another apt saying is
"Don't leave any broken
windows." This means that when you detect a problem,
you should fix it and not let it linger. Picture a building with a
broken window that's not immediately fixed. If
people are led to believe that having one broken window in the
building is acceptable, they will eventually decide that
it's all right to have many broken windows. Before
long, the building will be in shambles, and all the tenants will have
moved out. If you find obvious performance problems during early
tests, fix them.

So how do you measure the performance of a web application?
What's considered acceptable or too slow? The
answers to these questions are strictly related to the nonfunctional
requirements of the application.^[1] There are tangible and
quantitative measurements that can be taken to help determine whether
the application is able to meet the minimum requirements set out in
the nonfunctional requirements.

^[1] The nonfunctional
requirements are part of the analysis work that should be done for
any nontrivial application. These requirements describe the broader
issues of the application, such as availability, disaster recovery,
package dependencies, hardware configuration, and, almost always,
performance criteria.

The problem is that each application is different and therefore has
different nonfunctional requirements. One application might need to
have an average response time of 3.0 seconds and support 50
concurrent users, while another might have to support 500
simultaneous users. Performance testing is a little more nebulous
than functional testing, where it's easy to see when
the application fails to meet the design specifications.

According to Alberto Savoia, the Director of Software
Research at Sun Microsystems's Laboratories, there
are four behavioral laws that make web
page performance critical to an organization's
success:

The Law of Stickiness

This law states that web users are sticky, but not loyal. If
they find a web site that serves their needs, they tend to continue
to use that site. If the web site begins to respond slowly and cause
the users to wait, they will move to another site that fulfills their
same needs. The point is to strive to keep the performance of the
application strong in order to keep the users coming back.

The Law of User Perspective

This law states that you should
always measure the performance of your application from the
user's point of view, not from your own. The point
here is that, for example, while your environment may have a 100-MB
network with an otherwise light load on it, the user may be using a
modem with a much smaller bandwidth capability. Always keep in mind
what the user's environment and network capabilities
will be and test accordingly.

The Law of Responsibility

This law states that the users don't care what or
who is at fault for poor web site performance; they will always blame
the application. The problem might be their ISP or another
nonapplication issue, but most users will not be able to isolate the
problem to that level and instead will blame the application or site.
You must be aware of all the factors that may impact the performance
of your application.

The Law of Expectations

This law states that users' satisfaction is based on
their expectations, which are set by their personal experiences with
other, similar web sites. When measuring the performance of your
application, don't rely just on arbitrary numbers to
indicate what's slow or fast; compare your results
with those of your competitors.

These simple, common-sense laws explain the human-behavior aspects of
web site performance. In general, however, slow is slow and fast is
fast, and generalizations can be made across applications and
business domains. But before we discuss how to detect whether
performance problems exist in an application, a distinction must be
made between the types of performance testing that should be
conducted.