How to formalize your application’s performance monitoring? Do you rather buy a solution, or build your own, or simply call your vendors and demand a solution? NOW!
If your are of the do-it-yourself type, then keep reading below:
How Should a Performance Monitoring/Management Project be Carried Out?
Simply, the basic ingredient is smart engineers and “divide and conquer” but tempered with keeping a keen eye on achievable results that maximize return on investment.
1. Scope What is Important to End-Users.
The first step that is essential to success is actually seldom performed as it is generally obvious to end-users, but difficult to express technologically unless it is consciously researched. This step consists in finding out what subsets of the software’s functionality are truly important to end-users as they carry out their daily work. This is an essential step. If you end up identifying the wrong metric, all subsequent work can be carried out brilliantly, but there would be a good chance that you will fail to identify the performance bottlenecks that are most annoying to your users.
2. Create an Application Diagram
A great (at least initial) approach is to map out a complete diagram that illustrates how an application works. The easy approach to doing this is to list all communication and network pathways between users, servers, interfaces, sites, etc. These pathways need to be limited down to TCP/IP ports, should indicate if the network connectivity is connectionless or stateful, what higher level protocol they implement (say XML or HL7) and so forth.
3. Nibble and Take Incremental Steps, then Create Monitors and Probes
While monitoring and performance management does need a critical mass of work to obtain best results, the first inclination (and generally a mistake) is generally trying to do too much –which by its very nature assumes that the job will be easy (something that or might not be the case).
It is in general better to come up with a succinct yet broad (in terms of product functionality) set of information flows to implement or monitor usually by examining (or generating) network traffic.
4. Build your Monitors!
Create monitors (TCP/IP probes, stateless calls, etc) to gather timing data. Then observe if the information gleamed from this monitoring corresponds with application performance as perceived by end-users, help desk, and IT staff. If there seems to be no correlation, it is necessary to figure out why! Is the traffic observed or generated related to the set of transactions critical to the users’ experience?
4. As You Incrementally Build – Know When to Stop
After the previous steps prove successful it might be tempting to go back and add more and more probes. However, something to consider is that not only might there be diminishing returns, but that the amount of information gleamed might become harder and harder to interpret. For example, tracking the fluctuations of three metrics might be effective. Having more than that can be of questionable value… In theory, tracking fifteen or more user response metrics might be more comprehensive. Yet by having so many data points to analyze, it might become humanly impossible to analyze it… Too much information becomes muddled into noise.
5. Keep your Investment Up to Date
As your application changes, modification to your scripts (if generating traffic) or to your dashboards and observed metrics (if using an APM package) might become necessary. There is no better time to carefully look at timing and response data prior to an upgrade or hardware modification, but occasionally products change so deeply that re-visiting scripts and assumptions (including the network and connectivity diagram) might become overdue.
6. Relax and be Happy!
Yup, enjoy being the master of your applications!