OSDL-DBT-1


An On-Line Transaction Processing Test Kit



Architecture


Version 1.0



June 20, 2002

Table of Contents

1OSDL Database Test 1 3

1.1Introduction 3

1.2What is TPC-W™ 3

1.3What is OSDL-DBT-1 5

1.4Improper Comparisons 7

2Architecture Design 7

2.1Development Language and APIs 7

2.2The Driver 7

2.3Transaction Management Server 7

2.4The Database 8

2.5Other Design Issues 9

1OSDL Database Test 1

1.1Introduction

The OSDL Database Test 1project (OSDL-DBT-1) is aimed at developing an easy to use transactional test kit to stress the Linux OS and its open source software stack in a manner that could be shared with the wider development community. This test is a simplified derivative of the Transaction Processing Performance Council (TPC) Benchmark Specification W (TPC-W)1. The TPC-Wis used as a template for this test because it is felt that the work done by the TPC reflects a reasonable workload for realistic performance optimization activity.


The TPC-W workload simulates the activities of web users browsing and buying items from an on-line bookstore. The OSDL-DBT-1 test uses the workload characteristics of the TPC-W to create a simplified tool for exposing performance bottlenecks and measuring relative performance enhancements made by open source developers.


Since TPC benchmarks are intended to be used as competitive tools, the results of the OSDL-DBT-1 workload are not comparable in any way to the results of a TPC-W benchmark. The TPC requires all published results to comply with strict publication and auditing rules to ensure fair comparisons between competitors. The TPC rules also require the general availability and disclosure of the pricing for all products used for the benchmark. It is impractical for open source development projects to adhere to these rules; thus, the results reported by the OSDL-DBT-1 test do not constitute a "TPC-W Benchmark". The results of the OSDL-DBT-1 workload are completely incomparable with any TPC-W benchmark.

1.2What is TPC-W™

TPC-W specifies an e-commerce workload that simulates the activities of an on-line bookstore. A typical TPC-W setup includes Remote Browser Emulators (RBE), web servers, and a database. For a complete description of the TPC-W benchmark please refer to the TPC web site at www.tpc.org.


The workload is generated by the RBE. An RBE emulates users that open multiple on-line browser sessions that allow the users to browse and order products. Fourteen web pages are simulated. They are:


One web page represents one web interaction. Each web interaction2 may include one or more exchanges between the System Under Test (SUT) and the Emulated Browser (EB). The exchanges may include the request and communication of cookies, HTML pages, image files or other web objects. According to defined navigation rules, the EBs randomly navigate through the various pages. Those navigation rules simulate the behavior of a real user, and ensure that the access to the 14 pages follows the TPC-W"Web Interaction Mix"3 that defines the range of percentages each transaction falls into.


When receiving a request from the RBE, the web servers access and update the database, generate web pages dynamically, and send the pages back. An e-commerce solution would typically have servers divided into several groups based on their functions. For example, an image server serves .gif and .jpg files, the HTTP server and the application server execute business logic and access the database, and a web cache server serves the cacheable web objects. For the search results web interaction, the TPC-WSpecification allows the use of a commercially available text search engine4, which creates and maintains static indexes outside of the database. TPC-Walso requires a Payment Gateway Emulator to simulate credit card authorizations.


The database consists of many tables with a wide range of sizes and complicated relationships. The database transactions must maintain ACID properties.


Database transaction ACID properties are Atomicity, Consistency, Isolation and Durability. For detailed information, please refer to the TPC-WSpecification Clause 3.1.1, 3.1.2, 3.1.3 and 3.1.4.


Figure 1 shows a typical TPC-W setup:

Figure 1. TPC-W™ Setup

1.3What is OSDL-DBT-1

OSDL-DBT-1 is a transactional based test kit. It drives a database with a similar workload to the one defined by the TPC-WSpecification.


OSDL-DBT-1 consists of a database, a transaction management server and a driver.


Figure 2 illustrates the components in OSDL-DBT-1:

Figure 2. OSDL-DBT-1 Architecture

The OSDL-DBT-1 driver performs similar tasks to the RBE in TPC-W. It generates and manages Emulated Users (EU). The EU follows a similar logic to the EB in the TPC-Wbenchmark, but generates data structures instead of HTTP requests.


While the TPC-Wbenchmark requires web servers to serve web objects, the OSDL-DBT-1 test kit uses the transaction management server to simplify testing and remove an entire layer of web servers.

The transaction management server is the middle tier connecting the driver to the database. It performs transaction management functions. It talks to the database via ODBC.


The databases in OSDL-DBT-1 and TPC-Whave essentially the same table and table definitions, and follow the same population rules. The stored procedures execute similar business logic. Some of the stored procedures in OSDL-DBT-1 return less data than defined for the TPC-W.


For details of the differences between TPC-W and OSDL-DBT-1, please refer to document "Similarities and Differences to the TPC-W Specification".

1.4Improper Comparisons

If you discover any usage of the OSDL-DBT-1 in drawing conclusions about the TPC-W performance, this inappropriate usage should be reported to both the TPC and to the OSDL:

TPC - admin@tpc.org

OSDL- wookie@osdl.org

2Architecture Design

There are three components in the OSDL-DBT-1 kit: the driver, the transaction management server and the database.

2.1Development Language and APIs

The driver and the transaction management server are written in C and use ODBC APIs to initiate the stored procedures. The database used for development is the open source database SAP DB v7.3.0.21. The operating system developed on is RedHat 7.2, but it was designed to run on any standard Linux distribution.

2.2The Driver

The database driver executes a workload on the database system. It is a multi-threaded program where each thread performs the activities of a single user. The driver is compiled into two separate binaries. The first binary (dbdriver_p1) is linked to the ODBC interface and communicates directly with the database; bypassing the transaction manager. This driver can be used for simple functional testing of the database stored procedures. The second binary (dbdriver_p2) is linked against a socket interface to communicate with the transaction management server. This is the main driver for testing performance.

2.3Transaction Management Server

The transaction management server is the middle-tier software. It receives transaction requests from the driver, delivers the query to the database, and returns the query result back to the driver. The transaction management server is configured to create a specified number of database connections, in order to handle a greater number of individual Emulated Users. This allows greater throughput capabilities and gives the overall system a more realistic stress load.


Figure 3 shows the transaction management server and its relationship to the driver and the database.

Figure 3. Transaction Management Serer Architecture

When starting the transaction management server, a fixed number of DoTxn threads are started. Each DoTxn opens a database connection, and then waits for queue elements to arrive in the Transaction Queue.


There is only one thread listening on a dedicated port for incoming connections. When the EU attempts a connection, the listener thread creates a DoConnection thread to service the request.


DoConnection receives the query request from an EU, puts it in the Transaction Queue, tells DoTxn that there is something in the Queue, and then waits for the transaction to be completed.


DoTxn picks up the query request from the Transaction Queue, accesses the database, and notifies DoConnection that the transaction is done. DoConnection then sends the resulting data back to the EU.

2.4The Database

The database is composed of tables, indexes, and stored procedures. The tables hold information about the e-commerce bookstore inventory. The stored procedures execute the queries. The indexes are created to accelerate the queries. Using the database, the Emulated Users can make queries about best selling books, new products, books by specific authors, etc.

2.5Other Design Issues

Aside from the basic files to create and run the OSDL-DBT-1 test, other tools were implemented to support the development and debugging of the OSDL-DBT-1 kit.


A database simulation module was implemented in the transaction management server to assist in the test and debug efforts for the driver and the transaction management server.


Tools were developed to load and test each individual stored procedure, and analyze test run results. Due to limitations in SAP DB repmcli, the loading tool is needed to load large stored procedures. The test tool is compiled into two binaries: odbc_test_p2 and odbc_test_p1. They are used to test stored procedures with and without communicating with the transaction management server respectively.

1 TPC Benchmark W is a registered trademark of the Transaction Processing Performance Council.

2 TPC-W Specification Version 1.7 Clause 2.1.4.

3 TPC-W Specification Version 1.7 Clause 5.2.1.

4 TPC-WSpecification Version 1.7 Clause 2.2.1.5.