Shanti Subramanyam

Sun Microsystems, Inc.

 

Art Technology Group Inc.(ATG)		BEA Systems		Borland Software Corporation
Hewlett-Packard		IBM		Informix Software
IONA Technologies PLC		iPlanet		Oracle
Sun Microsystems, Inc.		Sybase

Expert Group Private Page

JSR Community Update Page

 

Original Java Specification Request (JSR)

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 Java^TM 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.