What is the standard unit of billing for cloud computing?

What is the standard unit of measurement (billing) for cloud computing? Well if you are using JXInsight Probes for application monitoring, management and billing you have many options that can be combined into one or more rate plans. Most importantly the same metering model is used across these difference perspectives. When you optimize the performance of your cloud computing based applications you can also reduce your cloud computing billing or at least trade speed and scalability for cost in a controlled manner.

The latest early access build of JXInsight 5.7 has been made available with an exciting new capability that allows administrators to define custom resource meters based on the resource metering for a particular probe group using a underlying meter (cpu time, clock time,…) or custom meter.

Tools versus Solutions

The difference between ad-hoc Java troubleshooting tools and application performance management solutions that combine people, process and product is summarized nicely in this famous quote.

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

The difference between a developer and a software performance engineer is that the latter can assign meaning and importance to one or more numbers and knows the how, when, and what of measurement data collection.

JXInsight 5.7.EA.4 Update

We are just preparing the latest early access build of JXInsight 5.7 which includes a new exciting interface, Charge, to the Probes Open API.

We have also worked more on the performance tuning of our Probes runtime further extending our lead in our SPECjvm2008 benchmarks. We have gone from being 17 times faster and more scalable than Sun’s NetBeans Profiler / VisualVM to more than 20 times faster and more scalable. For the other solutions we are more than 100 times faster.

We expect this lead to grow even further with some upcoming native agent changes.

State Observation: The Good (JXI), Bad (JMX), Ugly (JMX)

One of the most common usages of JMX is to make instances of a particular object and its associated state visible from a remote machine for diagnostics purposes. But how easy is it really?

Note: In a mature production environment editing managed object state would have to be performed under change management so access is largely read-only.

Below is a simple Channel class which I would like instances of exposed for remote state inspection. I would like to be able to determine the name of each active channel and its queue state.

The Good Way

Here is how this class could be exposed using JXInsight’s Diagnostics Open API.

One line of code and we get the following runtime state information available in our console which can exported from the server in one snapshot call and saved for offline inspection including the attachment of notes to each object field state node along with class meta data that includes inheritance trees and code sources.

Simple and non-intrusive except for the one line which we will remove at the end completely via AOP.

The Bad Way

Before exposing our Channel via JMX we first need to create a MBean interface class.

Then we need to change our Channel class to implement this MBean interface.

Finally lets change the main class and register the MBean taking into account we must now provide it with a name that is unique to the process.

Here is the MBean displayed in jconsole. We cannot inspect the Queue attribute value because we need to do much more work to make the state associated with non-primitive values visible.

The Ugly Way – More JMX

Well this way is so convoluted and intrusive that I am not even going to bother listing the code here. In short you would need to write one or more wrapper classes that would turn the state associated with queue and its messages (which can hold complex objects) into instances of CompositeData and TabularData. A lot of work for someone just trying to expose state for problem diagnosis of a system.

The Cool Way

To get rid of the Diagnostics.global().set() we can instrument the Channel class at load-time and automatically register new instances with the diagnostics global frame. This is achieved by adding the following META-INF/aop.xml file to the classpath along with our load-time weaving -javaagent argument.

Beats a println() call hands down!

No development of a trace script class. No linking to target classes. No compiling. No deploying. No searching in a log file for a flatlined object state entry.

The difference between a solution designed and a tool developed.

Update #3

Observed objects added to a global, thread, or stack scoped frame in JXInsight Diagnostics runtime are weakly referenced which means you do not have to worry about cleaning up after an observed object is released by the application. With JMX you are forced to develop more code to handle this as the JMX MBeanServer will strongly reference the MBean instance.

Update #2

This same technique can be applied to the remote inspection of HTTP sessions, data grid caches, connections, thread pools, message queues, components, spring contexts, …. We supply 85 technology specific observation extensions today.

Update #1
All is not lost if you do have JMX MBeans with complex object state exposed as attributes but not visible in a remote console such as jconsole. JXInsight has an Insight extension for JMX that creates a repository model within the managed runtime and exports the state it to its remote console client.

javax.management.ObjectName

Every time I look at the javax.management.ObjectName class I cannot help be reminded how important API design is in the eventual performance characteristics of implementations. 

The design of the client interaction for this class is extremely poor excluding many possible performance optimizations in any reasonably safe implementation. Judging by the implementation code itself performance was never a consideration anyway.