劉 維,何冬輝,楊攀飛
(1.工業和信息化部電子第五研究所,廣州 511300;2.基礎軟硬件性能與可靠性測評工業和信息化部重點實驗室,廣州 511300)
中間件是連接軟件組件或企業應用程序的軟件[1],其主要作用是屏蔽底層系統和通信的異構性,進而支撐應用實現穩定、可靠和高并發運行,并簡化應用的開發流程[2]。它開始于操作系統之上的一些附加功能,以促進復雜應用程序的開發,然后發展了數據集成功能,后來成為網絡應用程序的促進者,最終成為每個分布式環境、應用程序、系統和平臺的重要組成部分。到目前為止,任何類型的分布式系統或應用程序都能找到中間件或一些涉及的中間件功能。通常,它支持復雜的分布式業務軟件應用程序[1]。
作為三大基礎軟件之一,中間件是信息系統建設項目不可缺少的核心組件,與操作系統、數據庫具備同樣的戰略高度。中間件實現的范圍是多種多樣的,從面向通信的中間件到面向組件的應用服務器[3]。目前國際通用的中間件技術標準主要有由SUN 公司提出的Java EE、微軟的COM+/.NET 框架以及公共對象請求代理體系結構(common object request broker architec?ture,CORBA)/CORBA 組件模型(CCM)[4]。在政策的指引下,國內涌現出了一批國產化中間件產品,并廣泛應用在各個行業與領域,現階段的國產中間件的核心訴求主要集中在應用中間件。
目前在中國市場,主要的中間件廠商(組織)有8 家,其中3 家來自美國,5 家為國內廠商,國內廠商因受到政策驅動,市場保持穩定發展態勢[5]。在8 家中間件廠商的主打中間件產品中,7 家為商業產品,1 家為開源產品,8 家廠商均通過了Jakarta EE 8規范兼容測試認證。
獲得系統性能特征的常用方法是通過基準測試[3],為保證國產Web 應用中間件滿足其服務質量(QoS)要求,須使用基準測試來測量和驗證它們的性能。面對國產中間件無測評體系、無配套測評工具的現狀,通過對中間件測評技術的研究,本文設計了一種Web 應用中間件性能測試系統,使用汽車保險經紀基準模型對Web 應用中間件進行性能評估,對通過了Java EE 8、Java EE 7、Java EE 6 國際標準兼容認證的某國產品牌Web應用服務器軟件進行評測。
汽車保險經紀基準模型旨在測量與Java EE 7.0 Web Profile 或更高版本規范兼容的應用服務器的性能。它為Web 應用程序的用戶提供了一個標準,用于比較從Java EE Web Profile 應用服務器、Java 運行時環境、網絡和操作系統到數據庫服務器和存儲的所有級別的應用程序棧(application stack)的軟件和硬件性能[6]。它由一個保險應用程序組成,包含三種不同的服務:車輛服務、保險供應商服務和保險服務,該應用程序使用JSF 和REST 函數來驅動應用服務器上的負載。
整個測試系統可大致分為Driver,Applica?tion Server,Database Server三個部分[7],結構如圖1所示。

圖1 Web應用中間件性能測試系統結構圖
Driver 的壓力部分:首先Driver 引用Faban測試工具進行部署和測試,其工作原理是由主節點創立多個從節點,之后用大量從節點來進行壓力負載的測試。基準測試系統使用Faban來安排和自動化基準測試運行。Faban 還提供了一個嵌入式圖形工具,可以繪制和比較運行結果。該工具作為托管在Tomcat 服務器上的Web 應用程序運行,它提供Web 用戶界面,并充當汽車保險經紀基準測試的驅動程序組件的容器。線束提供的Web 用戶界面用于調度運行,管理運行,查看運行日志以及運行完成后查看結果(包括詳細圖表)[7]。
Application Server 部分:其主要運行著車輛保險模型,該模型由三部分服務組成,分別是:車輛服務、保險供應商服務和保險服務。該模型支持集群化部署。
Database Server 部分:提供數據服務,并且能夠及時響應,支持集群化部署。
通過gradle 腳本程序獲取到預先寫好的Ap?plication 的接口測試模型數據,之后通過創建主從線程來預熱測試程序,預熱之后按照接口測試模型數據針對性地對承載應用服務器Applica?tion Server的中間件進行測試。
Web 應用中間件性能測試系統的功能特點見表1。

表1 Web應用中間件性能測試系統的功能特點
測試系統軟、硬件環境如表2所示。汽車保險經紀基準模型測試的吞吐量由保險驅動程序的活動驅動。注入率(injection rate,IR)衡量在基準運行期間將加載多少數據,驅動器的吞吐量與所選的注入率直接相關。為了提高吞吐量,需要增加注入率。較高的注入率等同于更多的客戶端負載,因此相應地創建了更多的數據,本文分別在注入率為500、1000、1500 和2000的條件下進行了測試,設置預熱時長為600 s,測試時長為3600 s,結束時長為300 s。

表2 測試系統運行環境
本系統對Web 應用中間件測試項分為四個部分,分別為組合操作(Operation Mix)、響應時長(Response Times(seconds))、邏輯執行時長(Cycle/Think Times(seconds))及其他項(Miscella?neous Statistics),業務交易類型如表3 所示。由保險驅動程序運行的業務交易是保險服務的一系列操作,業務交易序列由驅動程序根據表4中所示的組合選擇。驅動程序將85%的負載發送到JAX?RS API,并將15%的負載發送到JSF生成的HTML 頁面。表4 中的每個序列都具有REST 和JSF變體。驅動負載的客戶端模擬Web用戶與保險服務的應用程序進行交互,負載按照15%的JSF請求和85%的REST請求的比例進行分配。

表4 業務交易組合要求
2.2.1 組合操作
組合操作測試結果包括業務成功總數、失敗總數、實際組合、目標組合四項,對于每種類型的業務交易操作,基準中實現的實際組合須在目標組合的4%范圍內(±2%),驅動程序檢查并報告是否滿足組合混合要求。圖2 顯示了500、1000、1500 和2000 四種不同注入率(txrate)下業務操作的成功總數,圖3 顯示了實際組合和目標組合之間的偏差在規定的范圍內,所有業務測試項通過。

圖2 不同注入率下業務的成功總數

圖3 不同注入率下業務實際組合和目標組合的偏差
2.2.2 響應時長
驅動程序測量并記錄業務交易序列中每個不同操作的響應時間,僅包括在測量間隔中成功完成業務交易序列的操作。業務交易的每個操作中至少有90%的響應時間(90%th)須小于2 s(即90%目標響應時間為2 s)。每個業務交易操作的平均響應時間不得超過記錄的90%響應時間的0.1 s,此要求可確保所有用戶都能看到合理的響應時間。例如,如果注冊事務的90%響應時間是1 s,那么平均值不能大于1.1 s。驅動程序檢查并報告是否滿足響應時間要求。
該項測試,測試結果包括平均響應時長、最大響應時長、標準差、90%實際響應時間、90%目標響應時間五項,若每項業務平均響應時間和90%實際響應時間符合以上要求,則該測試項通過,反之則未通過。
圖4表明不同注入率,業務交易的每個操作中90%實際響應時間(90%th)均小于90%目標響應時間(2 s),平均響應時間(avg)符合規定,所有測試項通過,通過計算驗證也可證明以上結論。

圖4 業務交易操作的響應時間
2.2.3 邏輯執行時長
該部分測試結果分為目標平均(targeted avg)、實際平均(actual avg)、邏輯執行時長最小值(min)和邏輯執行時長最大值(max)四項,每一個業務交易操作的測試均生成上述四項結果,當實際平均不超過目標平均時,該業務交易操作項測試通過。測試結果表明在各注入率下實際平均執行時長(actual avg)皆不高于目標執行時長(targeted avg),該項測試通過,測試結果如圖5及圖6所示。

圖5 邏輯執行時長的目標平均和實際平均

圖6 邏輯執行時長的目標平均及實際平均之差
2.2.4 其他項
該部分測試項設測量基準設置,包括使用安全連接、有效的運行屬性設置;初步審計項,該項是注入數據的初步數據量審計,包括車輛描述、車輛、車輛保險、投保人、保險政策;原子性測試,測試內容包括原子性測試一及原子性測試二;持久性和正確性測試,包括JPA緩存透寫測試、幻讀刪除測試;最終審計項測試,它對程序測試之后的數據審計;業務審計項測試。具體描述見表5。

表5 其他項測試

續表5
在基準測試期間,業務交易序列的每個操作有99%或以上須在穩定狀態下取得成功,這允許最多1%的操作類型失敗。此外,數據庫表中的行數須不超過預期大小±1%的偏差。驅動程序檢查并報告是否滿足這些要求。測試結果表明,實際結果(results)符合目標結果(targeted results),被測Web 應用中間件使用https 安全連接方式,與目標結果一致,有效的運行屬性設置符合目標結果,原子性測試通過。在誤差允許范圍內,初步審計、最終審計及業務審計成功率被測結果符合目標結果要求。圖7在橫軸上三組不連續線段分別表示初步審計項、最終審計項和業務審計的成功數。

圖7 初步審計、最終審計及業務審計成功數
當前,我國信創產業快速發展,但在中間件測評體系和測評工具方面還沒有成熟的、標準的技術和產品成果,本文設計了一個基于汽車保險經紀基準模型的Web 應用中間件性能測試系統,并在某國產品牌Web 應用中間件上進行了應用驗證,探索了在四組不同注入率下應用服務器的系統性能。實驗結果表明,該測試系統能夠實現對國產Web 應用中間件性能的評估,在一定程度上有效牽引了國產Web 應用中間件產品質量提升。