TPC photo
The TPC defines transaction processing and database benchmarks and delivers trusted results to the industry
    Document Search         Member Login    
     Home
About the TPC
Benchmarks
      Newsletter
      Join the TPC
      Downloads
      Technical Articles
      TPCTC



TPC Benchmark Status
December 1999

TPC Benchmark Status is published about every two months. The first and primary purpose of the newsletter is to keep interested parties informed about the content, issues, and schedule of the TPC's benchmark development efforts. The second purpose is to invite new members to join these important development efforts. We've already outlined most of the reasons for joining the TPC in another article, Why Join. To receive the status report by email, please click here.

Last Meeting
TPC held a General Council meeting on December 8th in Orange County, California. There was one significant development at this meeting: the Council approved the TPC-W specification to go out for mail ballot approval to the TPC membership.

TPC-W Subcommittee
  • TPC Benchmark™ W (TPC-W) is a transactional web benchmark.
  • The workload is performed in a controlled Internet Commerce environment that simulates the activities of a business oriented web server.
  • The workload exercises a breadth of system components associated with such environments.
  • The application portrayed by the benchmark is a Retail Store on the Internet with a customer browse and order scenario.
TPC-W Characteristics
  • Multiple on-line browser sessions.
  • Dynamic page generation with database access and update.
  • Consistent web objects.
  • The simultaneous execution of multiple transaction types that span a breadth of complexity.
  • On-line transaction execution modes.
  • Databases consisting of many tables with a wide variety of sizes, attributes, and relationships.
  • Transaction integrity (ACID properties).
  • Contention on data access and update.
Primary Performance Metric
  • The performance metric reported by TPC-W measures the number of web interactions processed per second.
  • Multiple transactions are used to simulate the business activity of processing an order, and each transaction is subject to a response time constraint.
  • The performance metric for this benchmark is expressed in Web Interactions per second (WIPS).
  • Pricing.
  • 3 year pricing established.
  • 6-month availability.
  • Announced requirements defined.
  • Public, non-TPC, product overview required.
  • Orderable requirements defined: generally orderable through usual and customary channels for company and product of this type.
  • Non-SUT networking component pricing removed.
  • Waive written price quote for items where aggregate effect is less than 1% of total.
  • Roll-forward recovery data must be online.
  • Update for consistent third party pricing with TPC-C.
TPC-W's Three Profiles
TPC-W simulates three different profiles by varying the ratio of browse to buy:
  • Primarily shopping (WIPS),
  • Browsing (WIPSB) and
  • Web-based Ordering (WIPSO).
All references to WIPS (WIPSB, WIPSO) results must include the primary metrics, which are: WIPS rate (WIPS), the associated price per WIPS ($/WIPS), and the availability date of the priced configuration.

Web Interaction
  • Web interaction is a complete cycle of communication between the EB (Emulated Browser) and the SUT.
  • This cycle starts when the EB selects a navigation option from the previously displayed web page or when requesting the Home Page for the first time.
  • It includes one or more exchanges of messages between the SUT and the EB.
  • The cycle is completed when the last byte of data from the response page, including all referenced embedded objects, has been received by the EB.
  • May include one or more database transactions.
Response Time Requirement
  • Shopping cart persistence through session required.
  • Minimum of 2-hour shopping cart persistency after last shopping cart update.
  • Durability and atomic set of operations is required.
Ecommerce Package Requirement
  • The following functions, if used in the benchmark, must be provided by commercially available products and be transparent to the Application Program:
    • Multiplexing
    • Routing
    • Load Balancing
    • Caching
  • The electronic commerce function must include, at minimum, the following capabilities as defined in this specification:
    • Secure Socket Layer (SSL)
    • Shopping Cart
    • Credit Card Verification
    • Secure on-line payment authorization in the benchmark, must be provided by commercially available products and be transparent to the application.
TPC-W Schedule
  • 12/1999: TPC-W submitted for TPC mail ballot approval.
  • 1-2/2000: TPC-W approved.
  • 3-4/2000 results can be published.
TPC-C Subcommittee
John Fowler of Sun, Chair of TPC-C Subcommittee, discussed a few of the comments that the Subcommittee had received when Version 4 of TPC-C, the newest major version of the TPC's OLTP benchmark, was sent out for public and company review. The period for review was extended to 1/31/2000.

TPC-C Version 4.0 Schedule
  • 10/1999: TPC-C V.4 submitted for public and company review.
  • 2/2000: TPC-C V. 4 submitted for TPC mail ballot approval.
  • 5/2000: TPC-C V. 4 approved as an official TPC benchmark.
TPC-R/H Subcommittees
With no new business to conduct, the TPC-R/H Subcommittees did not meet.

The Next Millennium
With any luck at all, the TPC should be ringing in the millennium with two major accomplishments in early 2000: a new TPC-W, our ecommerce web benchmark and a new major version of TPC-C, our primary OLTP benchmark. And that's just in year one of the next 1000! It should be a great next millennium. But let's take them one at a time for now: Happy Holidays and Happy New Year.

All Benchmark Status Reports
 

Valid XHTML 1.0 Transitional Valid CSS!