在大規模 SOA 應用的性能測試中,一個很重要的事就是準備鋪底數據。所謂鋪底數據,即在性能測試之前人工的向數據庫里面存入用來模擬歷史的或無用的大量數據。那么,為什么要準備鋪底數據呢?通常情況下,準備大概每個表 1 G 的數據,數據量大概是每張表大于 5000 萬條數據,如何快捷真實的準備鋪底數據呢?本文還將簡單介紹一下在性能測試的時候為什么需要搭建 WebSphere Process Sever (WPS) Cluster,以及如何搭建 WPS Cluster。最后,通過 Rational Performance Tester (RPT) 7 結合 WPS 集群進行性能測試,并分析比較在 WPS 服務器下的有無鋪底數據支持的性能。
本文假設對某大型 SOA 系統進行的性能測試。其中主要的測試場景是案例的申請,保證所有在線用戶同時在線錄入檔案。測試場景包括了創建成員的信息、收入及支出信息和提交救援案例的申請。共有 10 個 web services。
在這個系統中,性能測試需要模擬很多人同時在線的情景,通過性能測試工具能模擬任意多的人同時在線,而且要保證系統性能穩定,不論任何時候都要保證系統的請求和響應時間基本保持穩定,不會隨著數據庫的數據的增加而變慢;谶@些問題,就需要找到一種有效的方式來對系統進行性能測試。
在上面的場景中,需要一個長時間穩定的環境,那我們就可以增大數據庫里面的數據量,并用一些負載平衡的應用服務器環境。綜上所述,可以在數據庫里面存入鋪底數據,在服務器端搭建集群服務器。
那么如何制作鋪底數據呢?以下的幾段我們將詳細闡述。
鋪底數據就是我們在做性能測試之前,在數據庫里面除數據庫字典表外按照業務邏輯存入的大量的數據。這些數據可以視為垃圾數據,因為它們對系統的業務邏輯沒有實際的影響,但對系統的性能卻有著很大的影響。
- 鋪底數據需要按照實際的情況去生成,要符合實際的生產情況的表的數據比例。譬如:有一張表的數據量和另外一張表的倍數關系是
5:1
,那么準備數據的時候不論準備的數據是多少條,也需要保證這兩個表的數據量的倍數是5:1
。 - 鋪底數據雖然是垃圾數據,但同樣需要遵守數據庫中數據的依賴關系。比如一對一,一對多的關系。
如下是我們在性能測試中準備的數據:
在性能測試之前在 DB2 里面準備的鋪底數據,總量是:10.5 GB。
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 |
或許你會問,為什么要準備這些鋪底數據?這些數據不是我們的實際生產環境的數據,那為什么要花時間去準備如此大量的數據呢?
答案是,系統在有鋪底數據和沒有鋪底數據的情況下,性能會有很大的差異。那為什么會這樣呢?
- 首先,如果沒有那些鋪底數據,那么本來為一張表建立了一個索引,當系統的數據量很小的時候,數據庫就有可能造成全表掃描,而不走索引掃描,這樣就會造成系統的性能降低。
- 如果數據量很小的話,我們不知道進行一次查詢時候的 SQL 語句究竟是哪種執行路徑方案。(數據庫有自動根據 SQL 語句算出一條自認為最優化的路徑的功能。譬如 DB2 的 ACCESS PATH。ACCESS PATH 會隨著數據量的多少的變化而變化的。一旦系統比較龐大,在日積月累中,數據量會越來越大的。所以要準備一定數量的數據,讓 ACCESS PATH 保持相對穩定。
如果數據量少,數據庫為了優化有的時候就不用 INDEX 掃描,而采用全表掃描,這樣造成整表被鎖,導致死鎖,而數據量大了以后數據庫會進行 INDEX 掃描,所以不會瑣住整個表。所以在有些情況下在系統上線時準備一些無用的數據放在表中,讓數據庫不會導致全表掃描!雖然有的時候可以通過改變鎖的策略去解決這個問題,但是如果存在風險,在上線系統中就要避免。
1.4 鋪底數據使得系統性能更加真實 , 更符合生產環境的真實情況
在數據庫里面存入鋪底數據,系統從一開始上線的時候,就已有了一個比較穩定的環境。如果沒有鋪底數據,那系統的環境可能隨時面臨著不穩定的因素:如性能陡變,數據庫異常 ( 資源池不夠用,數據庫死鎖,數據庫全表掃描等等 ),響應時間突然下降。所以準備鋪底數據,不但對性能測試意味深遠,而且對即將上線的生產環境也是至關重要的。試想在銀行系統中,如果不準備鋪底數據,一旦系統上線的時候發生了問題,那么銀行會損失多少客戶!
準備鋪底數據主要有以下幾點原則:
- 準備的數據量大。簲祿䦷熘械臄祿恐灰葍却娲笊先舾杀,結果就差不多了。
- 數據在準備的時候,要保持原表的約束關系。
- 每張表的數據量要符合真實情況(對此點要求可能比較高 , 通常的做法是估算一下實際的情況)。
介紹了這些的原則,如何在實際操作中創建鋪底數據呢?后面的第 2 章將結合上述的三條原則,具體講述如何高性能地準備鋪地數據。
文章來源于領測軟件測試網 http://www.k11sc111.com/