The WHAM Tools are used as part of a performance tuning methodology
that has been proven to work by numerous customers as well as WHAM's
consultants over the years. The process begins by understanding the
application architecture and then collecting the appropriate data during
load test, functional tests or even in production problem situations.
Of particular importance is the metric set that is applicable to each
application type. For a batch processing type of application that reads
data from files, processes the data and then writes new records to a
database or new set of flat-files, information about File I/O is
critical. For such an application that spends much of it's time reading
and writing files, it will be important to know the average read/write
rate, the average read/write size, the throughput achieved in bytes per
second and so on. For a web-based multi-tier application with a browser
as a front end, the File I/O activity is less important and network
related measurements become more of the focus. In this case it is important
to have some measure of response time as well as to be able to measure
message size, message throughput, messaging latency and so on. In
addition, it is critical to be able to somehow link the time spent in
each tier of the web-based application to the overall response time
behavior perceived at the browser.
There are many load generation and client point of view tools in the
market today that do a great job of looking at the client side of things.
There are also a number of tools in the market today that do a great
job of looking inside the Java Virtual Machine and providing a JVM or
J2EE specific view of things. These tools in each case are quite expensive
and do not share data, therefore the use of these tools is costly and
not a complete solution to the problem of multi-tier performance analysis
for web-based applications.
Several years ago, before the advent of thin-client web applications, while
WHAM was still a secondary sampling tool albeit at high resolution and low
intrusion cost, it was clear from our experience with client-server apps
that a more robust metric set was needed. The problem we discovered with
only collecting the CPU and memory data that the OS vendors provided, was
that these two measures are only effects and not causes. What that means
is that application behavior produces as an effect, CPU consumption and
memory consumption, but these metrics are not deterministic of response time
or throughput. These metrics may contribute to poor throughput or slow
response time but it isn't enough to say high CPU consumption equals poor
response time. In fact, it is important to use all of the CPU on a system
if that is possible without impacting response time. Full utilization of the CPUs
on a system with acceptable response time means that the resource utility
is maximized. Buying hardware and not using it all is a waste of the
money that purchased the unused portion of the hardware and likewise for
application software such as WebSphere and WebLogic or Oracle that are
licensed per CPU.
In 1998 WHAM added a set of metrics to it's product line that more fully
characterize the behavior of an application than just memory and CPU. This metric set is robust enough
so that it can completely characterize a batch application, client-server
application, Java process or a database application. In short, the 50 additional
metrics that WHAM defined and which we create from within the kernel of
the systems on which our agent resides, are sufficient to completely characterize the
behavior of any application. In analyzing a new application, it is important to
determine which of the WHAM metrics to focus on. With thin-client web-based
applications there are a set of critical WHAM metrics that can be combined to
form a complete picture of the application across multiple tiers simultaneously.
This is the key to quickly solving J2EE based application performance problems.
This example starts by using data collected from our Resolver tools.
The data is read in and analyzed by the Refractor tool.
