TPC 벤치마크 C 의 소개:

Order-Entry 벤치마크

By Francois Raab, Walt Kohler, Amitabh Shah
 

Transaction Processing Performance Council(TPC)는 트랜잭션 처리 시스템들의 성능과 가격대비성능을 측정하는 벤치마크의 종류중 세번째를 이제 막 승인하려한다. TPC의 첫번째 벤치마크인 TPC-A처럼, 새로운 TPC 벤치마크 C 또는 TPC-C는 온라인 거래 처리(OLTP) 벤치마크이다. 그러나 TPC-C는 복합적인 트랜잭션 유형, 더 복합한 데이터베이스, 그리고 전체적인 실행 구조 때문에 TPC-A와 다르고 더 복잡하다. TPC-C는 2년전 TPC에 제공된 작업량에 기반을 두고 있으며 산업계의 단면을 대표하는 16명으로 이뤄진 소위원회에 의해 다듬어졌다.

TPC 벤치마크의 목적은 하드웨어나 OS에 상관없이 어느 트랜잭션 처리 시스템상에서 실행될 수 있는 일련의 기능 요구사항을 정의하기 위함이다. 그것은 제품이 모든 요구사항을 만족한다는 증거(완전한 미공개 보고서의 양식으로)로 제출하기 위한 테스트 스폰서를 위한 것이다. 이 방법론은 독점 시스템이나 개방형 시스템을 사용하는 어떤 벤더라도 TPC 벤치마크를 수행하고 동일제품간의 비교를 보려고 하는 엔드유저들에게 보증하도록 해준다. 이것은 테스트 스폰서들이 단 하나의 OS시스템에서 동작하는 장비들을 비교하기나 똑같은 소프트웨어 명령어 집합들을 실행하는 벤치마크들에 제한된 대부분의 여타 벤치마크들로부터의 파격적인 이탈이다.

TPC 벤치마크는 TPC벤치마크들이 UI, 통신방식, 디스크입출력, 데이터 저장, 그리고 백업과 복구 같은 주요 성능 요소들을 평가하지 않을지도 모르는 스탠드단일 컴퓨터 테스트보다는 현실적인 제품 응용 프로그램들과 환경들을 본 따 설계되었다는 점에서 다른 벤치마크들과 다르다. TPC 벤치마크를 설계하는 과정에서 어려움은 주로 시스템 사용률과 동작의 복잡성과 같은 실질적인 성능 특성들을 얻는 동안 제품 응용프로그램에서 발견되는 동작의 복잡성을 줄이는 데 있다. 수많은 기능들이 제품 시스템을 관리하기 위해 수행되어야 한다. 그런 기능들 중에 많은 부분이 시스템 자원 사용률에 있어서나 실행빈도로 볼 때 상대적으로 작은 부분이기 때문에 그것들은 성능분석에 있어 주요한 관심사는 아니다. 비록 그런 기능들이 표준 벤치마크의 정황 아래 제품 시스템에서 중요하긴 하지만, 그것들은 주로 과도한 복잡성과 비용을 발생시키고 그래서 생략된다.

The Benchmark Model

OLTP(온라인 거래 처리) 시스템으로써 TPC-C는 터미널 사용자들의 집합이 데이터베이스에 대한 거래를 실행하는 완벽한 환경을 시뮬레이션한다. 벤치마크는 order-entry 환경의 중요한 행위들에 있어 중심이 된다. 그런 거래들은  입장, 주문 발주, 지불 기록, 주문의 상태확인 그리고 창고의 재고 수준 모니터링 등을 포함한다. 하지만 그것은 압박을 받게 된다. 즉 order-entry 시스템의 최적의 구현을 하기 위한 방법을 지정하기 위한 TPC-C의 의도가 아니라는 것이다. 벤치마크가 도매 업자의 활동을 묘사하는 반면, TPC-C는 어떤 특정한 비즈니스 영역의 활동에 국한되지 않고 관리하고 팔거나 제품 또는 서비스를 배포해야 하는 모든 산업활동을 나타낸다. TPC-C 비즈니스 모델에서 도매 부품 공급자(아래부터 회사라고 칭한다.)가 많은 창고들과 그들과 관계된 판매 지역들을 관리한다. TPC 벤치마크는 회사가 확장하고 새로운 창고들이 생기는 것 따위의 척도를 가늠하기 위해 고안되었다. 하지만 틀림없이 일치하는 요구사항들은 측정된 벤치마크만큼 유지되어야 한다. TPC-C 모델에서 각 창고는 10개의 판매지역에 공급해야 한다. 그리고 각 지역은 3천명의 고객들에게 제공된다. 판매 지역의 운영자는 언제라도 다섯 개의 동작 또는 회사의 주문-발주 시스템에 의해 제공된 거래들 중 하나를 선택할 수 있다. 그들 스스로의 거래들처럼 개별 거래들의 빈도가 실제적인 시나리오를 본 따 설계되었다.

가장 빈번한 거래는 평균적으로 10개의 다른 아이템들로 구성된 새 주문을 입력하는 것으로 구성된다. 각 창고는 회사의 카탈로그에 10만개의 아이템들에 대한 재고를 유지하기 위해 노력하며 그 재고로부터 주문서를 작성한다. 하지만 실제로 한 창고는 아마도 각 주문을 작성하기 위해 요구된 모든 부분을 갖고 있지는 않을 것이다. 그러므로 TPC-C는 모든 주문들의 약 10%가 회사의 다른 창고에 의해 공급될 것을 필요로 한다. 다른 잦은 거래는 고객으로부터 받은 지불을 기록하는 것으로 구성된다. 자주는 아니지만 운영자들은 이전에 받은 주문상태를 요청하고, 배송을 위한 열 개 주문의 묶음을 처리하고 또는 지역 창고에 재고 수준을 조사함으로써 잠재적인 공급 부족에 대해 시스템에 질의할 것이다. 총 5개의 거래 유형들은 이 비즈니스 행위를 본 뜨는데 사용된다. TPC-C에 의해 보고된 성능 척도는 1분당 완전하게 처리될 수 있는 주문들의 수를 계산하고 tpm-C로 표현된다.

TPC-C는 TPC의 DebitCredit 표준 버전인 TPC-A의 많은 특징들을 가져오기 위해 고안되었다. 그러므로 TPC-C는 기본 OLTP 벤치마크의 모든 구성요소들을 포함한다. 벤치마크를 다양한 연산 능력을 가진 시스템에 적용하기 위해, TPC-C 구현은 피측정 시스템의 연산력에 상대적으로 터미널 수와 데이터베이스의 크기를 가늠해야 한다. 피측정 시스템이 충분한 복구 기능으로 완전하게 준비가 된 제품인지 아닌진 테스트하기 위해 데이터베이스는 ACID 속성:atomicity, consistency, isolation, durability (원자수, 경도, 분리, 내구성)으로써 정의된 것을 제공해야 한다. 벤치마크 결과의 독립적인 검증을 용이하게하기 위해 테스트 스폰서는 보고된 성능을 재생산하기 위해 필요한 모든 정보를 완전한 공개 보고서 양식으로 발행해야 한다. 시스템의 처리량을 계산하는 이 성능은 전체 시스템 비용과 함께 보고되어야한다. 전체 시스템 비용은 엔드유저에게 대한 시스템의 벤더에서 제공되는 부분의 실제 액수의 근사치이다. 모든 하드웨어와 소프트웨어 구성요소, 5년간의 유지보수 비용, 보고된 성능에서 1일 8시간 180일의 운용기간에 걸쳐 생성된 데이터를 유지하기 위해 충분한 스토리지 용량.

More OLTP Features and Complexity

TPC-C가 승인이 되면서 TPC는 이제 TPC-A와 TPC-C 라는 두 개의 OLTP 벤치마크를 보유하게 될 것이다. TPC는 최초의 OLTP 벤치마크인 TPC-A에 대한 결과를 계속해서 지원하고 공표할 것이다. TPC-A는 완전한 OLTP 시스템의 모든 중요한 기능들을 시뮬레이트하고 시스템들을 비교하는 다양한 수단으로써 산업계에 의해 지금까지 수용되어 왔다.

With the coming approval of TPC-C, the TPC will have two OLTP benchmarks, TPC-A and TPC-C. The TPC will continue to support and publish results on TPC-A, its first OLTP benchmark. TPC-A simulates all the major functions of a complete OLTP system and has now been accepted by the industry as a valid means of comparing systems.

TPC-C의 도입을 통해, TPC는 산업계에 부수적이고 더 복잡한 OLTP 측정 도구를 제공하고 있다. TPC-C는 온라인에서 실행되거나 혹은 지연된 실행 때문에 대기상태에 있는 다양한 형태와 복잡성을 띈 5가지의 동시 트랜잭션의 혼재를 수반한다. 이것은 다른 습성들을 가진 다중의 트랜잭션들을 시스템 자원을 두고 경쟁하게 함으로써 피측정 시스템의 새로운 구성요소들이 스트레스를 받도록하는 기초적인 OLTP 벤치마크 모델의 가장 본질적인 확장 중의 하나이다. 또 다른 본질적인 확장은 그것의 데이터베이스 구조의 증가된 복잡성이다. 새로운 데이터베이스는 넓은 레코드 범위와 생성 크기를 가진 9개 종류의 레코드로 구성되어 있다. 결과적으로 5가지 트랜잭션 각각에 의해 조작되는 데이터 속에는 더 방대한 다양성이 존재한다. TPC-C에서 수행자에 의해 입력되는 데이터는 현실 세계의 데이터 입력의 기본적인 몇몇 특성들을 포함한다. 예를 들면, 수행자들은 트랜잭션이 취소되도록하는 유효하지 않은 아이템 번호를 입력할 수 도 있다.

With the introduction of TPC-C, the TPC is providing the industry with an additional, more complex OLTP measurement tool. TPC-C involves a mix of five concurrent transactions of different types and complexity either executed on-line or queued for deferred execution. This is one of the most substantial extensions of the basic OLTP benchmarking model as new components of the measured system are being stressed by having multiple transactions of different natures compete for system resources. Another substantial extension is the increased complexity of its database structure. The new database is comprised of nine types of records with a wide range of record and population sizes. As a result, there is greater diversity in the data manipulated by each of the five transactions. The data entered by operators in TPC-C include some of the basic characteristics of real-life data input. For example, operators may enter an invalid item number, forcing the transaction to be cancelled.

더 현실적인 환경을 모델링하려는 시도 속에서 TPC-C는 다른 벤치마크들에서 주로 발견된 인위적인 한계를의 숫자를 줄여간다. 예를 들면, 잘 동작하는 터미널 혹은 워크스테이션 그리고 화면 관리 소프트웨어의 사용을 활성화하기 위해서, TPC-C는 현실 세계의 수행자들에 의해 사용될 수 있는 모든 터미널 입력값들과 화면을 필요로 한다. 이를 위해, 모든 스크린들은 지정된대로 이름이 붙은 입력과 출력 필드를 사용하여 포맷되어야 하며, 입력 필드와 올바르게 정의된 필드에 숫자입력을 통해 앞뒤로 이동하는 것을 포함하는 모든 일반적인 스크린 조작 기능들을 제공해야 한다. 또 다른 영역에서 어떤 물리적 데이터베이스는 TPC-C에서 허용된 데이터의 파티셔닝 혹은 복제같은 현실 세계의 성능을 향상시키기 위해 사용될 수 있는 기술을 설계한다. 트랜잭션에 의한 데이터베이스 레코드의 사용은 테스트 후원자들이 그런 기술들 중 일부에서 비현실적인 장점들을 얻는 것을 배제하기 위해 조심스럽게 정의되어져 왔다.

In moving toward modeling more realistic environments, TPC-C reduces the number of artificial limitations commonly found in other benchmarks. For example, to promote the use of fully-functional terminals or work-stations and screen management software, TPC-C requires all terminal inputs and displays to be usable by real-life operators. To that end, all screens must be formatted using labeled input and output fields, as specified, and must provide all the common screen manipulation features, including moving forward or backward through the input fields and entering numbers in right justified fields. In another area, any physical database design technique that can be used to improve the performance of a real-life application, such as partitioning or replication of data, is allowed in TPC-C. The use of database records by the transactions has been carefully defined to preclude test sponsors from gaining unrealistic advantages from any of these techniques.

A Measure of Business Throughput

The throughput of TPC-C is a direct result of the level of activity at the terminals. Each warehouse has ten terminals and all five transactions are available at each terminal. A remote terminal emulator (RTE) is used to maintain the required mix of transactions over the performance measurement period. This mix represents the complete business processing of an order as it is entered, paid for, checked, and delivered. More specifically, the required mix is defined to produce an equal number of New-Order and Payment transactions and to produce one Delivery transaction, one Order-Status transaction, and one Stock-Level transaction for every ten New-Order transactions.

The tpm-C metric is the number of New-Order transactions executed per minute. Given the required mix and the wide range of complexity and types among the transactions, this metric more closely simulates a complete business activity, not just one or two transactions or computer operations. For this reason, the tpm-C metric is considered to be a measure of business throughput.

The RTE is also used to measure the response time of each transaction and to simulate keying times and think times. The keying time represents the time spent entering data at the terminal and the think time represents the time spent, by the operator, to read the result of the transaction at the terminal before requesting another transaction. Each transaction has a minimum keying time and a minimum think time. In addition, the response time of each transaction must be below a required threshold. These thresholds have been defined to give predominance to New-Order as the performance limiting transaction.

A New Yardstick

Users of benchmark information and results, whether they be members of the press, market researchers, or commercial users, want to be assured that the benchmark results they see are valid measures of performance. To meet that demand, the TPC has designed its benchmarks to simulate and test systems with all the necessary production-oriented features, including backup and recovery features. In addition, the TPC requires complete documentation of the benchmark run (the full disclosure report). These reports are available to any user and pass through the TPC's own internal review process. All these requirements help to ensure that users of TPC benchmark results will see valid, objective measures of performance.

TPC-C follows the TPC's benchmarking philosophy and methodology in all the above respects, but it also includes new elements and more complex requirements. TPC-C's performance measurement metric, tpm-C, does not just measure a few basic computer or database transactions, but measures how many complete business operations can be processed per minute. This new benchmark should give users a more extensive, more complex yardstick for measuring OLTP system performance.