sm.gif)
|
Hoov's Musings (volume 3, number 9) |
Getting
the Performance You Deserve
Mark Hoover,
President, Acuitive, Inc.
I’m a networking guy through and through.
It’s all I know. But even after spending twenty-five years focused on nothing
but networking, I still maintain a perspective on the value of
networking that I sometimes think many of my peers have lost
- it’s not about networks, it’s about applications and
the users of those applications.
If the speeds and feeds of some new networking product
doesn’t improve application availability and performance in some
manner, it just doesn’t matter.
Yet end users of applications, and even many
application service providers look at the problem from the bottom
up, worrying a lot about WAN link speeds, bandwidth management
policies and classification techniques, and network utilization
statistics, without the frame of reference of what these networking
metrics mean to the application. Because of this, Acuitive constantly receives panicked
requests from customers who have just deployed a new application
onto their network with resulting poor performance, not only for the
new application but degraded performance for existing applications
as well.
As an accidental result, Acuitive has a few
consultants that have developed an innate ability to diagnose and
solve application performance problems.
Now that we have performed such magic over a period
of a few years and in a variety of situations, we can look back and
perform some pattern recognition to identify the root causes for
these panic situations. Most
of these customers have some common factors:
n
The application is already
deployed
n
The response time is
exponentially worse than it was expected to be
n
The problems are being blamed
on the network
This creates a recipe for a great business for a
network consulting company like Acuitive.
But I’m here to let you in on a big secret – most of the
time these customers could have avoided big consulting bills from
Acuitive (or others) simply by planning a little better.
To help our customers help themselves, or even to
avoid needing to be Acuitive customers at all (so we can spend more
time at the beach), Acuitive has developed a methodology called
Application Quality Management.
This methodology addresses the management tools and
organizational processes that can be used to achieve better
application performance and more realistic expectations of end user
response times, prior to or after application deployment.
Later this month, we are putting this methodology into an
Acuitive Research Report that will be made available for free on our
web site (http://www.acuitive.com/rr.html).
I thought I'd use the remainder of this musing to
go through some of the highlights of the AQM methodology.
So, where do customers get into trouble? Certainly no one sets out to get poor performance. The same problems can occur whether you are deploying an enterprise application, a web site or a B2B exchange. The root of the problem centers around two major themes:
n
Little to no cooperation
between the organizations responsible for the application's success
n
Too busy to plan (sometimes
mentally I substitute the word “stupid” for “busy”)
The first of these two is the most prevalent but
hardest to fix. It is
still very common that application developers work on applications
over an extended time only to notify the network planning team and
the operations staff at the last minute (the weekend before?) before
the new application is deployed into the network.
Often the application is developed on a local network that
gives the illusion that bandwidth is unlimited and response time
will be excellent. When
the application development team and the network planning team don't
get together until the 11th hour two big disconnects
occur. First, the
network planning staff doesn’t have time to ensure that there is
sufficient bandwidth for the new application. Second, the
application development team (and the application user) has a fairly
unrealistic expectation of the response time the users will see when
they access this application over a WAN.
The AQM methodology recommends a process that
engages application developers and network planners in a development
cycle to experiment with early versions of the application and
determine likely response times and WAN bandwidth required.
If this was the only change made, the gap between the expectation of the
"end user experience" and reality would shrink
dramatically. This would result in less finger-pointing among the
application developers, application deployment staff, network
planners, and network operations teams.
This seems obvious, but it continues to be one of the leading
causes of poor AQM.
The second major problem is based on the very
commonly heard phrase "I'm too busy to plan."
(Remember my mental substitution for “busy”). This commonly heard complaint is based on the assumption that
the components used in planning for application performance are
overly complicated and require a dedicated expert.
While this has been true in the past there are new products
on the market that can make this planning process much quicker
without sacrificing accuracy.
There has been much new activity in the development
of tools used for planning and performance measurement of
application response time - a lot of this in the last year.
One significant trend is the number of service companies that
have emerged to measure response time for Internet-oriented
applications. But the biggest trend is consolidation in a market that used
to be fragmented. In
the past, customers had to be their own integrator of various types
of tools – which truly was time consuming.
At a high level, tools used to be separated into
three types:
n
Measurement/monitoring of the
infrastructure - the "highway"
n
Measurement/monitoring of the
server - the "application"
n
Measurement/monitoring of the
end-to-end application response time - the "user"
The recent consolidation makes it possible now for
a single company to offer tools that correlate these three areas and
arrive at an overall "quality measurement" of the end user
experience.
So, I've covered some of the organizational issues
(many companies have trouble here) and the performance monitoring
tools (most companies have implemented some of these but they still
aren't coordinated). But
there is another area of interest, the ability to predict behavior
before the application is deployed - so called Application Planning
Tools. This is a field
where a lot of work has been done to simplify the process without
sacrificing the accuracy of the results.
Application planning tools can be grouped into two
general areas - Modeling and Stress Testing - and there is a place
for both. In general,
there are two situations that companies face when planning for an
application deployment:
n
Known
Network/Unknown Load: In this situation, there is
an established network and you are trying to determine how much more
application traffic (users) can be put into the network before
increased capacity is needed or before severely degraded response
time. Stress testing is
the best choice here.
n
Known
Load/Unknown Network: In this situation, in trying
to deploy a fixed number of users of an application, you need to
know what kind of network to build to ensure success. Modeling is
the best choice here.
Historically, this planning step has been perceived
as too difficult or costly to do.
But a number of new tools have emerged that make planning a
reasonable job for the average company.
This tools-assisted planning step, executed across the
relevant organizations, and combined with comprehensive application
performance monitoring and management, creates an environment where
companies can finally achieve some level of end user satisfaction
with their application deployments.
In our AQM white paper, we talk in more detail
about the processes and selected tools that can be used to
facilitate the process steps. Acuitive
consultants have done this work and have developed first-hand
knowledge of the potential for success of implementing an
Application Quality Management process.
We hope this information will help both enterprises and
service providers get a better handle on the application issue,
which really is the true measure of the worth of the network.
(volume
3,
number 9)
Send email to
info@acuitive.com with questions or comments about this web
site.
Copyright ©1997-2001 Acuitive, Inc. All Rights Reserved