I talked with nVision Software’s Juan Cabezas and Ted Hulick yesterday afternoon to get a more in-depth technical overview of how nVision’s AppVision works. (Thanks to both of them for making the time ;>)
Ted seemed quite passionate about systems management and, having been in the industry for for a while, is very eager to “do things right this time.” Technical passion for systems management can be hard to find, and it’s key for up-and-coming companies: otherwise, you might end up with the same old thing.
Beyond Instrumenting
Here are some highlights:
- From the discussion that we had, it seems like it’s technologically quite clever. On the Java side, there’s classloader magic that allows AppVision to do light-weight instrumentation, in runtime, or VMs. The .Net technology is a bit thornier apparently as .Net runs with more security options on by default (most Java apps don’t go hog-wild with
SecurityManager) and there’s apparently more hidden voodoo in .Net than Java. - Relevant to the current open sourcing Java discussion, Ted said that access to the Java source over the years (before it being technically “open source”) has been great.
- Their overall systems management philosophy was along the lines of the New Systems Management think that I’ve been seeing. In the words of Ted: “no metrics.” There’s, of course, over-statement in that. The point isn’t that there are absolutely no measurements or measuring going on. The point is more to value judgments and conclusions over raw data.
- There’s an emerging world of non-traditional devices, like VoIP phones which are essentially just little computers — that are beefy enough to run Java and .Net. Meaning, there are new types of devices to monitor and manage.
- While BCEL is “fine,” nVision wrote their own byte-code library to get complete control over that core part of their stack.
- AppVision is built on a plugin architecture.
- The “symbiont” (the code that AppVision runs in the host VM or CLR) can be cut down to a few 100K. This is important, of course, for using less than, as Ted said, 5% or less of the host’s resources. With that AppVision to target not only desktops and servers, but the wider range of devices mentioned above in addition to realtime systems.
- Along those performance lines, AppVision doesn’t do method-level tracking. Instead, it pays attention to explicit error states (like exceptions) and only instruments key parts of the application (like the
main()method/class). - We talked a fair amount about scaling at the database level and scaling in general. That’s encouraging, of course, because scale is the mid-life crisis of all systems management tools and platforms.
We of course covered more detail. The AppVision 5.0 page actually goes into a fair level of detail as well.
In the Labs
Overall, my theory is that AppVision would be a great “debugging in the field” tool. I’ve longed for a “headless profiler” for sometime, and the approach that AppVision has taken might shoe-horn into that. We’ll see.
As the use of the word “theory” implies, all of this discussion comes with the disclaimer that it’s just been discussion up to this point, I can’t vouch for nVision and AppVision beyond that. Also, I still haven’t tried the application out on my own, but I should be getting an evaluation/demo copy sometime soon. I’d be interested in any “tests” or “scenarios” you, dear readers, have in mind.
Tags: .net, bytecode, instrumentation, java, nvision, profilers
Recent Comments