JXInsight 4.0 Released - eXtensible performance managment

Discussions

News: JXInsight 4.0 Released - eXtensible performance managment

  1. JInspired has released JXInsight 4.0, a tool that allows you to see the performance profile of any Java application running in either a stand-alone or distributed computing environment.

    JXInsight augments the JVMPI (the profiling interface of the JVM) to provide comprehensive set of measurements that can be correlated across machines to provide a coherent picture of how an application is performing.

    What is new in JXInsight?

    Server Enhancements
        * Distributed JMS Trace Extension
        * Distributed WLS RMI Tracing (Swing Client to EJB)
        * WorkManager and TimeManager Trace Extension
        * JAX-RPC (WebService) Trace Extension
        * RMI Trace Extension
        * EJB3 Trace Extension
        * Java Connector Architecture (JCA CCI) Trace Extension
        * JTS XAResource Trace Extension
        * Directory/LDAP Trace Extension
        * Java Content Repository (JCR) Trace Extension
        * Java 5 Annotations
        * Hibernate 2.0 / 3.0 Trace Extension
        * JDO (Vendor Neutral) Trace Extension
        * JBoss EJB Interceptor Trace Extension
        * Spring AOP Trace Extension
        * JUnit Trace Extension
        * Apache Ant Trace Extension
        * New JDBC Drivers and DataSources

    Console Enhancements
        * Ease of Use
        * Color Themes
        * Classes Perspective
        * Classifications
        * JDBC Call Trace View
        * Icon Set Redesign and Color Encoding
        * Inject Trace
        * Snapshot Note

    JVMPI Agent Enhancements
        * Platform Support
        * Agent System Properties

    Installation & Deployment Changes
        * Java Libraries
        * System Properties
        * Public Trace Extensions Classes
        * Script Changes
        * Native Agent Library

    Terminal Enhancements
        * Monitor Command Read Insight Article
        * InjectTrace Command

    You can find additional information and screen shots on the JXInsight website.

    Threaded Messages (15)

  2. Pricing schema[ Go to top ]

    Personally, I do not even bother evaluating developer oriented products without clearly visible pricing schema.
  3. Pricing - Explanation[ Go to top ]

    Hi,

    This has been stated over and over again. We are not a company that offers different pricing schemes depending on the size of your pockets/purse/wallet.

    The pricing is withheld initially (not on the website) so that you contact us and so we can assess the level of interest in the product as well as the effectiveness of our pricing scheme.

    I must admit that it troubles me that you have stated this when for a longtime we have allowed unlimited assess to our product (no even contact info needed) and only recently we took steps to limit evaluation abuse.

    Our pricing scheme is extremely simple to calculate across product releases.

    JXInsight Server Edition is ${jxinsight.version} * 1000 USD (2 CPU)
    Additional CPU's for large installations are 500 USD per unit.

    The Workstation Edition has stayed in the range of 695-750 USD across all releases depending on exchange rates and volume.


    Regards,

    William Louth
    JXInsight Product Architect
    CTO, JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  4. Pricing - Explanation[ Go to top ]

    Hi,This has been stated over and over again. We are not a company that offers different pricing schemes depending on the size of your pockets/purse/wallet. The pricing is withheld initially (not on the website) so that you contact us and so we can assess the level of interest in the product as well as the effectiveness of our pricing scheme.
    Thanks for quoting the price. Why do not do that on your web site?
    http://www.jinspired.com/products/jdbinsight/sales_en.html
    No price - not interested to contact, sorry, just sick of sales gimmics.
  5. Pricing - Explanation[ Go to top ]

    Hi,

    We am more than willing to revisit our business marketing and sales decisions. We will have the website updated over the weekend with the published price list.

    Regards,

    William
  6. Pricing - Explanation[ Go to top ]

    Very good. I think you'll find that wise. Personally I also tend to avoid products without a visible price. Printing it up front saves time and effort for all parties.
  7. William,

    do I have to add code (e.g. trace.start/end) to get traces or do you add this via AOP?

    Where do you store the trace output? In a file to analyze it later or do I need your server?

    Do I need a license for the jars etc I need to trace a JVM on a customer's site or is it possible to cover that with just a workstation license?

    The GUI rocks!

    -- Andreas
  8. JXInsight 4.0 - eXtensible Tracing[ Go to top ]

    "do I have to add code (e.g. trace.start/end) to get traces or do you add this via AOP?"

    For J*EE environments we hook mainly into the JNDI calls and proxy the returned objects. This was the approach we took in trying to differentiate between container internal interactions and application component-to-component interaction. This is evident in our usage of the JNDI name for trace identification along with operation name. When a object is returned from JNDI we check whether the instance (and not just the class) should be traced.

    We also provide hooks (interceptors/listeners/filters) into other pre- and post- event dispatching frameworks including CORBA, JBoss Client/Container Interceptors and Weblogic Distributed Tracing (weblogic.trace.Trace).

    For some custom technologies we use AOP (Spring, AspectJ / HP OpenView). We currently create these custom trace extensions ourselves but we are hoping that this will change as we publish more and more of our API and allow more UI customization (trace icons and color schemes).

    All our extensions are built on the following API:
    http://www.jinspired.com/products/jdbinsight/api/com/jinspired/jxinsight/trace/Tracer.html

    It is extremely easy today to download our tool and write a AOP around advice that traces an method invocation.

    Tracer.start("mytid")
    try {
      proceed();
    } finally {
      Tracer.stop();
    }

    What does this give you?
    * An embedded server that allows multiple client management console connections and request processing.
    * Access to many of the useful management capabilities from the JXInsight console including JVM metrics, profiles, timelines, threads, system properties, configurations, class loaders....
    * Your custom traces will have JVMPI statistics including high resolution clock times, cpu times, GC times within trace points (start-stop), thread blocking and waiting and object allocations depending on agent monitoring parameters.
    * The traces will appear within profile and timeline snapshots. The traces may also be associated with other trace extensions including those that spanning multiple JVM's. [We can even trace object allocations across multiple JVMs for a single request.]
    * The traces will have associated callstacks, threads and classloaders.
    * Much more...as well as a UI that ROCKS, ;-).


    "Where do you store the trace output? In a file to analyze it later or do I need your server?"

    The JXInsight server maintains an in memory snapshot file which contains a complete model of the JVM for traces and transactions. There are 3 models: profile, metrics, and timeline. On JVM shutdown each one will by default be written to disk. Client consoles including our command line terminal can also connect and take snapshots and export them to disk. We do not have a single server storing all data as we are used in disconnected environments for self healing / support reporting and analysis with customer products and projects. The distributed tracing correlation can be performed by simply merging and aggregating a set of snapshots within the console by either defining a cluster or selecting multiple exported snapshots.

    An article that describes this better:
    http://www.jinspired.com/products/jdbinsight/corbatracing.html

    "Do I need a license for the jars etc I need to trace a JVM on a customer's site or is it possible to cover that with just a workstation license?"

    Whenever an JXInsight agent is loaded into the JVM a license for the particular machine is required. We do consider OEM deals. We also provide a on-demand temporary evaluation deal for offsite agents which also helps in introducing our product to the customers own operations staff. Typically we will work with the vendor in having an integrated trace extension with product/technology callstack classifications and icons for complete user experience which makes both parties look even more professional in their approach to application performance management and problem resolution.

    Workstation is single CPU. Server is multiple CPU.

    If you send me some product information and software downloads with deployment scenarios we can look into delivering an add-on application management solution to your offering.

    I hope the above information is useful. You should really check out my Insight articles:
    http://www.jinspired.com/products/jdbinsight/insights.html


    Regards,


    William
  9. JXInsight 4.0 - eXtensible Tracing[ Go to top ]

    <blockquote* Your custom traces will have JVMPI statistics including high resolution clock times, cpu times, GC times within trace points (start-stop), thread blocking and waiting and object allocations depending on agent monitoring parameters.
    It looks like a great tool and all but JVMPI is a no-no in 90% of real-world deployments (and even development). I know of several large java shops that can't even start their app with JVMPI (or JVMTI for that matter) turned on. I think what I as a potential customer would like to know are the costs associated with using this tool in development and in production. At a very deep technical level, as this is a developer tool. Real data, no marketing fluff.
  10. JXInsight 4.0 - eXtensible Tracing[ Go to top ]

    Hi,

    Our usage of JVMPI (and soon JVMTI) is minimal. We do not perform heap dumps which tend to bring a JVM down or at least take it out of action for a number of minutes.

    The JVMPI events we listen to are extremely safe and have very small performance overhead. By default our agent listens to Thread Monitor Blocking (Enter+Exit) and Thread Monitor Waiting (Enter + Exit). You can specify -Xrunjdbinsight:a=t to turn on object allocation counting which will slow down the the system (x2) for extremely large applications with lots of temporary allocation. Please note we do not capture the callstack for allocations which really can bring an application to a halt.

    -Xrunjdbinsight:a=t,g=t turns on GC and Object Allocations. Currently I am considering maing g=t the default for the agent the reason I will explain in a future Insight article.

    The only real API call we make is to get the current threads callstack. Again this has little overhead.

    For a long time we ship a script jxinsight-jvmpitest.(bat | sh) that a customer can run to see the actual costs of our JVMPI calls as well as test the accuracy of the metrics reported. Thread CPU times have for a long time not be accurate enough of many JVM's.

    The following is a snippet from a test I just performed on my iMac workstation. The times are in microseconds. Please note that the OSX JRE 1.4.2 JVMPI implementation has a thread cpu bug. Our biggest cost is the getCallFrames which is 22 microseconds. The counters cost of 6 microseconds will likely be reduced even further in a minor release coming soon.

    java.vm.info=mixed mode
    java.version=1.4.2_09
    java.ext.dirs=/Library/Java/Extensions:/System/Libr...
    java.vendor=Apple Computer, Inc.
    java.vendor.url.bug=http://developer.apple.com/java/
    sun.cpu.endian=big
    sun.io.unicode.encoding=UnicodeBig
    mrj.version=232
    sun.cpu.isalist=

    [jvmpitest] starting test loop of 10
    [jvmpitest] check agent clock time using Thread.sleep
    [jvmpitest] sleeping for 2000000 ?s
    [jvmpitest] clock time=2019000 ?s, counter=2001373 ?s
    [jvmpitest] PASSED
    [jvmpitest] check agent clock time using busy loop calling Agent.getClockTime
    [jvmpitest] calling getClockTime for 1000000 times
    [jvmpitest] clock time=376000 ?s, counter=375500 ?s
    [jvmpitest] average clock time per call=0.3755 ?s
    [jvmpitest] PASSED
    [jvmpitest] check agent wait counters using lock.wait(10000) call
    [jvmpitest] counter=10000072 ?s
    [jvmpitest] PASSED
    [jvmpitest] check Agent.fillCounters()
    [jvmpitest] average clock time per call=6.497277 ?s
    [jvmpitest] PASSED
    [jvmpitest] check Agent.getCounters()
    [jvmpitest] average clock time per call=6.134768 ?s
    [jvmpitest] PASSED
    [jvmpitest] check Agent.getThreadCpuTime()
    [jvmpitest] clock time=41674000 ?s, counter=11410416 ?s
    [jvmpitest] average clock time per call=1.426302 ?s
    [jvmpitest] FAILED
    [jvmpitest] check Agent.getCallFrames()
    [jvmpitest] callstack size=103
    [jvmpitest] average clock time per call=22.31838 ?s
    [jvmpitest] PASSED
    [jvmpitest] check Agent.getProcessCpuTime()
    [jvmpitest] clock time=17966000 ?s, counter=17177410 ?s
    [jvmpitest] average clock time per call=8.588705 ?s
    [jvmpitest] PASSED
    [jvmpitest] check Agent.getThreadStartCount()
    [jvmpitest] thread start.count=100
    [jvmpitest] PASSED
    [jvmpitest] check agent clock time using Thread.sleep
    [jvmpitest] sleeping for 2000000 ?s
    [jvmpitest] clock time=2001000 ?s, counter=2001280 ?s
    [jvmpitest] PASSED
    [jvmpitest] check agent clock time using busy loop calling Agent.getClockTime
    [jvmpitest] calling getClockTime for 1000000 times
    [jvmpitest] clock time=341000 ?s, counter=341311 ?s
    [jvmpitest] average clock time per call=0.341311 ?s
    [jvmpitest] PASSED
    [jvmpitest] check agent wait counters using lock.wait(10000) call
    [jvmpitest] counter=10000071 ?s
    [jvmpitest] PASSED

    If we did not use JVMPI we could never provide true clock times adjusted for GC events. Not adjusting for GC will have many developers chasing red herrings. This happens today in all other tools on the market. We are the only tool that recognises that a GC event is an environment factor that must be discounted as a developer has no control over it. Again I have a Insight article coming out discussing the importance of this.

    This tool can be used by developers, testers, architects, and operations because these are the roles I myself have taken on during my previous and current engagements. Naturally the tool has been largely designed and developed for a developer and performance engineer like myself.


    Regards,

    William Louth
    JXInsight Product Architect
    CTO, JInspired


    "J*EE tuning, testing, tracing with JXInsight"
    http://www.jinspired.com
  11. JXInsight 4.0 - eXtensible Tracing[ Go to top ]

    Just to be clear does one need to run the JVM with jvmpi turned on to use this tool? if not, what functionality would I be missing if I were to run it without?
  12. JXInsight 4.0 - eXtensible Tracing[ Go to top ]

    Hi,

    You need to run the JVM with the following VM parameter
    -Xrunjdbinsight

    The -Xrun tells the JVM (not JVMPI) to load the native library on start up. When our library is loaded the agent registers witht eh JVMPI API an event listener for those events you are interested in.

    Once again our agent uses a small and limited part of the JVMPI API and to date we have not had a single report of a crash coming from native code with the JVM or Agent. I am speaking truthfully.

    There are parts of the JVMPI API that are not scalable (heap dumps) which can of course crash a JVM of significant size but to be honest many of the JVMPI horror stories are related to incorrect behavior of the JVMPI API (event ordering) which were not handled safely by other JVMPI agents resulting in native crashes. The JVMPI aspect of the JVM will not crash a JVM more than likely it will be the agent and its additional native memory requirements and exception handling. JXInsight stores most (95%) of its data on the Java heap.

    We need the JVMPI agent for:
    - Reverse Engineer Protection (most of our bytecode code is encrypted)
    - Fast creation of thread call stacks
    - GC events
    - Thread Blocking and Waiting
    - Class load events for limited class instrumention

    Regards,

    William
  13. JXInsight 4.0 - eXtensible Tracing[ Go to top ]

    Some additional requirements:

    We need the JVMPI agent for:
    ....
    - Thread CPU Times
    - Object Allocation Events with no expensive callstack analysis


    Regards,

    William
  14. Hi All,

    I was reading the latest Java Performance Tuning (http://www.javaperformancetuning.com) Monthly newsletter , which unfortunately did not list our product release, and I stumbled upon an IBM Rational TestStudio article which discussed the difficulties in relating a single use (test) case with multiple transactions and component interactions.

    Well this gave me the inspiration for an article about one of the many new innovative features in JXInsight 4.0.
     http://www.jinspired.com/products/jdbinsight/usertesting.html

    <extract>
    Many testing teams struggle trying to relate multiple transactions (HTTP/RMI/IIOP) and component interactions with a single use case. Displaying even a single webpage or a form within a client application can result in many round trips between the client and server, and server and backend resource (message system or relation database). In this article I will highlight an innovative solution to the problem that is rather simple (as are most good ideas) but extremely powerful - JXInsight's Injected Traces.
    </extract>


    Regards,


    William Louth
    JXInsight Product Architect
    CTO, JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  15. Thanks for the infos. I'll check it out (just sent the eval request).

    What about to offer a light version of your product which doesn't have J2EE-specific API tracing but simple JVM performance and allocation analysis like JProfler?

    -- Andreas
  16. Hi Andreas,

    JXInsight was designed so that it could be used as a plug-in replacement for many custom tracing solutions being built today.

    Every company appears to have a dedicated team providing a shared trace component solution. Unfortunately the solutions have little tooling support and in general poor execution context capture capabilities outside of the application domain itself.

    I think it is impossible to stop developers writing their tracing solution so instead we provide them with an API that could easily be plugged in underneath their own solution giving them immediately a powerful user interface that can connect to multiple traced clients and servers retrieving and merging snapshots into a user defined cluster which can then be analysed, annotated and shared.

    With that in mind we have considered offering "a build your own distributed Java application performance management" solution that could be distributed with products and deployed into custom applications at an extremely low price. The console will be streamlined with the J*EE extensions removed.

    For the next release the plan is to enhance our snapshot analysis capabilities in the area of trace patterns, problem inspections, comparsions, and reporting so this type of solution is even more compelling than it is today. We are also planning on offering an add-on that simplifies trace extension building via AOP but without the need to understand a pointcut language (point, click and trace).

    Regards,

    William