標籤: 暫無標籤

TPC(Transaction Processing Performance Council,事務處理性能委員會的簡稱)是由數10家會員公司創建的非盈利組織,總部設在美國。

天的用戶在選用平台時面對的是一個繽紛繁雜的世界。用戶希望有一種度量標準,能夠量化計算機系統的性能,以此作為選型的依據。作者曾在美國從事過數年計算機性能評價工作,深深體會到,計算機的性能很難用一兩種度量來 評價,而且,任何度量都有其優缺點,尤其是當使用者對性能度量了解不深時,很容易被引入一些誤區,甚至推演出錯誤的結論。本文以TPC基準程序為例,給出一 些實際建議,以幫助用戶避免進入這些誤區。

1 TPC -一、什麼是TPC和tpmC?



tpmC值在國內外被廣 泛用于衡量計算機系統的事務處理能力。但究竟什麼是tpmC值呢?作者曾向一些 用戶、推銷人員乃至某些國外大公司的技術人員問過這個問題,但回答的精確度 與tpmC值的流行程度遠非相稱。tpmC這一度量也常被誤寫為TPM或TPMC。

1、TPC

TPC(Transaction Processing Performance Council,事務處理性能委員會)是由數10家會員公司創建的非盈利組織,總部設在美國。該組織對全世界開放,但迄今為止,絕大多數會員都是美、 日、西歐的大公司。TPC的成員主要是計算機軟硬體廠家,而非計算機用戶,它的功 能是制定商務應用基準程序(Benchmark)的標準規範、性能和價格度量,並管理測 試結果的發布。

TPC的出版物是開放 的,可以通過網路獲取(http://www.tpc.org)。TPC不給出基準程序的代碼,而只 給出基準程序的標準規範(Standard Specification)。任何廠家或其它測試者都可以根據規範,最優地構造出自己的系統(測試平台和測試程序)。為保證測試結果的客觀性,被測試者(通常是廠家)必須提交給TPC一套完整的報告(Full Disclosure Report),包括被測系統的詳細配置、分類價格和包含五年維護費用在內的總價 格。該報告必須由TPC授權的審核員核實(TPC本身並不做審計)。現在全球只有幾個審核員,全部在美國。

2、tpmC

TPC已經推出了四套基準程序,被稱為TPC-A、TPC-B、TPC-C和TPC-D。其中A和B已經過時,不再使用了。TPC-C是在線事務處理(OLTP)的基準程序,TPC-D是決策支持(Decision Support) 的基準程序。TPC即將推TPC-E,作為大型企業(Enterprise)信息服務的基準程序。

TPC-C模擬一個批發 商的貨物管理環境。該批發公司有N個倉庫,每個倉庫供應10個地區,其中每個地 區為3000名顧客服務。在每個倉庫中有10個終端,每一個終端用於一個地區。在運 行時,10×N個終端操作員向公司的資料庫發出5類請求。由於一個倉庫中不可能 存儲公司所有的貨物,有一些請求必須發往其它倉庫,因此,資料庫在邏輯上是 分佈的。N是一個可變參數,測試者可以隨意改變N,以獲得最佳測試效果。

TPC-C使用三種性能 和價格度量,其中性能由TPC-C吞吐率衡量,單位是tpmC。tpm是transactions per minute的簡稱;C指TPC中的C基準程序。它的定義是每分鐘內系統處理的新訂單個數。要注意的是,在處理新訂單的同時,系統還要按表1的要求處理其它4類事務 請求。從表1可以看出,新訂單請求不可能超出全部事務請求的45%,因此,當一個 系統的性能為1000tpmC時,它每分鐘實際處理的請求數是2000多個。價格是指系 統的總價格,單位是美元,而價格性能比則定義為總價格÷性能,單位是$/tpmC。

2 TPC -二、如何衡量計算機系統的性能和價格



在系統選型時,我們一定不要忘記我們是為特定用戶環境中的特定應用選擇系統。切忌為了「與國際接 軌」而盲目套用「國際通用」的東西。在性能評價領域,越是通用的度量常常越是不準確的。據我所知,美國的一些大用戶從不相信任何「國際通用」的度量,而是花相當精力,比如預算的5%,使用自己的應用來測試系統,決定選型。在使用任何一種性能和價格度量時,一定要弄明白該度量的定義,以及它是在什麼系統配置和運行環境下得到的,如何解釋它的意義等。下面我們由好到差討論三種方式。

1、在真實環境中運行 實際應用

最理想的方式是搞一個試點,要求製造商或系統集成商配合將系統(含平台、軟體和操作流程)在一個 實際用戶點真正試運行一段時間。這樣,用戶不僅能看到實際性能,也能觀察到系統是否穩定可靠、使用是否方便、服務是否周到、配置是否足夠、全部價格是否合理。如果一個部門需要購買一批同類的系統,這種方式應列為首選,因為它不僅最精確、穩妥,也常常最有效率,用戶還可先租一套系統作為試點。用這種方式得到的度量值常常具有很明確和實際的含義。

2、使用用戶定義的基準程序

如果由於某種原因第一種方式不可行,用戶可以定義一組含有自己實際應用環境特徵的應用基準程序。 我舉兩個例子:近年來,由於R/3軟體是應用層軟體,SAP公司的基準程序獲得了越來越多國外企業的認可;中國稅務總局最近也開發了自己的基準程序,以幫助稅務系統進行計算機選型。這種方式在中國尤其重要,因為中國的信息系統有其特殊性。

3、使用通用基準程序

如果第1種和第2種方式都不行,則使用如TPC-C之類的通用基準程序,這是不得已的一種近似方法。因 此,tpmC值只能用作參考。我們應當注意以下幾點:

(1)實際應用是否與基準程序相符

絕大多數基準程序都是在美國制訂的,而中國的企事業單位與美國的運作方式常常不一樣(恐怕也不應該或不可能一樣)。在使用TPC-C時,我們應該清楚地知道:我的應用是否符合批發商模式?事務請求是否與表1近似?對響應時間的要求是否滿足表1?如果都不是,則tpmC值的參考價值就不太大了。

(2)TPC度量的解釋

TPC基準程序是用來測系統而不是測主機的,廠家肯定要充分優化他們的被測系統。此處的「系統」包括主機、外設(如硬碟或RAID)、主機端操作系統、資料庫軟體、客戶端計算機及其 操作系統、資料庫軟體和網路連接等。在很多廠家的TPC測試系統中,主機的價格只是系統總價格的1/4或更小,而硬碟的價格有可能佔到總價格的1/3以上,因為TPC-C要求被測系統必須保存180天的事務記錄。如果同樣的主機被用到用戶的環境中,廠家報的tpmC值就意義不大,因為用戶的實際系統與廠家原來用於TPC測試的系統大不一樣。當同樣的主機用在不同的系統中時,tpmC值可能有相當大的變化,現在很多用戶還沒有意識到這一點。

我舉一個例子。假設用 戶希望購買一批同類系統,每一系統至少需要1GB的內存和50GB的硬碟。廠家A、B、C 各報了三個價格相當的系統,tpmC值分別為3000、2800、2600。用戶是否應該選廠 家A的產品呢?答案是:不一定。廠家用於測試tpmC值的系統與實際提供給用戶的系統配置大不一樣。tpmC最低的廠家C提供給用戶的系統反而有可能性能最好,不 論是以實際系統的tpmC值還是以用戶的實際應用性能來衡量。

(3)TPC測試的成本

TPC-C和TPC-D都是很複雜的基準程序,做一個嚴格的測試是很消耗資源的,廠家當然不會說出他們花費了多少錢和時間。但據國外知情人士透露,一個廠家做第一個TPC-C測試需 要幾十萬到上百萬美元的資金和半年左右的時間投入。因此,很多TPC的度量值都 是估計的。由於計算機系統換代頻繁,如果用戶一定要用通過審核的度量值,就必 須多等待半年時間,因此而不能用最先進的系統。中國的廠家通過審核的時間則 更長。

綜上所述,我們對中國 用戶(尤其是大用戶)在計算機系統的選型方面有如下建議:

最好建立一個真實的試點,因為實際應用環境是檢驗計算機系統的最好標準。

中國的行業應該建立符合自己實際應用的基準程序和測試標準。中國稅務總局的做法值得提倡。國家有關部門應該建立獨立的測試中心,制定跨行業、符合中國企事業運作模式的性能測試標準。

「國際通用」的度量可以作為參考值,而不應作為必要條件。尤其是一定要弄清這些流行度量有什麼含義,是在什麼樣的系統環境中測得的,以及基準程序是否符合企業真實的業務流程和運作模式。







--------------------------------------------------------------------------------------------------------------------------------------------------

作為一家非盈利性機構,事務處理性能委員會(TPC)負責定義諸如TPC-C、TPC-H和TPC-W基準測試之類的事務處理與資料庫性能基準測試,並依據這些基準測試項目發布客觀性能數據。TPC基準測試採用極為嚴格的運行環境,並且必須在獨立審計機構監督下進行。委員會成員包括大多數主要資料庫產品廠商以及伺服器硬體系統供應商。

相關企業參與TPC基準測試以期在規定運行環境中獲得客觀性能驗證,並通過應用測試過程中所使用的技術開發出更加強健且更具伸縮性的軟體產品及硬體設備。

TPC-C是一種旨在衡量聯機事務處理(OLTP)系統性能與可伸縮性的行業標準基準測試項目。這種基準測試項目將對包括查詢、更新及隊列式小批量事務在內的廣泛資料庫功能進行測試。許多IT專業人員將TPC-C視為衡量「真實」OLTP系統性能的有效指示器。

TPC-C基準測試針對一種模擬訂單錄入與銷售環境測量每分鐘商業事務(tpmC)吞吐量。特別值得一提的是,它將專門測量系統在同時執行其它四種事務類型(如支付、訂單狀態更新、交付及證券級變更)時每分鐘所生成的新增訂單事務數量。獨立審計機構將負責對基準測試結果進行公證,同時,TPC將出據一份全面徹底的測試報告。這份測試報告可以從TPC Web站點(http://www.tpc.org)上獲得。

tpmC定義: TPC-C的吞吐量,按有效TPC-C配置期間每分鐘處理的平均交易次數測量,至少要運行12分鐘。

1.TPC-C規範概要

TPC-C是專門針對聯機交易處理系統(OLTP系統)的,一般情況下我們也把這類系統稱為業務處理系統。

TPC-C測試規範中模擬了一個比較複雜並具有代表意義的OLTP應用環境:假設有一個大型商品批發商,它擁有若干個分佈在不同區域的商品庫;每個倉庫負責為10個銷售點供貨;每個銷售點為3000個客戶提供服務;每個客戶平均一個訂單有10項產品;所有訂單中約1%的產品在其直接所屬的倉庫中沒有存貨,需要由其他區域的倉庫來供貨。

該系統需要處理的交易為以下幾種:

  New-Order:客戶輸入一筆新的訂貨交易;

  Payment:更新客戶賬戶餘額以反映其支付狀況;

  Delivery:發貨(模擬批處理交易);

  Order-Status:查詢客戶最近交易的狀態;

  Stock-Level:查詢倉庫庫存狀況,以便能夠及時補貨。

對於前四種類型的交易,要求響應時間在5秒以內;對於庫存狀況查詢交易,要求響應時間在20秒以內。



2.評測指標

TPC-C測試規範經過兩年的研製,於1992年7月發布。幾乎所有在OLTP市場提供軟硬體平台的廠商都發布了相應的TPC-C測試結果,隨著計算機技術的不斷發展,這些測試結果也在不斷刷新。

TPC-C的測試結果主要有兩個指標:

● 流量指標(Throughput,簡稱tpmC)

按照TPC的定義,流量指標描述了系統在執行Payment、Order-status、Delivery、Stock-Level這四種交易的同時,每分鐘可以處理多少個New-Order交易。所有交易的響應時間必須滿足TPC-C測試規範的要求。

流量指標值越大越好!

● 性價比(Price/Performance,簡稱Price/tpmC)

即測試系統價格(指在美國的報價)與流量指標的比值。

性價比越小越好!

3.結果發布

各廠商的TPC-C測試結果都按TPC組織規定的兩種形式發布:測試結果概要(Executive Summary)和詳細測試報告(Full Disclosure Report)。測試結果概要中描述了主要的測試指標、測試環境示意圖以及完整的系統配置與報價,而詳細測試報告中除了包含上述內容外,還詳細說明了整個測試環境的設置與測試過程。

P690 tpmC測試值:76,389,839.00

$/tpmC:831.00

美國美金報價:6,349,223.0

CPU數:32

資料庫:IBM DB2 udb 8.1

操作系統:AIX 5L V5.2

中間件:TUXEDO 8.0

測試日期:2003.6.30

P690 TPC-C測試的配置:

1.  後台:1 x eServer pSeries 690 with 32 x 1.7GHz POWER4+ processors with 128MB L3 Cache per MCM (total of four MCMs), 512GB memory

2.  前端:30 x eServer pSeries 630 Model 6E4 each with 4 x 1.0GHz POWER4 CPUs with 32MB L3 cache, 16GB memory

SPECweb:

SPECweb96: 在SPECweb96基準測試程序上實現的每秒鐘超文本傳輸協議(HTTP)操作最多次數,響應時間無明顯退化。

SPECweb99: 接入數,網路伺服器可用預先確定的工作量支持的同時接入數。SPECweb99檢測設備模擬客戶通過慢Internet聯接,向網路伺服器發送HTTP工作量請求。

SPECweb99 測試Web伺服器運行狀況

SPECweb99 是由標準性能評估組織(SPEC)開發的Web伺服器基準測試。它測量滿足特定吞吐量和客戶請求響應速率要求的WEB伺服器的最大併發連接數量。併發連接的合計波特率在320 Kbps到400Kbps範圍內,則滿足相應規範。

SPECweb99 在一台稱為主客戶端的機器上運行,這台機器上包含有允許用戶載入特定負載請求的配置文件。主客戶端也要處理在客戶端和伺服器或測試中的系統(SUT)之間的傳輸協調問題。客戶端通過許多子進程/線程生成獨立HTTP請求流,模擬足夠的負載發送給SUT。



在這個測試中,客戶端向測試中的伺服器發送請求數據。測試規範要求客戶端和伺服器之間的連接不能使用片段大小大於1460比特的TCP協議。因此,每一個客戶端讀取1460比特或更少數據塊的響應。

測試中使用兩種類型的負載量:

靜態負載. 靜態負載具有四種類型的文件。最小的文件的增幅為0.1KB,第二種文件類型的增幅為1KB,最後兩種類型的文件的增幅為10KB和100KB。每一個目錄包含每種類型9個文件共36個文件。

目標請求的文件類型在各類型中分散使用。在每一類中的9個文件中又進行二次分佈。最終目標文件混合為:

35%的請求文件小於1 KB

50%的請求文件小於10 KB

14%的請求文件小於100 KB,但是大於或等於10 KB

1%的請求文件小於1000 KB,但是大於或等於100 KB

動態負載.動態負載是基於廣告和用戶註冊。共有四種在SPECweb99中使用的請求內容類型,分別是標準動態取操作、動態隨機取操作、動態發送操作和客戶圖形介面動態取操作。標準動態取操作和客戶圖形介面動態取操作表現web伺服器的簡單廣告輪轉特性。帶有廣告輪轉的動態取操作追蹤用戶和用戶選擇,所以廣告可以由不同的方式來定製。最終,動態發布實施一個用戶註冊在相應的網站上。

P690 SPECweb99測試值:21,000

Web伺服器:Zeus 4.0

操作系統:AIX 5L V5.1 (64-bit)

CPU數:16

測試日期:2001-10-1

測試配置:16 x 1.3GHz POWER-4 Processors w/1440KB unified on chip L2 cache, 192GB memory, 32 x 32 IBM Gigabit Ethernet-SX PCI controllers, 32 x Gigabit Ethernet network (1 Gigabit/sec  ), 96 x Clients (4 x 375MHz POWER3-II, RS/6000 44P-270), Requested Connections = 21000, Max Fileset Size = 67319.6MB

P650 SPECweb99測試值:12,400

Web伺服器:Zeus 4.1r3

操作系統:AIX 5L V5.2 (64-bit)

CPU數:8

測試日期:2002-10-1

測試配置:8 x 1.45GHz POWER4+ processors w/1.5MB(I+D) unified on chip L2 cache, 32MB unified off chip/SCM L3 cache, 64GB memory, 8 x Gigabit Ethernet-SX PCI-X controllers, 8 x Gigabit Ethernet network (1 Gigabit/sec ), 48 x Clients (6 x 668MHz RS64-IV, pSeries 620 Model 6F1), Requested Connections = 12400, Max Fileset Size = 39801.28MB

p630 SPECweb99測試值:6,895

Web伺服器:Zeus 4.2r1

操作系統:AIX 5L V5.2(64-bit)

CPU數:4

測試日期:2003-2-1

測試配置:4 x 1450MHz POWER4+ Processors w/1536KB(I+D) unified on chip L2 cache, 8MB unified (off chip)/SCM L3 cache, 32GB memory, 4 x Gigabit Ethernet-SX PCI-X controllers, 4 x Gigabit Ethernet networks (1 Gigabit/sec ), 24 x Clients (4 x 375MHz POWER3-II, pSeries 640 Model B80), Requested Connections = 6900, Max Fileset Size = 22199.12MB

NotesBench:

NotesBench是測試各種不同Lotus Notes方面的驅動程序。目的是執行自定義工作量教本中的命令,模擬客戶機的操作。NotesBench測試「僅測試郵件」和「測試郵件和資料庫」。所有已經公布的IBM結果均為「僅測試郵件工作量」。

p680 NotesBench測試值:150,197

用戶數:108,000

平均反應時間:0.584秒

Domino伺服器版本:5.06a

操作系統:AIX 4.3.3

CPU數:4

測試日期:2001.11.20

測試配置:IBM eServer pSeries 680 (24*RS64 IV/600MHz; 96GB RAM, 30 Partitions)

上一篇[恑]    下一篇 [通貨膨脹率]

相關評論

同義詞:暫無同義詞