Measuring Software Architecture Performance
Do you know how your software is performing on an hourly, daily, monthly basis? If you operate a distributed or multi-server software architecture you probably should know. My friend, Kirk Pepperdine at http://www.javaperformancetuning.com/ will show you how to find performance problems with his performance anti-patterns. I will talk about how to build performance monitoring so that you can know how your systems are doing at any time.
First, instrumenting the software is EASY. There is really no reason for everyone to do it. Start by deciding what you want to capture. The basics are the time lapse between the the start and end of a method.
public void doApiMethod() {
long start = System.getMilliseconds;
// do some work
long finish = System.getMilliseconds;
Log.logPerformance(29,(finish-start));
}
Ideally, for SOA, you would embed this into your architecture so that no instrument coding would need to be done.
Create a logging class or reuse one of your current ones to store an method ID (29=doApiMethod in this example) and the time lapse. The data should be stored in a non-critical system database so that usage does not affect your overall system performance. Thats it.
1. Create a logging method
2. Write performance data from logging to a database.
3. Instrument methods to write to logging method.
Once you have data for a period of a month or so, you can start to look at your system and watch for performance issues and changes. Issues would be methods that take much longer on average than they should. This is where Kirk can help you. Changes are when the average method time increases suspiciously or dramatically. For example, a method to write a new customer to db averages 60ms and then moves to 300ms. What just happened?
For immediate problems you might start with code that says:
// write to db...
// check for performance issues
if (methodID == 29 && elapsedMs > 200)
doSomeAction();
}
This is the key to the why behind performance monitoring, being able to identify changes in system performance immediately and over time. Once you can do this you can monitor how code, database, system, network, and other dependencies affect your system and proactively manage vs. reactively manage when the system crashes or slows so much no work gets done.

0 Comments:
Post a Comment
<< Home