 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 4: ECperf Benchmark Specification
Original Java Specification Request (JSR) Identification | Request | Contributions Section 1: Identification
Submitting Participant: Shanti Subramanyam, Senior Staff Engineer,
e-mail: shanti.subramanyam@sun.com
Section 2: Request
Targeted JavaTM Platform: Server/EJB Need: Performance assessment and improvement of EJB server/containers, including database access. Inappropriateness of existing workloads: Existing pertinent performance workloads (eg, TPC-C, TPC-W, SPECjvm, etc) are targeted to different and limited requirements. TPC-C represents standard OLTP transaction processing in a client/server environment. TPC-W represents standard web server multiplexing to a database. SPECjvm measures computer system performance for Java virtual machine* (JVM) client platforms. None of these workloads capture the gestalt of EJB: distributed, transactionally oriented components. Specification: The ECperf specification describes a distributed, transactionally oriented workload metaphor, manifested in the form of a detailed component specification. The spec also specifies necessary run rules, a workload metric, how the workload scales, etc. A draft spec is already written, as are the EJB components that implement it. Underlying Technology: EJB API's; commercial EJB server/containers. Proposed package name for API specification: N/A. Workload name is ECperf. Possible platform dependencies: Database DDL for table creation and load are O/S and DBMS dependent. Instantiation of RTE agents is O/S dependent. Everything else depends only on 100% pure Java and an EJB server/container that is compliant to the EJB specification. Security, Internationalization, and Localization implications: Not an API spec. These characteristics are relevant to the extent that they impact performance in an interesting or useful way (security, for example). Risk Assessment: Risks include failure of the Java platform due to poor performance; definition and domination of the distributed, transactional component performance agenda by a leading competitor; default use of TPC-C or TPC-W by the industry, thus selling the EJB promise short; and unilateral creation of EJB performance workloads by any or all of the many EJB server/containers. Re RI/CTS, the performance kit is each of these, and the workload can't be run unless the performance kit exists. Note that a verification audit is required, as is publication of a Full Disclosure Report. Existing specs rendered obsolete by this work: None, although without Ecperf, TPC-C or TPC-W may come to be the default EJB performance workloads. Existing specs that might need revisions as a result of this work: None, although see the previous paragraph. Section 3: Contributions
Contact Shanti Subramanyam at Sun (shanti.subramanyam@sun.com) for details on the current state of the Ecperf work that will serve as a starting point. This project would benefit particularly from the participation of ISV's
that develop EJB server/containers and others who are interested in this
area.
|
