基于最小業(yè)務(wù)單元的Web系統(tǒng)性能測(cè)試調(diào)優(yōu)

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

0 引言

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

1 性能測(cè)試分析

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

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

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

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

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

2.2 依靠最小業(yè)務(wù)單元?jiǎng)?chuàng)建測(cè)壓環(huán)境的辦法

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

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

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

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

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

3 實(shí)驗(yàn)檢測(cè)及分析

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

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

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

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

當(dāng)worker進(jìn)程數(shù)超過(guò)邏輯CPU數(shù)目時(shí)，因?yàn)橄到y(tǒng)內(nèi)自身無(wú)什么進(jìn)程與worker爭(zhēng)奪CPU時(shí)間片，因此就算worker進(jìn)程數(shù)增多也不會(huì)有正面作用。反而因?yàn)檫M(jìn)程數(shù)的增加，多了多余的進(jìn)程轉(zhuǎn)換，COPD的分子無(wú)謂加大，令指標(biāo)表現(xiàn)更加差一點(diǎn)。

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

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

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

4 測(cè)試結(jié)果探究

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

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

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

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

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

5 結(jié)論

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