Proposal
Identification | Request | Contributions
Section 1: Identification
Submitting Participant:
Shanti Subramanyam, Senior Staff Engineer,
Performance Application Engineering Group
Sun Microsystems, Inc.
e-mail: shanti.subramanyam@sun.com
voice: 650-786-6147
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.
*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.
