Application Profiling is a Packet Level analysis of how given sets of Transactions perform on a Network. It is a Quantitative analysis that allows an experienced Application Profiler to determine the following.
- How will your Application behave as a "network citizen?"
- How chatty is it?
- How much bandwidth will it require? (Think Capacity Planning.)
- How will it scale?
- Are there any bottlenecks?
- How could it be optimized? (Think TCP.)
- How do individual Transactions behave at the Packet Level? (Think APM Architecture.)
For example, one time I did a very simple Application Profiling project that piggy-backed on a Load Test. In it, I saw that TCP Overhead was over 20 percent. The application was going to be servicing thousands of users—with some across a WAN. It would have broken. The issue did NOT show up in the Load Testing software. Once the Development and Server Teams were shown this — it took them under a week to bring that TCP Overhead down to less than 1 percent.
Application Profiling is no harder than setting up a quality Load Test—and is best done without a Load Test running. Ideally, no Synthetic Users are used. No simulated transactions are executed.
Here is how it is done:
The SME of the Application—guided by the Application Profiler—creates "Click Scripts." Click Scripts are simply a set of detailed instructions on how to perform the various transactions that need to be Profiled. They should contain all the information required to assure that any user familiar with the application will execute the transactions the same way--making the same choices. Choices include such items as Account Numbers, Names, which button to click at which part of the transaction, and more. For example, if a User is able to either click on a button on the lower right hand side of the screen--or--click on a Bread Crumb on the top left hand side of the screen—(each of which are expected to do the same thing)—the Click Script should mandate which choice to make. The goal is to have no variation in the way the tests are performed. Once the process of writing the Click Scripts is completed you have a Text Document (not an executable) that contains instructions and screen shots on how to perform the transactions being profiled.
The next step is to map out the InterPath or Data Path that those transactions will take. Which Servers at each Tier are involved? Which Switches--Routers--Firewalls will be crossed?
From there one or more Sniffer or Wireshark devices are placed in key positions to capture Trace Files of the transactions at various positions.
Once all the pieces are in place the transactions are performed by an individual user or by a few users at the same time. The User's Experience is noted and the Trace Files are analyzed by the Application Profiler.
If you have worked with an Application Performance Monitor Tool you will see that many of these steps are similar. In fact, this is the best way to test your APM to see how accurate it is—before you buy.
More details on this process are available in "Application Profiling -- Part Two.
Follow Barry Koplowitz on Twitter @bkoplowitz