采用鋪底數據進行 SOA 應用的性能測試

在大規模 SOA 應用的性能測試中，一個很重要的事就是準備鋪底數據。所謂鋪底數據，即在性能測試之前人工的向數據庫里面存入用來模擬歷史的或無用的大量數據。那么，為什么要準備鋪底數據呢？通常情況下，準備大概每個表 1 G 的數據，數據量大概是每張表大于 5000 萬條數據，如何快捷真實的準備鋪底數據呢？本文還將簡單介紹一下在性能測試的時候為什么需要搭建 WebSphere Process Sever (WPS) Cluster，以及如何搭建 WPS Cluster。最后，通過 Rational Performance Tester (RPT) 7 結合 WPS 集群進行性能測試，并分析比較在 WPS 服務器下的有無鋪底數據支持的性能。

場景及背景介紹

本文假設對某大型 SOA 系統進行的性能測試。其中主要的測試場景是案例的申請，保證所有在線用戶同時在線錄入檔案。測試場景包括了創建成員的信息、收入及支出信息和提交救援案例的申請。共有 10 個 web services。

在這個系統中，性能測試需要模擬很多人同時在線的情景，通過性能測試工具能模擬任意多的人同時在線，而且要保證系統性能穩定，不論任何時候都要保證系統的請求和響應時間基本保持穩定，不會隨著數據庫的數據的增加而變慢?；谶@些問題，就需要找到一種有效的方式來對系統進行性能測試。

soa/?S_TACT=105AGX52&S_CMP=NL&ca=dnl-cn-04022008#main" cmImpressionSent="1">回頁首

1. 為什么要準備鋪底數據

在上面的場景中，需要一個長時間穩定的環境，那我們就可以增大數據庫里面的數據量，并用一些負載平衡的應用服務器環境。綜上所述，可以在數據庫里面存入鋪底數據，在服務器端搭建集群服務器。

那么如何制作鋪底數據呢？以下的幾段我們將詳細闡述。

1.1 什么是鋪底數據

鋪底數據就是我們在做性能測試之前，在數據庫里面除數據庫字典表外按照業務邏輯存入的大量的數據。這些數據可以視為垃圾數據，因為它們對系統的業務邏輯沒有實際的影響，但對系統的性能卻有著很大的影響。

• 鋪底數據需要按照實際的情況去生成，要符合實際的生產情況的表的數據比例。譬如：有一張表的數據量和另外一張表的倍數關系是 5:1，那么準備數據的時候不論準備的數據是多少條，也需要保證這兩個表的數據量的倍數是 5:1。
• 鋪底數據雖然是垃圾數據，但同樣需要遵守數據庫中數據的依賴關系。比如一對一，一對多的關系。

如下是我們在性能測試中準備的數據：

在性能測試之前在 DB2 里面準備的鋪底數據，總量是：10.5 GB。

表 1：在性能測試之前在 DB2 里面準備的鋪底數據

Table Name	Data size(KB)	Data Count
Interested_party	3,630,594	7,730,000
Address	178,600	1,230,000
Interested_party_type_association	760,719	7,720,000
Household_member	546,328	4,487,000
Household	28,840	1,239,000
Document	610,632	5,251,000
Interested_party_association	542,390	4,958,000
Interested_party_address	99,602	1,232,000
Contact_phone	143,581	1,232,000
Address_contact_phone	109,356	1,232,000
Case	269,039	2,479,000
Case_document_association	22,731	1,235,000
Case_party_association	537,562	4,958,000
Evidence	2,793,073	43,295,000
evidence_party_association	796,680	43,295,000

1.2 有沒有鋪底數據的性能會有很大差異

或許你會問，為什么要準備這些鋪底數據？這些數據不是我們的實際生產環境的數據，那為什么要花時間去準備如此大量的數據呢？

答案是，系統在有鋪底數據和沒有鋪底數據的情況下，性能會有很大的差異。那為什么會這樣呢?

• 首先，如果沒有那些鋪底數據，那么本來為一張表建立了一個索引，當系統的數據量很小的時候，數據庫就有可能造成全表掃描，而不走索引掃描，這樣就會造成系統的性能降低。
• 如果數據量很小的話，我們不知道進行一次查詢時候的 SQL 語句究竟是哪種執行路徑方案。（數據庫有自動根據 SQL 語句算出一條自認為最優化的路徑的功能。譬如 DB2 的 ACCESS PATH。ACCESS PATH 會隨著數據量的多少的變化而變化的。一旦系統比較龐大，在日積月累中，數據量會越來越大的。所以要準備一定數量的數據，讓 ACCESS PATH 保持相對穩定。

1.3 沒有鋪底數據有可能造成系統發生數據庫的死鎖

如果數據量少，數據庫為了優化有的時候就不用 INDEX 掃描，而采用全表掃描，這樣造成整表被鎖，導致死鎖，而數據量大了以后數據庫會進行 INDEX 掃描，所以不會瑣住整個表。所以在有些情況下在系統上線時準備一些無用的數據放在表中，讓數據庫不會導致全表掃描！雖然有的時候可以通過改變鎖的策略去解決這個問題，但是如果存在風險，在上線系統中就要避免。

1.4 鋪底數據使得系統性能更加真實 , 更符合生產環境的真實情況

在數據庫里面存入鋪底數據，系統從一開始上線的時候，就已有了一個比較穩定的環境。如果沒有鋪底數據，那系統的環境可能隨時面臨著不穩定的因素：如性能陡變，數據庫異常 ( 資源池不夠用，數據庫死鎖，數據庫全表掃描等等 )，響應時間突然下降。所以準備鋪底數據，不但對性能測試意味深遠，而且對即將上線的生產環境也是至關重要的。試想在銀行系統中，如果不準備鋪底數據，一旦系統上線的時候發生了問題，那么銀行會損失多少客戶！

1.5 準備鋪底數據要則

準備鋪底數據主要有以下幾點原則：

• 準備的數據量大?。簲祿熘械臄祿恐灰葍却娲笊先舾杀?，結果就差不多了。
• 數據在準備的時候，要保持原表的約束關系。
• 每張表的數據量要符合真實情況（對此點要求可能比較高 , 通常的做法是估算一下實際的情況）。

介紹了這些的原則，如何在實際操作中創建鋪底數據呢？后面的第 2 章將結合上述的三條原則，具體講述如何高性能地準備鋪地數據。

回頁首

2. 高性能準備鋪底數據

以上介紹了鋪底數據的重要性。要知道準備的鋪底數據每張表要上億條，那么我們如何快速而真實的準備鋪底數據呢？這章將詳細展開講解。

2.1. 如果用簡單的 JDBC 程序插入鋪底數據 , 性能很差

用 JDBC 寫一個程序往數據庫里面插入數據的話，速度會很慢，大概是十萬條一張表需要 20 分鐘。那假設我們需要準備 1 億條數據一張表就是 10000/10*20/60=333 小時，如果業務邏輯需要準備 20 張表，那我們準備這些數據將需要 333*20=6660 小時 =277.5 天！這樣的速度慢得驚人，所以通過 JDBC 準備鋪底數據將不成立。

2.2. 高效率生成鋪底數據

顯然，我們需要能更高效產生鋪底數據的方法。筆者所在團隊選擇了如下的方法：找出數據庫之間的表結構關系，并據此把數據翻倍利用 CPU 的運算能力高效率生成的數據導入到數據庫中，從而在數據庫中產生出所需的鋪底數據。通過這種方式即避免了采用編寫 JDBC 程序的方式，又能高效地生成鋪底數據。

2.2.1. 找到數據庫之間的表結構關系

要準備鋪底數據首先要找表與表之間的關系，也就是要清楚在數據庫里面的表之間的主表附表關系：一對多，多對多的關系。還有要知道實際情況中，一張主表的一條記錄大概對應附表的幾條數據。只需要一個大概的規律就可以了，或者取一個中間值的比例。我們可以通過 Rational Data Architect 生成的表結構圖找到表與表之間的關系：

如下圖所示：

圖 1. 找到表與表之間的關系

從上圖（注：上圖可以在需求文檔中得到）可以看出里面的 7 張表 A_S_HIS，A_ST，A_I，A，A_T，A_S，A_S_T 中，我們先要導入的三張表：A_ST，A_T， A_S_T，其次要導的表是 A，最后要導入的三張表是 A_S_HIS，A_I， A_S。順便說一下，我們還要保證后導入的表的引自先前導入表的主鍵須和主表的引它作為外健的條目有對應關系，最好是保持一致。

2.2.2. 準備原始的第一套數據 ( 每張表大概 1000 條數據 ).

首先利用 Rational Performance Tester 7.0 錄制一個腳本。腳本里面要包括要測試的主要用例。譬如：筆者所做的腳本一共包括十個請求，要全部按照順序錄入到 RPT 中。

然后，重新建立數據庫，使數據庫里面不存在數據。

接下來，就可以利用上文錄制好的 Rational Performance Tester 腳本循環 1000 次。這樣我們的數據庫里面的一些表里就會有 1000 條數據了。然后我們從數據庫里面查看哪些表中的數據增加了，然后把這些表里面的數據導出到文本文件里。

如圖所示：

圖 2. 把這些表里面的數據導出到文本文件里

注意：對于每張變化的表，我們都要導出它所對應的文本文件。例如：表 casee 對應的文本文件是 casee.sql。

2.2.3. 程序擴大數據至每張表千萬條 .

編寫程序把每張表對應的文本文件 ( 例如：casee.sql) 的數據成比例擴大 10000 倍，要注意處理表里面的主鍵的唯一性還有依賴性，保證表和表的一對一關系和一對多關系。首先我們利用 DB2 找到個表的依賴關系：

圖 3. 利用 DB2 找到個表的依賴關系

從上圖中我們可以看到表 CASEE 和很多表都有關系，也就是說它的一些字段在圖里面的很多表里面或者做主鍵，或者做外鍵。如果 CASEE 里面的字段是圖中所示表里面字段的外鍵，那就需要一一對應了。在程序設計的時候就要保證這兩張表的字段和字段里面的值保持一致。

接下來就是寫一個程序去把每張表的數據翻倍，筆者在此提供一套思路供大家參考：

• 我們找到需要表的主鍵字段以后，讓這個字段的數據不要重復，通常都是用數字表示的。建議從 10000000 開始增加，這樣可以避免鋪底數據和我們的實際數據主鍵重復。
• 生成數據的時候要用 BufferedReader，BufferedWriter 去讀寫文件。
• 生成的數據一定要保持主鍵唯一，還要滿足字段的各種約束，否則會導致數據導入后無法 active。

2.2.4. 把數據導入到數據庫中

將數據 IMPORT 到 DB2 里面，注意不要用 load，因為 load 需要數據之間有約束關系，這樣效率會低很多倍。而 IMPORT 不需要依賴關系，因為數據在數據庫里面還沒有被 ACTIVE。

如下所示：

圖 4. 把數據導入到數據庫中

2.2.5. 將數據庫的表置成 ACTIVITY

建好的數據庫，需要把表 ACTIVITY，并且 REORG 一次數據庫里面的數據。這樣使得數據庫的查詢路徑可以優化。

如下所示：

圖 5. 將數據庫的表置成 ACTIVITY

2.2.6. 重建表的索引

為數據庫里面的表建立一些適當的索引，并且要調整一些數據庫的參數，如緩沖池，連接池等。

到此為止，鋪底數據就準備好了。

回頁首

3. 結合鋪底數據基于 WPS Cluster 服務器的性能測試試驗

3.1 性能測試環境準備

在本文中，準備采用這樣的測試環境：IBM WebSphere Process Sever 集群做應用服務器，IBM DB2 做數據庫，Rational Performance Tester 7.0 做性能測試工具，IBM HTTP Server 做 HTTP Server。

3.1.1 什么是 WPS Cluste 及其作用 , 以及 WPS Cluster 的搭建

• Cluster 集群 ：

一組相互獨立的服務器在網絡中表現為單一的系統，并以單一系統的模式加以管理。此單一系統為客戶工作站提供高可靠性的服務。大多數模式下，集群中所有的計算機擁有一個共同的名稱，集群內任意系統上運行的服務可被所有的網絡客戶所使用。Cluster 必須可以協調管理各分離的組件的錯誤和失敗，并可透明地向 Cluster 中加入組件。一個 Cluster 包含多臺（至少二臺）擁有共享數據存儲空間的服務器。任何一臺服務器運行一個應用時，應用數據被存儲在共享的數據空間內。每臺服務器的操作系統和應用程序文件存儲在其各自的本地儲存空間上。Cluster 內各節點服務器通過內部局域網相互通訊。當一臺節點服務器發生故障時，這臺服務器上所運行的應用程序將在另一節點服務器上被自動接管。當一個應用服務發生故障時，應用服務將被重新啟動或被另一臺服務器接管。當以上的任一故障發生時，客戶都將能很快連接到新的應用服務上。

WPS 的集群就是基于 WPS 服務器建立的集群。

• Clus ter 集群的作用：

利用集群我們可以增大 JVM 緊張的問題，可以分攤 I/O 的負載量，還可以把系統的故障率成萬倍的降低。假如一臺 Server 的穩定性是 0.99，那么系統 DOWN 掉的幾率就是 0.01，那么如果我們兩個 Server 在一起的集群環境的不穩定性將降低到 0.00001，也就是有兩個 Server 的集群環境的穩定性提高到 0.9999。這樣我們就可以根據實際生產環境的要求來降低系統的風險性。

• WPS Cluster 集群的 搭建：

本測試環境中我們就采用了 WPS 集群（WPS Cluster）。Cluster（集群）是多個 WPS 的集群，它可以集中管理所有 WPS，并參與管理所有 WPS 的負載。WPS 6.0.1 及以上版本支持搭建 Cluster。這樣可以做到負載均衡（Workload Balance）和高可用性（High Availability），從而使得 WPS 更加穩定，性能更為優秀。況且在一般的真實生產環境中，WPS 集群也是經常要使用到的。

以下是本測試環境中 WPS Cluster 的拓撲圖：

圖 6. WPS Cluster 的拓撲圖

Cluster 分為兩種，水平 Cluster 和豎直 Cluster。水平 Cluster 的成員在不同物理機器上，豎直 Cluster 的成員在同一臺物理機器上。在這里由于測試環境的限制，我們采用的是豎直 Cluster，有三個 Cluster 成員。Cluster 中有一個 Deployment Manager 類型 profile，它可以管理整個單元內部所有的 WPS。Deployment Manager 通過和 Node Agent 交互信息來管理節點。而 Node Agent 用來管理三個 Cluster 成員。我們還需要在 WPS Cluster 和應用中間加入一個 HTTP Server，使得應用通過 HTTP 協議訪問 WPS Cluster 的時候隨機的分攤到不同的 Cluster 上面。

3.1.2 性能測試環境的準備

在理想的情況下，性能測試的環境最好能夠完全模擬真實應用部署的環境，以便于通過性能測試得到應用在真實生產環境下的性能結果。然而由于真實應用部署環境的規模比較大，這是不實際的。因此，為了能夠得到更具真實性的性能結果以及更好地發現應用存在的性能問題，我們在測試中采用可控制的測試環境來盡量模擬真實環境，其中也包括對歷史數據的準備。在我們的測試環境中，為了更好地分析數據庫和應用本身的性能問題，如 I/O 問題，將 WPS 和數據庫將分別安裝在不同的物理機上。

如下是性能測試環境的拓撲圖：

圖 7. 性能測試環境的拓撲圖

首先通過 HTTP 請求到 HTTP Server ，再進入 UI 層，然后通過 UI 調用 Web Service，Web Servive 再通過 HTTP Server 調用一些 BPEL 和 WSDL 文件，再通過 JDBC 連接 Database，并用 Content Manager 存入一些文件（如 PDF，Word）到 Database 上。

利用 IBM HTTP Server 做 HTTP Server，WebSphere Application Server 上搭建 UI 層，將 BPEL WSDL 搭建到 WebSphere Process Server 上，并用 DB2 做 Database?，F在整個測試環境就基本搭建完成。

3.2 在 Rational Performance Tester 中生成測試腳本

3.2.1 Rational performance tester 介紹

在本文中用來進行性能測試的工具采用的是 IBM 的 Rational Performance Tester。它是用于生成用戶負載的商業化的 IBM 產品。它作為 IBM 軟件開發平臺（software development platform，SDP 的一個插件，并且目前只支持在 Microsoft® Windows® 操作系統和 Linux 上使用。Rational Performance Tester 包括一個 IBM Rational ClearCase LT 的完整功能的副本，再加上以下這些關鍵特性：

• 用于創建、修改，并執行工作負載的可視化測試編輯器。
• 能夠同時運行多個，以及各種各樣的用戶模擬。
• 跨節點分配測試作業的可部署的執行代理。
• 立即的性能及吞吐量報告。
• 動態服務器響應的自動識別，及對其的支持。
• 使用數據池隨機的輸入。
• 服務器資源數據的集合及可視化。
• 生成在測試記錄過程中被訪問的 Web 頁面的 HTML 視圖。
• 為了靈活定制測試，可以插入 Java 代碼。

用 Rational performance tester 創建一個申請案例的頁面測試，并命名 Project Name 為 MAR。

圖 8. 創建一個頁面測試

通過訪問 Manage Application Request 的 Web 頁面，執行一個完整的申請流程，來完成 Rational performance tester 的測試腳本的錄制。在 Test 的內容框可以看到，錄制的測試腳本共包含 11 個頁面。

圖 9. 錄制的測試腳本共包含 11 個頁面

3.2.2 創建性能調度

性能調度使得你可以對測試分組，排序，以及在遠端運行測試。時間計劃可以簡單到每一個虛擬用戶運行一個測試，也可以復雜至在不同的組中有上百個虛擬用戶，每一個都在不同的時間運行不同的測試。利用性能調度，你可以：

• 對測試分組來仿真不同用戶操作。
• 設置測試運行次序：順序地，隨機地，或按照所帶權值的次序。
• 設置每個測試運行次數。
• 依照一定的速率運行測試。
• 在遠端運行一個或多個測試。

這里創建一個名為 schedule 性能調度，由于這次測試都是在本機執行，并且都執行同一個測試腳本，所以創建一個 User Group，其中包含并發用戶 5 個。為保證用戶的真正并發性，注意要將每個 user 之間的 delay time 設置為 0 Sec，think time 也設置為 0 Sec。測試執行次數設為 10 次。

圖 10. 創建一個名為 schedule 性能調度

性能調度設置完成后，執行性能調度。

圖 11. 執行性能調度

首次執行的測試是在數據庫為空的情況下進行的，然后按照本文第二部分介紹的方法，向數據庫中插入鋪底數據。插入鋪底數據后，同樣的方法，再次執行一遍 schedule 性能調度，與之前執行的結果進行比較。

3.3 分析測試結果

通過分別對沒有鋪底數據和有鋪底數據的情況進行相同的性能測試，會發現測試結果有很大的區別，主要表現在頁面平均響應時間。經過測試，在沒有鋪底數據的情況下，平均頁面響應時間是 58.552 ms，而在有鋪底數據的情況下，平均頁面響應時間是 608.344 ms，具體從 Rational Performance Tester 生成的測試報告中可以清楚地看到每個頁面的平均響應時間。

3.3.1 沒有鋪底數據的測試結果

圖 12. 沒有鋪底數據的測試結果

3.3.2 有鋪底數據的測試結果

圖 13. 有鋪底數據的測試結果

3.3.3 分析比較測試結果不同的原因

從上面兩個頁面平均響應時間圖的對比，可以看出在有鋪底數據的情況下，平均響應時間均高于沒有鋪底數據的測試結果，其中 start 和 Manage Application Request (7) 這兩個頁面的響應時間差距比較大，并且普遍高于其他頁面。經過查找問題根源，發現這是由于在這兩個頁面中，在數據庫中進行了大量視圖創建和 select 語句的操作，從而導致響應時間比較長。

因此從上述比較可以看出，在有鋪底數據的情況下進行性能測試，能夠幫助測試人員更好地發現被測應用系統存在的問題。另外，一般應用在真正生產系統中運行時，都會存在大量的歷史數據。這樣我們在測試時就加入鋪底數據，不僅能夠得到更加真實的測試結果，并且能夠及早發現應用系統中存在的隱患，不會在系統正式運行后才發現問題，那時已經為時已晚。

回頁首

4. 總結

在本文中，介紹了什么是鋪底數據、準備鋪底數據的重要性，以及如何運用 Ratioanl Performance Tester 7.0 和 DB2 的導入功能高效生成鋪底數據的方法。并且提供了一個實際性能測試樣例，對一個基于 WebSphere Process Sever 的應用程序的性能測試進行了詳細描述，并且，對有鋪底數據和沒有鋪底數據的兩種情況的測試結果進行了分析，發現使用鋪底數據進行性能測試，不僅可以幫助測試人員更好地發現應用系統存在的問題，同時也能夠使測試結果更加接近真實生產環境下的結果。

原文轉自：http://www.anti-gravitydesign.com