（江蘇省軟件產(chǎn)品檢測中心，江蘇 南京 210012）

0 引言

網(wǎng)絡服務已經(jīng)是信息化技術(shù)下必不可少的重要方式，其性能的好壞將影響著其承載工作的服務效果。作為網(wǎng)絡服務的重要構(gòu)成部分，借助承載服務設備Web Server的關(guān)鍵性勢必不言而喻。為確保其可以穩(wěn)定高效的帶來網(wǎng)絡服務，運維項目師對其性能展現(xiàn)與優(yōu)化方法非常重視。針對某個Web Server展開評價，能夠從兩個層面來看：其一，面向客戶，客戶體驗要好；其二，面向本身，對系統(tǒng)所依靠的硬件設備需物盡其用，充分使用。而以往的Web性能評估指標僅能體現(xiàn)以上兩個方面的某個部分，不精準的基礎上對兩方面展開整體評估，有一定優(yōu)點也有一些不足。

1 性能測試分析

借鑒格雷格對系統(tǒng)功能的界定，性能檢測是面向被測系統(tǒng)軟硬件結(jié)構(gòu)、網(wǎng)絡條件、業(yè)務邏輯與業(yè)務環(huán)境，對系統(tǒng)的時間屬性與資源性質(zhì)等展開分析檢測，發(fā)現(xiàn)系統(tǒng)性能問題，且確定問題獲得處理的過程。

一個常見的Web系統(tǒng)結(jié)構(gòu)從后至前逐一包含：信息庫服務器、WWW服務器、客戶終端，就客戶角度來講，系統(tǒng)性能即對客戶處理的響應時間。當客戶點擊一個開關(guān)，從客戶點擊該開關(guān)應用系統(tǒng)將此次處理的結(jié)果根據(jù)客戶可以看見的方式呈現(xiàn)出來，該環(huán)節(jié)所需的時間即客戶對系統(tǒng)性能直觀記憶，若這一時間太長或返回結(jié)果不準確就表示該系統(tǒng)有瓶頸。

2 依靠最小業(yè)務單元創(chuàng)建壓力測試環(huán)境辦法的提出

2.1 常規(guī)系統(tǒng)性能瓶頸與定位辦法

借鑒CSDN的《常規(guī)的性能瓶頸與分析過程專題》，根據(jù)個人測試操作實際，歸納了當下典型的性能瓶頸種類與定位辦法。為了方便在實踐過程處理，對某些種類實施了合并。

2.2 依靠最小業(yè)務單元創(chuàng)建測壓環(huán)境的辦法

2.2.1 傳統(tǒng)辦法在確定性能瓶頸方面的限制

監(jiān)測工具與日志分析僅能確定普通的軟件性能瓶頸，找出應用軟件與信息庫編程漏洞就要求錄制壓力檢測環(huán)境，開展測壓工作以確定潛在的性能瓶頸。在以往的性能環(huán)境錄制過程，是盡量的模擬現(xiàn)實的業(yè)務環(huán)境，盡量可以一網(wǎng)打盡發(fā)現(xiàn)全部的性能問題。

另外，還能夠在“動態(tài)頁面、考慮時間、限時放棄瀏覽等客戶特點”方面展開考慮，提高測壓環(huán)境加載狀態(tài)下對業(yè)務仿真的逼真度?；谶@種指導觀念，腳本錄制環(huán)節(jié)也是盡量還原現(xiàn)實的業(yè)務辦理場景與時間順序，但在確定瓶頸方面通常不如人意。主要原因在于，當同時有先后兩個至上系統(tǒng)瓶頸時，于測壓過程不管如何增壓，因為前面出現(xiàn)的瓶頸限制了測壓設備的迭代速率，后面的系統(tǒng)瓶頸將一直不會顯露出來，這就干擾了測試與調(diào)優(yōu)效率。

2.2.2 依靠最小業(yè)務單位創(chuàng)建測壓環(huán)境的基本思路

本文主要從最小業(yè)務單位著手，將可能干擾系統(tǒng)性能的條件控制在最小時間范疇與相關(guān)因素內(nèi)[1]?；诖?，經(jīng)研究被測應用系統(tǒng)的業(yè)務邏輯，根據(jù)序列把業(yè)務單元組成存在前置關(guān)系和沒有前置關(guān)系的某個業(yè)務單元序列。各業(yè)務單元序列看作一個測壓環(huán)境逐步展開測壓，且把存在業(yè)務邏輯關(guān)系的測壓結(jié)果進行比較，如此就可以迅速確定故障點與瓶頸。

3 實驗檢測及分析

實驗選擇了2臺虛擬機，主要用作運轉(zhuǎn)Nginx軟件與壓測設備。壓測設備選用Webbench，一個輕量級網(wǎng)站壓測產(chǎn)品。其工作原理為：父進程fork許多子進程，各子進程于客戶需求時間和默認時間內(nèi)基于GET信號對目標Web反復傳出具體訪問請求。實驗選擇虛擬機配備與運轉(zhuǎn)系統(tǒng)版本狀況見表1所示。

表1 虛擬機配備與運轉(zhuǎn)系統(tǒng)版本狀況

在壓測環(huán)節(jié)，選擇實時軟件監(jiān)控設備mpstat監(jiān)測運轉(zhuǎn)Nginx的Linux平臺的CPU狀態(tài)，檢查CPU統(tǒng)計數(shù)據(jù)。在多邏輯CPU軟件內(nèi)，其不僅可以呈現(xiàn)CPU的數(shù)據(jù)還可以查看全部的CPU平均狀態(tài)數(shù)據(jù)[2]。Webbench的父進程于全部子進程退出后將統(tǒng)計并呈現(xiàn)出最終檢測結(jié)果，再退出。利用這兩個工具可以獲得當下軟件的CPU資源應用量與頁面下載速率。

統(tǒng)計各不同work-processes值條件下，CPU應用率與頁面下載速度，且計算獲得COPD值。借助matplotlib與numpy等系統(tǒng)，制作出worker-processes值和COPD指標的聯(lián)系。

當worker進程數(shù)超過邏輯CPU數(shù)目時，因為系統(tǒng)內(nèi)自身無什么進程與worker爭奪CPU時間片，因此就算worker進程數(shù)增多也不會有正面作用。反而因為進程數(shù)的增加，多了多余的進程轉(zhuǎn)換，COPD的分子無謂加大，令指標表現(xiàn)更加差一點。

圖1上COPD值順著橫軸類似單調(diào)遞減，表示在X的取值區(qū)間中CPU應用率越大COPD值越小。由于Linux系統(tǒng)內(nèi)分布的對外服務僅有Nginx，且無其他需要大量資源的進度與worker進度競爭，優(yōu)先級調(diào)整對worker進度獲得CPU時間片沒有過大影響[3]。若實際條件下Nginx和其他服務運轉(zhuǎn)于同個主機上，能夠按照以上方案實際檢測，明確優(yōu)先級怎樣設置。

總之，對于Nginx的COPD的提高完善，能夠聚集在CPU應用率方面。在具體業(yè)務中，能夠觀察軟件業(yè)務高峰期穩(wěn)固的CPU應用率。故worker-processes取值的運算公式可以是：

如此不僅可以符合原來業(yè)務的需求，還能夠提效。就worker-priority來說，若Nginx運轉(zhuǎn)的系統(tǒng)上沒有分布其他應用，將之保留默認值就行。

4 測試結(jié)果探究

4.1 依靠最小業(yè)務單位的檢測與調(diào)優(yōu)方式

本實例的首次“測試-調(diào)優(yōu)”循環(huán)過程發(fā)現(xiàn)：“客戶登錄、內(nèi)部信息核實、內(nèi)部中心記錄核實、業(yè)務上交”都有超時情況，再交給各研發(fā)小組同步實現(xiàn)針對性調(diào)優(yōu)。因為依靠最小業(yè)務單位確定的測壓環(huán)境，促使各研發(fā)小組成員可以隨時檢測所管理模塊的調(diào)優(yōu)成效，而不能等待負責前置要求功能模塊的研發(fā)小組先調(diào)優(yōu)[5]。

等各研發(fā)小組做好各自模塊調(diào)優(yōu)工作后，再開始一次包括全部最小業(yè)務單位壓力條件的回歸檢測。通過兩次檢測與循環(huán)調(diào)優(yōu)后，調(diào)優(yōu)后的系統(tǒng)滿足了檢測依據(jù)標準。

4.2 傳統(tǒng)模擬工作場景的檢測與調(diào)優(yōu)方式

作為對比方法，若測壓場景簡單模擬實際工作場景展開設置將會發(fā)現(xiàn)，最初檢測時僅僅是“客戶登錄”超時，待負責登錄的研發(fā)小組處理了“客戶登錄”故障后，充分檢測又發(fā)現(xiàn)“內(nèi)部信息核實”超時或錯誤；負責小組處理了“內(nèi)部信息核實”故障，重新檢測又找出“部中心記錄核實”超時；處理了“部中心記錄核實”故障，才得知大并發(fā)客戶下“業(yè)務上交”偶然會出現(xiàn)錯誤[5]。如此不僅延遲了調(diào)優(yōu)進度，而且若這些有瓶頸的業(yè)務存在相互作用與耦合聯(lián)系的話，問題將越來越復雜。

5 結(jié)論

本文探究了性能測試過程的重要問題之一即確定性能瓶頸的各種內(nèi)容，分析了依靠最小業(yè)務單元創(chuàng)建靈活的測壓環(huán)境，進而加速找到軟件瓶頸的辦法。系統(tǒng)性能檢測與調(diào)優(yōu)緊密聯(lián)系，在一個常見的性能測試與調(diào)優(yōu)活動中，利用IBM系統(tǒng)研制成本估算模型。怎樣高效地找到性能瓶頸，進而節(jié)約測試和調(diào)優(yōu)時間，以減少研發(fā)成本，一直是個需要著重探究的問題。