ECperf Uncovered Whitepaper Available


News: ECperf Uncovered Whitepaper Available

  1. ECperf Uncovered Whitepaper Available (2 messages)

    Inspired today announced that it is making available a white paper, "ECperf Uncovered" which provides an insight into the transactional execution plans of 3 application server vendors - BEA, Borland and Pramati. Also announced is version 1.2 of JDBInsight, a performance optimization tool that captures timing and execution information for JDBC access data.

    Visit: Inspired.
    Download: ECperf Uncovered.

    Press Release
    Dublin, Ireland, September 4, 2002 – Inspired today announced that it is making available a white paper, "ECperf Uncovered" which provides an insight into the transactional execution plans of 3 application server vendors - BEA, Borland and Pramati.

    Visit: Inspired
    Download: ECperf Uncovered.

    Inspired has also announced that the next release of JDBInsight will include a developer edition priced at 150 USD to allow JDBInsight to be used throughout the development lifecycle. With this announcement developers can start to target J2EE performance bottlenecks, JDBC resource bugs, and incorrect persistence mappings from the start, further reducing overall development costs.

    About JDBInsight
    JDBInsight is an innovative enterprise development product, aimed at simplifying the performance tuning and testing of J2EE™ applications, which access data through the Java Database Connectivity (JDBC™) API. JDBInsight analyses the access of enterprise data by J2EE™ client-, web-, and bean containers. The analysis can encompass transaction executions, spanning multiple J2EE™ containers. JDBInsight captures timing and execution information for enterprise data accessed by Servlets, JavaServer Pages, Session- and Entity Beans using JDBC™ or an Entity Bean using a container's persistence engine.

    JDBInsight provides the ability to quickly detect performance bottlenecks within a J2EE™ system, reducing the need to hire expensive performance tuning consultants, allocating valuable development resources or purchasing further hardware to compensate for lack of tuning. It aids testing by providing the ability to create snapshots of the database interaction during test runs.

    William Louth
  2. This report shows that Borland Enterprise Server 5.02 has the best CMP 1.1 engine, even somewhat (although marginally) better then BEA's 7.0.

    Pramati is no competitor because their CMP engine uses pessimistic locking, although pessimistic locking could be
    useful in some scenarios.

  3. Mileta,

    This report does not set out to determine which vendors cmp engine is the best. What it attempts to show is the transactional characteristics of ECperf and the various deployment configurations applied by vendors in their kits.

    Issues with the execution of the ECperfs are highlighted in the analysis but strangely not one vendor has come forward to provide an explanation.

    I have since 1999 advocated CMP 1.1 - along time before anyone would even consider Entity Beans (Book: J2EE in Practice). CMP 1.1 could be used to build large scale systems if it was implemented correctly by vendors. CMP 2 just makes it that must easier for them and also increases the flexibility and power of entity beans.

    Borlands CMP 1.1 engine was for along time ahead of the packk but that is not the case anymore with BEA making great strides with WLS 6.0 and WLS 7.0. BEA and Borland CMP engines are near identical (in relation to ECperf).

    There is still much more that can be done by these engines. Such as realtime profiling (by the cmp engines) used to determine what type of connection to give out. Read-only connections could be dispensed for entry points which have been determined as not altering persistent state. Most developers to this day partition CRUD across different methods within an session bean. A good appserver vendor could apply this heuristic in the creation of more efficient connections and in the reduction of overall prepared statements.

    In ECperf 1.1 there is now a requirement on certain beans for "select for update" calls. Pramati just adopted this from day one.