Performance Tuning Is A Process--Not A Tool

-MILLION DOLLAR loses occur every day due tomissing the true “gotchas.”
poor application testing plans, too much trust inNetwork & Application testing crosses many
automated testing tools and a general lack of the bigcorporate departments and boundaries. This wears
picture. Plans are made without understanding how ITpeople down and makes them ready to accept any
all works together. Yet more automated tools hit theresult that will at least get the testing completed.
market every day.The results are not surprising from this perspective.
The Web is alive with ads for software that will doThe incident of “successful” application
the following:performance in testing is not equal to the incidence
Analyze your application response time from theof successful application performance in real-life.
perspective of the User experience.Network & application performance problems
End to End transparent application monitoring.continue on--month after month, year after year.
Create “Load” that exactly simulatesUsers stop sending in tickets but still complain to their
user experience.manager. This results in a schism between perceived
Automate application performance analysis &problems and reported problems.
troubleshooting.The Solution:
Based on these products and their claims, you wouldThere is really only one consistently successful
think that the goal of IT Management is to automateapproach to troubleshooting under-performing
all aspects of Network & Applicationnetworks & applications, the Network &
Performance Troubleshooting. Nevertheless, here isApplication Performance Analysis Team. This
an important question: Is that not a little like asking aapproach has a near 100% success rate at providing
chicken to guard the chicken coop? Who isresolution. It involves utilizing a highly skilled
monitoring the monitor tool? Is it not just another“SWAT” team of individuals that look
application? This goes around in circles.at all the component factors. These factors include
Humans use tools, highly skilled and experiencedthe following:
humans. To rely so heavily on automation to monitorServers
other automation is to hope one potential failureDirectory Services
catches another potential failure. Furthermore, ourOperating Systems
experience has shown that companies all too oftenTCP issues
utilize under-skilled staff for these roles, hoping thatOther Protocol Issues
the tool will know what to do with itself or simpleWorkstation builds
default configurations will apply. Catch 22? Well, yes.LAN Issues
You cannot take the need for skill, training andWAN Issues
experience out of the equation; even if you believeUser Skills & Training
automated tools can do the job. Yet experience hasDatabase Optimization
shown that not only do many automated tools notInteraction with other Applications
perform exactly as anticipated, the skill level of theServer Consolidation / Virtualization Issues
human being configuring these tools and tests isThe team works with a client’s Subject
critical to the success of the test.Matter Experts for the application and database
Here are a few typical problems:involved. Frequently, a Network & Application
It is the business user, possibly backed up by thePerformance Analysis Team member is the first to
application Subject Matter Expert (SME) that designsunderstand the application from the bottom up to
most automated application tests. Between themthe top.
there is little expertise regarding the networkPeople working with other humans--interviewing
components, Operating Systems and TCP aspects ofusers, network staff, application staff and
the way the application works on a network--orothers--utilizing protocol analyzers such as Sniffer,
across a WAN. Frequently they create problems thatEthereal, WireShark and others, will find the problem
are not reality based, resulting in testing artificialconsistently. Resolution is always the Primary Goal.
problems due to incomplete testing designs--and