This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
I am using a proprietary framework in our project. I need a help in regard for an approach to calculate the time elapsed in the different layers of the framework.
We are having different back ends to connect. The current proprietary framework has the layer (tier) wise approach to connect to back end. We are placing our requests through the access layer calling the remote EJB methods, which will in turn connect to builder and builder calls back end.
We already have abstractions for RDBMS/Queues and other back-ends where we can add instrumentation logic. However, we have issue in calculating end to end time elapsed without intruding client code and providing generic solution. It looks like as of now, there are no clear-cut entry and exit methods at client level. (Each client invokes different remote methods on remote objects. No controller in between).Is there any approach that lets to add end - end instrumentation without disturbing existing code.
A couple come to mind, but they are surely non-trivial to do.
Aspect Oriented Programming (AOP) is good for this kind of thing. You define "cut points" where you'd like to insert code and the AOP processor puts in things like methodEntry() and methodExit() calls to a metrics engine. I haven't used any AOP tools, but I think you'd have to have source code so you can build an instrumented client ... sounds like you might not have that.
Another approach is byte code modification in the class loader. We use a tool called Wily Introscope (very big bucks) that does this. You tell it what classes and methods to modify and it inserts instrumentation as it loads the class. Software Development magazine had an article about how this approach worked out for a profiler in one of the big IDEs. The article says the developer identifies a "root" method and the tool automatically instruments every called method to give a complete breakdown of the timings. Do you have the budget or skills to buy or build such a thing?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Feb 21, 2006
Thanks for your reply. We considered AOP while evaluating our options. Is inserting bytecodes to add this profiling aspect, not going to alter actual metrics? (means an additional processing because of these additional bytes..) Also does this require a separate compiler to generate these additional byte codes? What is additional overhead in multisite deployment of the system? (Mean every client need to use this new compiler while using our code?)
Please let us know.
Joined: Jan 29, 2003
There are some neat packages to insert byte codes into classes. Some use native Java syntax so you don't have to learn byte codes yourself. I can't recall the names; maybe somebody will chime in with them. You'd have to deploy whatever jars those packages use. Getting the custom class loader in place might actually be more of a challenge, depending on the container.
Yes, any instrumentation affects the application. That SD article compared tightly focused instrumentation of one method call stack to a shotgun approach across the whole app and naturally came out with much less impact. If you have a pretty good idea where to look for a problem you can instrument a small part of the app and minimize the impact.
My open source project is called JAMon and it does a nice job of keeping summary performance statistics. If you have servlets then you can monitor page performance (hits,avg,total,min,max and some concurrency stats) without changing your code. Just add the jar and reference the jamon servlet filter to your web.xml. (see the jamon link below)
If you are already instrumenting your code in places, then jamon might provide better info. Also next week I am releasing jamon 2.0 which will give you even more capabilities for monitoring your application.
It doesn't monitor each tier though.
Here is how you would use it.
[ February 25, 2006: Message edited by: steve souza ]