News: JDBInsight - Performance Tuning and Testing of J2EE Apps
Inspired is pleased to announced JDBInsight a new product, aimed at simplifying the performance tuning and testing of J2EE applications, which access enterprise data through the Java Database Connectivity (JDBC) API.
- Posted by: William Louth
- Posted on: July 31 2001 16:15 EDT
JDBInsight analyses the access of enterprise data by J2EE client-, web-, and bean containers. The analysis can encompass transactional executions spanning multiple J2EE containers. The product captures timing and execution information for enterprise data accessed by Web-, Session-, and Entity Beans using JDBC or an Entity Bean using a container's persistence engine.
With the increasing usage of container-managed persistence (CMP), J2EE developers find it hard to determine what interactions are occurring between the container and database layers. This is further exacerbated with some CMP engines offering sophisticated performance mechanisms, including caching, loading and tuned writes. Though CMP offers many benefits in the development of scaleable enterprise applications delivered on time, it does present developers with problems during testing and performance tuning. One of the main problems faced is that the inner workings of the persistence engine are encapsulated, thus testers are limited to black box testing, which can slow down the development cycle considerably.
JDBInsight has been designed solely with J2EE development and deployment in mind. It offers sophisticated analytical tools, that capture transaction behavior and performance timing across multiple containers in one console, and presents this information intuitively to the developer. The product has been developed by a J2EE tuning expert at Borland, William Louth, who has spent a number of years architecting and developing distributed systems built on top of AppServer and VisiBroker. JDBInsight provides the ability to quickly detect performance bottlenecks within a J2EE system, reducing the need to hire expensive consultants or purchase further hardware. It aids testing by providing the ability to trace an invocation from a client container through to a bean container. During the trace, all database interactions will be recorded for later viewing in the console.
- JDBInsight - Performance Tuning and Testing of J2EE Apps by Anupam Khandelwal on August 01 2001 16:46 EDT
- JDBInsight - Performance Tuning and Testing of J2EE Apps by William Louth on August 02 2001 14:47 EDT
Is there any trial version for the software which works on HP Unix.. We are looking for a profiler to test our application which uses Jrun 3.0..
Based on the emails I have received regarding JDBInsight and how it works I would like to provide a relatively short reply which will be subsequently followed up by an update to the product tour.
Question: Does JDBInsight require code changes?
Answer: JDBInsight should not require any change in your bean code unless ofcourse you want to use the serverside trace and logging features or you have hard coded connect strings. JDBInsight sits ontop of existing Drivers and DataSources and simply delegates all calls to the underlying vendor driver or datasource.
JDBC 1.x Support (Borland AppServer Deployment Example)
simply change to
JDBInsight provides its own ConnectionPoolDataSource that has just one deployment property - the vendor specific datasource jndi-name.
You can point the ejb resource references to an appserver connection pool which can be directed to the oracle datasource or directed to the jdbinsight datasource which is directed to the oracle datasource. This is only a deployment issue and any good appserver should allow all this to be done easily and quickly.
Question: What overhead is incurred with JDBInsight?
Answer: First of the design of JDBInsight was based on the belief that performance tuning and testing should be done before production rollout. CURRENTLY its a tool for developers (I do work during the daytime for Borland).
Having said that JDBInsight has a very sophisticated interception engine which is designed to place as small as possible overhead onto normal JDBC work. Ontop of the interception engine sits services that register with the engine and analyse the calls occuring. Any overhead is probably added by the services. The services provided with JDBInsight include Transaciton, Reference, Lifetime, Utilization, Performance, Tracing and some others. The services activated can be configured onstart up.
The % overhead depends on many factors but currently it stands between 3%-7% on tested systems and I have still some tuning work to do. I should point out that most of the statistics do not include this cost so the data is relatively accurate.
One last point the transaction service's design is based on the assumption that most interaction with the database is done through prepared statements so the services tx path tree should not grow enourmous (note: the service still supports plain statements). The transaction service also compresses tx paths and has mechanisms built in to detect looping. Lets look at a very simple case:
load abean pk=1
delete abean pk=1
load abean pk=1
delete abean pk=2
In the tx pathx this will be translated into (load,delete,commit). This is much better than seeing
(load, delete, load, delete,.....,commit).