性能測試的原則和方法-創(chuàng)新互聯(lián)

什么是性能問題

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了黎平免費(fèi)建站歡迎大家使用！

性能問題表現(xiàn)第一種

小規(guī)模使用的時(shí)候性能表現(xiàn)很好，在大規(guī)模使用的時(shí)候，性能變得很差，業(yè)務(wù)響應(yīng)時(shí)間隨業(yè)務(wù)壓力變得越來越慢

原因：代碼中對資源使用產(chǎn)生的瓶頸，后續(xù)的請求在資源(cpu、內(nèi)存、鎖、線程池)上排隊(duì)

例子： 沒有索引的表的查詢 隨著業(yè)務(wù)量增加，表的行數(shù)快速增加，查詢越來越慢

性能測試解決的大部分問題是這種類型

性能問題表現(xiàn)第二種

在一定壓力情況下，應(yīng)用的性能突然變差或者不可使用

原因：應(yīng)用突然進(jìn)入了一個(gè)異常邏輯，占用了很多資源，并且無法從異常狀態(tài)下退出

例子：fetion 后臺(tái) 初期版本中使用同步的socket連接，網(wǎng)絡(luò)單點(diǎn)異常的時(shí)候，全網(wǎng)的服務(wù)都不可用。

性能測試很難解決這種類型的性能問題。很難定位異常邏輯是什么。

性能問題表現(xiàn)第三種

在壓力大于某個(gè)閥值的情況下，總會(huì)出現(xiàn)少量業(yè)務(wù)錯(cuò)誤

原因：業(yè)務(wù)邏輯考慮不嚴(yán)密，導(dǎo)致少量流程不是按照期望發(fā)生

例子：取一個(gè)值做uniquekey值，鎖保護(hù)不夠?qū)е拢≈挡晃ㄒ弧?/p>

性能測試能夠很好的解決這類問題。

一些基本概念詳細(xì)解析

響應(yīng)時(shí)間

Response time是性能測試中考察被測試軟件性能的一個(gè)指標(biāo)；

Response time包括從客戶端請求發(fā)出開始，到reponse 應(yīng)答回來后的時(shí)間總和，可能包括：

網(wǎng)絡(luò)傳輸

cpu上可執(zhí)行隊(duì)列的等待時(shí)間

cpu計(jì)算

線程執(zhí)行sleep語句的時(shí)間

鎖、閂的等待時(shí)間

磁盤io等待時(shí)間等。

吞吐量tps

吞吐量 tps是考察性能的另一個(gè)指標(biāo)；

單位時(shí)間內(nèi)完成業(yè)務(wù)量的多少，tps 是一個(gè)具體的常用的指標(biāo)，每秒鐘完成的業(yè)務(wù)個(gè)數(shù)。

通常的誤會(huì)是認(rèn)為response time一定會(huì)影響tps，這個(gè)不一定成立

并發(fā)

并發(fā)是指同時(shí)被處理的請求個(gè)數(shù)，同時(shí)處理可以有2個(gè)含義

同時(shí)都在線程堆棧上的請求

指在正在cpu上處理的請求

這里指得是后者。

那么大的tps = Concurrency*1000 /請求在cpu上的處理時(shí)間(ms)

思考時(shí)間

Think Time思考時(shí)間 Think time是在測試代碼中出現(xiàn)的概念，為了在測試代碼中模擬時(shí)間用戶的思考時(shí)間而加的sleep時(shí)間，2個(gè)作用

第一作用是控制測試代碼的業(yè)務(wù)執(zhí)行速度，完美地執(zhí)行出預(yù)計(jì)的場景

模擬實(shí)際用戶執(zhí)行的思考時(shí)間

有狀態(tài)的服務(wù) 很重要

無狀態(tài)的服務(wù) 不重要

測試壓力 business load

測試壓力是什么？或者是客戶做了什么導(dǎo)致服務(wù)器產(chǎn)生壓力

對于無狀態(tài)服務(wù)器，客戶端的壓力來源于客戶端的請求數(shù)/秒

對于有狀態(tài)服務(wù)器，客戶端的壓力是客戶端的在服務(wù)器的留存信息和rps。

數(shù)據(jù)庫是一個(gè)有狀態(tài)的服務(wù)器

有狀態(tài)的服務(wù)器更容易有性能問題

性能測試過程

完美的測試過程

完美的性能測試就是軟件在現(xiàn)網(wǎng)上實(shí)際運(yùn)行的過程

實(shí)驗(yàn)室狀態(tài)下永遠(yuǎn)也無法完全模擬

性能測試無法找到所有的問題

性能測試方案

定義了在影響軟件運(yùn)行性能的各個(gè)方面采用什么樣的方法和策略模擬真實(shí)的情況，達(dá)到盡量真實(shí)模擬的目的。

非常重要， 決定了測試的成敗

基礎(chǔ)數(shù)據(jù) : 測試之前，測試環(huán)境中已有的數(shù)據(jù)總和

關(guān)于基礎(chǔ)數(shù)據(jù)的原則

必須調(diào)查或者預(yù)測出數(shù)據(jù)庫表中每個(gè)表應(yīng)該有多少行的數(shù)據(jù)。

而且數(shù)據(jù)取值要實(shí)際情況一樣豐富。

數(shù)據(jù)長度和實(shí)際情況相同

基礎(chǔ)數(shù)據(jù)決定著數(shù)據(jù)庫server的cpu、內(nèi)存、io使用或其他多種資源的使用邏輯。

測試數(shù)據(jù)： 從基礎(chǔ)數(shù)據(jù)中選取的，參與到性能測試中的數(shù)據(jù)

選擇原則

在應(yīng)用合理范圍內(nèi)隨機(jī)挑選數(shù)據(jù)、挑選足夠的量。

挑選數(shù)據(jù)的方式通常影響數(shù)據(jù)庫的內(nèi)存和io，有狀態(tài)服務(wù)的cpu和內(nèi)存，線程、鎖等。

業(yè)務(wù)模型

測試完成哪些業(yè)務(wù)？完成速率？

建立業(yè)務(wù)模型的原則

最好是實(shí)際用戶行為的統(tǒng)計(jì)，如果沒有借助同類軟件的用戶行為統(tǒng)計(jì)，再?zèng)]有，根據(jù)有經(jīng)驗(yàn)人員的預(yù)估。

把用戶所有可能使用業(yè)務(wù)按使用頻繁程度排序，頻繁程度越高就越應(yīng)該納入測試場景。

查看業(yè)務(wù)消耗計(jì)算資源的程度，預(yù)計(jì)消耗程度越大的越應(yīng)該納入測試場景

建立業(yè)務(wù)模型的原則

多個(gè)業(yè)務(wù)在一起的復(fù)雜場景：把所有業(yè)務(wù)的在周期內(nèi)的tps放在一起考察，一般情況下所有業(yè)務(wù)會(huì)有一致性的行為，即tps變化一致，取峰值階段的tps為測試通過標(biāo)準(zhǔn)。

如何有明顯不一致，需要取2到多個(gè)典型場景分別測試

測試場景

多大測試壓力（多少在線用戶或者rps是多少）

預(yù)估和實(shí)際預(yù)測的結(jié)果

測試多長時(shí)間？

無狀態(tài)的幾個(gè)小時(shí)

有狀態(tài)的幾天

硬件資源選擇的原則

大型分布式軟件的中每個(gè)角色都需要負(fù)載均衡的設(shè)計(jì)才能夠平滑擴(kuò)展。 那么測試環(huán)境只需要取得這樣一個(gè)環(huán)境的小的集合就可以了。

單個(gè)硬件設(shè)備最好使用上線后用的機(jī)器，因?yàn)椴煌O(shè)備之間的差異很大，無法但從cpu、內(nèi)存、tpcc等指標(biāo)來分析硬件之間的差異。

使用差異很大的設(shè)備測試只能定性的說明問題，無法定量

如何編寫測試代碼

能和實(shí)際的客戶一樣完成業(yè)務(wù)功能。這是最基本的能力，也是性能測試的基礎(chǔ)，必選

對每次與服務(wù)器的交互做嚴(yán)格的結(jié)果正確性檢查，保證功能執(zhí)行的正確性。性能測試的目標(biāo)不僅僅是提供測試的工作壓力，而且要保證測試功能的正確性，必選。

提供出錯(cuò)日志功能，這對于初步分析性能問題，或者測試代碼、被測試軟件的功能問題都是非常好的手段，可選

測試代碼在設(shè)計(jì)時(shí)要意識(shí)地保證數(shù)據(jù)庫的數(shù)據(jù)量的穩(wěn)定性，可選。

提高測試代碼可配置性，保證在多種不同的測試場景下，測試場景可迅速建立，可選。

測試執(zhí)行人的能力要求

測試人需要按照測試方案的要求，配置測試代碼和使用測試工具建立起方案中的測試場景，必選。

按照方案選擇合理的測試數(shù)據(jù)，必選。

測試人必須完全了解測試代碼的每個(gè)細(xì)節(jié)，如果在測試中發(fā)現(xiàn)測試任何錯(cuò)誤，如果這個(gè)錯(cuò)誤是測試代碼或者場景設(shè)置的問題，測試人有能力解決，必選。

判斷測試的結(jié)果分析是否有性能問題，必選。

對于服務(wù)方的問題，提供當(dāng)時(shí)的上下文環(huán)境供開發(fā)和優(yōu)化人員分析，可選。

能夠解決被測試軟件方由于配置錯(cuò)誤等引起的簡單問題，可選。

軟件優(yōu)化的基本步驟

性能問題有哪些？ cpu的瓶頸、內(nèi)存的瓶頸、磁盤io的瓶頸、網(wǎng)絡(luò)io的瓶頸、線程之間同步的瓶頸等等

軟件優(yōu)化好以后應(yīng)該是什么樣？特征

Tps 基本上和cpu使用率正相關(guān)

響應(yīng)時(shí)間1-50 ms， tps 幾百幾千幾萬

參考測試設(shè)備 cpu等資源的情況

業(yè)務(wù)完成過程的復(fù)雜度

如果有性能瓶頸

首先排查其它瓶頸，保證tps和cpu正相關(guān)。

察看是否有cpu濫用的現(xiàn)象

“所有高cpu的問題都是不必要的循環(huán)引起的”---個(gè)人體會(huì)

沒有索引的表的查詢

應(yīng)用本地沒有緩存，反復(fù)從數(shù)據(jù)庫或者其它應(yīng)用獲取。

線程數(shù)太多，導(dǎo)致過多的上下文切換。

性能測試的限制

性能測試何時(shí)測不準(zhǔn)？

性能測試有限性導(dǎo)致測不準(zhǔn)

沒有測試到的場景和業(yè)務(wù)

軟件異常流程

硬件、網(wǎng)絡(luò)環(huán)境不一樣

比如客戶端特別移動(dòng)客戶端網(wǎng)速慢

用戶行為變化導(dǎo)致的測不準(zhǔn)

用戶數(shù)據(jù)增長導(dǎo)致的測不準(zhǔn)

一個(gè)性能優(yōu)化的例子

被測試系統(tǒng)問題介紹：一個(gè) 使用 dot net remoting的系統(tǒng)，在線上使用 1年多，突然出現(xiàn) 嚴(yán)重的outofmemory的問題

負(fù)載非常：忙時(shí)remoting的調(diào)用大約0.35個(gè)/秒

Cpu使用率低： 平均只有 1%

內(nèi)存只升不降，在幾天內(nèi)達(dá)到大值，導(dǎo)致 outofmemory。如下圖：

從應(yīng)用來看，每天只有20個(gè)客戶端在線使用，幾百個(gè)tcp連接怎么來的？

原因：網(wǎng)絡(luò)異常，連接已經(jīng)中斷，但server沒有感知。

應(yīng)用部署在win2000上， win2000 無法感知連接異常

解決辦法：升級到win2003， 在注冊表增加tcp連接的檢測，每90秒檢查一次

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前題目：性能測試的原則和方法-創(chuàng)新互聯(lián)
標(biāo)題URL：http://www.muchs.cn/article14/depige.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、軟件開發(fā)、外貿(mào)網(wǎng)站建設(shè)、定制網(wǎng)站、建站公司、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)