2

 
 
By eweek  |  Posted 2006-05-15 Email Print this article Print
 
 
 
 
 
 
 


There are classic mistakes in Java programming, things like string manipulations that create huge overheads and that developers learn to avoid at the level of application code. Are there similar types of common errors that you encounter at the level of end-to-end application performance analysis?

Narahari: Developers are sometimes negligent about object creation and the management of object lifetime. They assume that Javas garbage collection will handle everything. We look for leaks and for repeated object creation. Fixing those problems can give a lot of improvement.

The second area we see is interaction between the Java layer and the database layer: Your optimization in [JDBC (Java Database Connectivity)] code can give a lot of performance improvement, and its important to be able to correlate whats happening in J2EE [Java 2 Platform, Enterprise Edition] with whats happening in the database. When you can see that connection, you find yourself saying, I didnt realize that the query would execute like this; let me change my JDBC statement on the J2EE side."

It sounds as if you have to maintain a perspective on the full stack, so that youre never limiting yourself to solving "Java problems" but always thinking about "application problems."

Maness: That is exactly the way we built the product. We took a blueprint of the application transaction path. We said, OK, if you really look at performance, you have to have information from each point in the path as well as the network itself. [That lets you] get a real breakdown of what response time means and, if you have a problem, where to find it and troubleshoot it.

Not just each tier, but each component within the tier—in the database, the tables and views; in the Java tier, the methods and strings. These things get complex. At the end of the day, the value is not in managing a silo or a segmented tier but in managing that tier in the context of what the user is doing.

Looking at the arc of complexity of Java, its almost hard to recognize the language that we first saw in the late 1990s—but the last two years of JavaOne conferences have seen growing emphasis on manageability. Are there any key Java technologies that you expect to see highlighted at this years conference to help developers handle enterprise workloads?

Maness: I think there will be a lot of discussion around instrumentation: around understanding complexity without hogging the server CPU so that the instrumentation becomes a problem in itself. Thats central to the way were looking at the world [and working to make it] so that J2EE becomes more manageable.

Narahari: One [Java Specification Request] thats very interesting to us is JSR 168, the portlet specification. Our interest is in the adoption of that standard by the portal vendors, which is very much in the interest of the customers.

Maness: Thats right. And our [i3 version] 7.5 product instruments and manages performance on any JSR 168-compliant server. That really expands the activity that were doing around performance management, and its the JSR were most interested in driving forward and being part of.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.


 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel