SRM基準測試中工作負載定制與性能評估

摘 要：為解決多租用者應用程序所面臨的經營規模和運行特性等最佳配置策略問題，創建了名為S-BM基準的模擬供應商關系管理應用程序。S-BM基準作為代表基準測量的一種方式，可以用來評估多租用者應用程序和資源利用配置問題。通過兩組設備對定制的負載生成器進行評測，包括在12個從小到大商業規模的代表負載中測量系統應用程序性能，以及在多樣基礎設施配置基礎上對比其性能和不同負載成本等。實驗研究負載與性能之間的關系，幫助找到用于多租用者應用程序的最優配置策略，結果表明，通過在共享環境下重新配置大和小交易應用程序，負載性能在同樣資源成本情況下增長了30%。

關鍵詞：SRM;SaaS;負載

DOI：10. 11907/rjdk. 191496

中圖分類號：TP393

文獻標識碼：A文章編號：1672-7800（2019）006-0188-04

Abstract：To address the optimal configuration policy issues faced by multi-tenant applications， such as scale of operations and operational characteristics， we created a simulated vendor relationship management application called the S-BM benchmark which serves as a way of representing benchmark measurements that can be used to evaluate multi-tenant applications and resource utilization configuration issues. We measured the custom load generator across two sets of devices， including measuring the application performance of the system in 12 small to large commercial scale representative loads and comparing its performance against the cost of different loads based on a variety of infrastructure configurations. The results of these experiments which examined the relationship between load and performance helped us find the optimal configuration strategy for multi-tenant applications. In the end， we found that by reconfiguring large and small transactions applications in a shared environment， the performance of the load was increased by 30 percent at the same resource cost.

Key Words：SRM;SaaS;workload

0 引言

SaaS（軟件即服務）作為一種軟件服務交付方式，已經得到中小企業廣泛認同。SaaS模式可幫助廠商增強差異化競爭優勢，降低開發成本和維護成本，加快產品或服務進入市場的節奏，有效降低營銷成本，改變自身收入模式，改善與客戶之間關系[1]。作為SaaS模式提供的供應商關系管理（Supplier Relationship Management，SRM）應用具有多租戶特征[2]。SRM最顯著的特征是多個企業租戶之間可以共享一個應用實例、基礎設施及其軟硬件資源，達到多種資源復用目的。同時，針對企業用戶數量以及業務數據規模各不相同的情況，每個租戶作為一個單獨對象，擁有不同業務規模。在租用服務過程中，服務供應商給每個租戶配置的系統資源也不一樣[3]。目前國內外研究中，保證租用者滿意度和供應者可負擔成本是發展SaaS一個不可避免的問題，同時也是研究者孜孜不倦尋找解決方案的問題。目前面臨的瓶頸是，從供應者角度出發，他們必須能發現過度預分配的和未充分使用的資源，這個問題包括在可擴展性、未被使用資源和演化代價之間的權衡。因此，多租用者應用程序的最優配置成為完善服務性能資源利用率的關鍵。

通常情況下，研究者一般用benchmark基準評估與對比應用程序和系統性能。該類評估的準確翻譯需要有綜合負載基本知識，基準用于判定它怎么表現多樣電子商務應用程序在現實生活中的負載[4]。

在眾多可行的評測電商服務器性能基準中，有些采用之前的應用程序如TPC-W事務Web基準，模仿自易趣網的RUBiS拍賣基準和RUBBoS布告欄基準，以評測與對比電腦系統性能[5-7]。但是，傳統基準并不能全部適用于具有不同特點的應用程序。與此同時，國內外很多普通用途的負載生成工具已被研發出來，例如UC伯克利為云計算應用程序研發了一種負載生成工作包——Rain，允許描述在3種主要符合規格下的概率分布使用，架構支持多種負載生產策略（開環、閉環、半開環），具有將新系統或新應用程序作為目標客戶定制需求生成器的易用性和可拓展性[8]。Diwakar等[9]提出一種基于互助請求會話特征的合作生成工作負載理論，特點是可以自主生成具有某種特性的負載，并且能夠維持正確的相互請求依賴關系[10]。為了動態地改變一個處理器的架構，使其更好地適應負載特征，Hashem等[11]提出一種建筑爭奪方式，即在一種領導者追隨者配置中基于很多不同建筑處理器的代碼冗余執行（針對不同負載特點的單獨定制）。不可否認的是，互聯網負載生成遠比它看起來復雜，一個關于RUBiS客戶生成器的實驗證明，由JVM和Java網絡庫使用生成器報告的響應時間可能很不準確[12]。由于模擬此類程序所面臨的技術挑戰，推崇一種能夠實現客戶服務質量滿意度與供應者系統資源利用率水平之間的平衡測量方式[13]。該測量基于一種用于模擬n層SaaS應用程序的具體基準。本文運用一種針對SRM的基準，稱為S-BM（基于供應商管理系統的Benchmark）。SRM應用程序被廣泛用于制造商供應連鎖管理，有助于供應商選擇和增加制造商的競爭優勢，例如其已被奧鈴、雷沃等多個汽車生產商使用。所以，S-BM是專為SRM型應用軟件設計的，同時能很好地反映多租用者SaaS應用程序的特點[14]。

本文主要貢獻在于為特定租用者以一種可配置方式提供負載私人定制。整個設計和開發過程遵照現代軟件工程過程及面向對象設計的要求[15-16]。自動化負載生成器能從描述設置的配置文件創建自定義工作負載工作流。實驗測評基于數據生成負載在400 000～4 250 000行數據兩組數據庫中得出。

1 S-BM基準測試系統

同所有電商基準一樣，S-BM基準測試系統包括測試系統（SUT）、數據生成器、模擬器生成器、監視器和分析器等客戶服務器架構。每一個SUT里至少包括一個Web應用服務器（WAS）和一個數據庫服務器（DS），用來與客戶進行溝通和處理通過專用網傳來的客戶請求。根據具體的SLA（Service-Level Agreement）要求和商業規模，一個或多個租用者應用程序可以被配置到SUT里。

數據生成器被用來生成一個租用者的工作負載數據，其中包括基本數據和基于特定租用者商業特征的數據。

為了刺激現實中供應商將執行的工作量，模擬器生成器被用來生成模擬瀏覽器，比如給SUT發送HTTP請求。所以，模擬瀏覽器對負載生成起直接作用。

在S-BM中，效仿顧客行為用HTTP會話連接SUT。每個會話包括18個基于SRM應用程序的網絡交互：登陸、指令處理、計劃詢問、存貨詢問、計算詢問和賬單詢問等。將該18個網絡會話交互分為只讀類型和可讀寫類型，而后者更占資源。

S-BM衡量兩個主要測度：第一個主要是關于網頁交互響應時間的服務性能測度;第二個是資源利用，其中包括CPU利用率、儲存卡利用率、輸入輸出操作和網絡利用率。

2 S-BM工作量定制

具有普遍適用性的基準需要產生至少一種類型應用程序工作量。S-BM是在基于分析和評測租用者特點的SRM應用中交易的電子商務工作量。

2.1 工作量數據模型

S-BM工作量數據是租用者特有的。它由兩方面組成：針對特定租用者的基礎數據和商業數據。兩者都在不同方面影響工作量，基礎數據范圍在一定程度上反映了一個特定租用者的生產能力，而商務數據則反映了生產者的訂單頻率。

2.1.1 特定租用者基礎數據

在S-BM中有3個因素影響每個租用者舉出數據的范圍，這些因素的關系如圖1所示[17]。一個制造商可能生產很多不同產品;每個產品由不同類型部件組成;每一個部件又由不同供應商提供;同時，一個部件供給比例的總和為1。

2.1.2 商業數據

在數據產生過程中，提供兩種參數按比例放大商業數據：一個是FOO（訂單頻率），另一個是日增長率。這兩個參數反映了訂單密度和供應商繁忙度。

除了工作量數據外，仿真瀏覽器用于給SUT發送HTTP請求，所以其數量是影響工作量的又一重要因素。在S-BM中，可以通過設定不同轉移概率矩陣給用戶安裝交互文件。轉移矩陣反映了在SRM應用程序中實際交互的轉移概率特征，可以通過分析該應用程序在實際操作中的日志獲得。

2.2 工作量定制

在S-BM中，可以用一種可配置方式為特定租用者定制工作量。配置包含基礎數據、商業數據、仿真瀏覽器文件和包含租用者SLA定制信息的xml格式文件。

（1）NUM_PRODUCTS，MAX_SUP_QUA_PER_PART， AVE_SUP_QUA_PER_PART和AVE_PART_QUA_PER_SUP是用來定義基礎數據的。因為生產商經常從外包零件起家，所以可以利用這些參數計算作為基礎數據指標的部件和供應商數量。

（2）FOO的參數和增長率被用來定義商業數據范圍。FOO由租用者繁忙度決定。很顯然，越多訂單就意味著越繁重的工作量，增長率主要與每日訂單增長率有關。

（3）NUM_EB、EB_ROLE 和USER_MODE 被用來定義仿真瀏覽器文件。NUM_EB、EB_ROLE用于描述有多少不同作用的仿真瀏覽器在單次測試中形成客戶瀏覽工作量。不同模式有不同讀寫運算比率，USER_MODE則用于定義瀏覽器模式。

最后，由于不同租用者可能有不同商業規模和需要不同水平的系統性能，根據租用者的SLA需求生產工作量，同時用MAX_WIRT 和 AVE_WIRT 兩個參數給予支持。

2.3 工作量生成

在定制完工作量之后，可以用包含定制信息的xml文件生成工作量數據。工作量生成器首先需要從文件中提取一些信息，如產品數量和限制參數，然后生成記錄詳細基礎信息的表格文件。在此基礎上，再生成已經插入到數據庫服務器中的商業數據。另外，還要保證這些數據都能用到SRM應用程序里。

仿真生成器用來生成能刺激實體客戶行為的仿真瀏覽器。它被用作多線程程序，而每個線程代表一個瀏覽器。因此，為了形成工作量，也被用于刺激客戶瀏覽正在進行試驗的系統。

3 性能測評

為了得到支持優化部署策略的有用結論，通過評估定制的工作負載生成工具和S-BM綜合性能，設計了兩組實驗。第一個是根據不同規模驗證性能變化，第二個是驗證度量標準的敏感性。

3.1 不同工作負載下的性能分析

為搜索關于不同工作負載組合下性能的詳細信息，根據基本數據（5個產品、10個產品、15個產品、20個產品）和商業數據期限（10天、20天、30天）的不同組合，將其分成12個小組。這些小組實驗涵蓋4種類型工作量規模，分別是低訂單率的小型企業（5個產品和10天）、高訂單率的小型企業（5個產品和30天）、低訂單率的大型企業（20個產品和10天）以及高訂單率的大型企業（20個產品和30天）。

在不同類型組合下，數據規模也不盡相同。事實上，最小數據規模可達400 000行，最大則是4 250 000行。基于一組固定的基礎數據和商業數據，逐步增加EB（仿真瀏覽器）的數量，直到它達到供應商最大數量或者報錯“閱讀超時”，將此錯誤視為系統在該配置下達到瓶頸的標志。

實驗結果如圖2所示。由于空間限制，只用CPU利用率舉例說明。

圖2中，上左、上右、下左、下右分別有5、10、15、20個產品的基礎數據。從實驗中得出以下結論：

（1）CPU資源利用率隨著經營指數的增長而增長，而應用系統能容納的仿真瀏覽器數量則越來越少。

（2）當系統達到瓶頸時會出現一個明顯的指標響應時間轉折點，該點在不同基礎數據規模下不同。

（3）在多數情況下，數據庫服務器性能限制了仿真瀏覽器的最多數量。

3.2 指數靈敏性分析

為評估系統性能在WIRT上基礎數據和商業數據的靈敏性，做了兩組實驗。第一組分析業務數據，第二組分析基礎數據。在實驗中固定一個因素，然后觀察另一個因素的變化。實驗結果如圖3、圖4所示。

從圖3、圖4中可以看出，業務數據變化導致CPU利用率、內存利用率和TPS變化較大。相反，改變基本數據導致資源利用率變化較小。雖然增加FOO和供應商數量時，平均響應時間都會增加，但是圖4中的值遠遠高于圖3。因此，業務數據對系統性能影響較大，基礎數據對響應時間影響較大。

圖3 峰值數據影響

[Average Response Time（ms）]

圖4 基礎數據影響

4 結語

本文展示了基于SRM應用基準的私人定制方式——一種自動化負載生成器用于從配置文件中制作私人定制的負載。通過兩組實驗對私人定制負載生成器進行評測，實驗結果能夠幫助找到用于多租用者應用程序的最優配置策略。在相同資源成本下，通過在共享環境中重新部署小型和大型業務的應用程序，工作負載能力可以提高30%。S-BM是基于私人SRM系統開發的，所以目前不具有普遍性，下一步需通過不斷優化，使之具有更好的通用性。

參考文獻：

[1] 楊建新. SAAS現狀分析與前景展望[J]. 軟件導刊，2012，11（1）：1-2.

[2] 郝曉寧. 面向客戶定制多租戶SaaS應用的Benchmark系統的設計與實現[D]. 濟南：山東大學，2014.

[3] 許世網. SAAS的優缺點辨析[EB/OL]. http：//www.ccw.com.cn/cio/research/info/htm2007/20070314_245311.asp.

[4] GARCíA D F，GARCíA J. TPC-W E-commerce benchmark evaluation[C]. Computer， 2003： 36-42.

[5] RUBIS.Rice university bidding system[EB/OL]. http：//rubis.ow2.org/.

[6] RUBBOS.Bulletin boardbenchmark[EB/OL]. ?http：//jmob.objectweb.org/rubbos.html.

[7] CECCHET E，MARGUERITE J，ZWAENEPOEL W. Performance and scalability of EJB applications[J]. SIGPLAN，2002，37： 246-261.

[8] BEITCH A， LIU B， YUNG T， et al. Rain： a workload generation toolkit for cloud computing applications[C]. California：Technical Report UCB/EECS-2010-14， 2010.

[9] DIWAKAR K. A synthetic workload generation technique for stress testing session-based systems[J]. IEEE Transactions on Software Engineering，2006，32（11）：868-882.

[10] HASHEM H N，ERIC R. Architectural contesting： exposing and exploiting temperamental behavior[J]. ?SIGARCH Computer Architecture News，2007，35（3）： 28-35 .

[11] DIWAKAR K. A Synthetic workload generation technique for stress testing session-based systems[J]. IEEE Transactions on Software Engineering，2006，32（11）：868-882.

[12] RAOUFEHSADAT H， DIWAKAR K， MARTIN F. Arlitt： web workload generation challenges-an empirical investigation[J]. Software-Practice and Experience，2012，42（5）： 629-647.

[13] GUEYOUNG J， KAUSTUBH J， MATTI H， et al. A cost-sensitive adaptation engine for server consolidation of multi-tier applications[C]. Illinois：ACM/IFIP/USENIX 10th International Middleware Conference （Middleware 2009）， 2009.

[14] WIKIPEDIA. Supplier relationship management[EB/OL]. http：//en.wikipedia.org/wiki/Supplier_relationship_management.

[15] SHARI L P. 軟件工程理論與實踐（第2版） [M]. 吳丹，譯. 北京：清華大學出版社，2003.

[16] STEPHEN R. Scnach面向對象與傳統軟件工程[M]. 北京：機械工業出版社，2003.

[17] ZEYU D. S-BM： a benchmark suite for multi-tenant supplier relationship management service[C]. Service Systems and Service Management （ICSSSM）， 2013：4-5.

（責任編輯：何 麗）