An Exception(ally) Bad Start

Software performance engineering (not necessarily tuning) can commence very early on in the development life cycle by focusing on key performance indicators (KPIs) that are independent of the hardware and to some extent the actual runtime and workload characteristics.

Good candidates for leading indicators that measure activities that have a significant effect on future performance of a system|application|request|operation include: database tx count, database query count, remote procedure call count, object allocation count and surprisingly in some cases the number of exceptions thrown and/or logged which is what the remaining of this article will focus on.

The cost of an exception thrown is extremely high in enterprise applications because of the typical depth of call stacks recorded at the point of creation (ignoring some magic VM flags) – a depth which seems to be increasing at a significant rate with the adoption of dependency injection frameworks both within applications and the middleware itself. It is now becoming increasingly common to see call stack depths greater than 320 – costing up to 1/2 second to create and resulting in a relatively significant amount of temporal object allocation (especially if logged repeatedly which is also common). Is this a manufactured problem with a solution in mind. No. This problem has existed for sometime due to poor API design choices in some Java enterprise technologies such as JNDI were a lookup on a context will throw an exception if no binding exists for the name parameter.

Below is a count of the number of methods located in the org.jboss and org.apache packages throwing exceptions during the initial start-up of a JBoss 4.x server instance with a single small web application deployed. Yes 21,236 method invocations with an exception thrown.

Using a JXInsight contextual counter extension we can see the actual methods throwing the exceptions. Yes JNDI related methods are high on the list as is classloading and a some internal plug-in registry class within the JBoss kernel.

Adding in JXInsight contextual counters extensions related to memory profiling provides us with the class of the exceptions instrumented and thrown by instrumented code.

To get an early warning of possible future performance problems start collecting and tracking key performance indicators across builds, tests runs and releases. Pick a few KPI’s that are easy to understand and at a suitable level of abstraction in terms of the software execution and system characteristics. If a significant change is detected in one or more KPI’s for a particular test|use case then investigate and document the reason.

Acquiring knowledge of the software execution model as early as possible increases the effectiveness of not just the development team but both the test and operations teams in delivering and maintaining a system|application in production.