5000字詳解性能需求
編輯導(dǎo)語:一件產(chǎn)品的完成,最重要的一環(huán)便是它的性能,好產(chǎn)品的性能必定是被人們所需要的。這篇文章詳細(xì)闡述了產(chǎn)品性能需求的重要性,推薦想要了解性能要求的童鞋閱讀。
我剛工作時(shí),和政府部門做了個(gè)產(chǎn)品,功能就是個(gè)表單錄入,錄入完保存到系統(tǒng)。拿去給用戶演示,一切很完美。
但是當(dāng)開始試運(yùn)行時(shí),出現(xiàn)了問題——單據(jù)錄入完成后,保存無反應(yīng)。
后來一看是用戶在每次會(huì)同時(shí)錄入很多條內(nèi)容,在保存100條數(shù)據(jù)要30s才能保存成功。500條數(shù)據(jù)直接保存失敗。
當(dāng)然,這是我的問題,忽略了對性能的要求。
性能的重要性不必細(xì)說,有些數(shù)據(jù)表明:近80%的用戶反饋應(yīng)用響應(yīng)時(shí)間慢、點(diǎn)擊沒反應(yīng)等性能問題。
一般在公司里會(huì)有專門的測試人員對系統(tǒng)進(jìn)行性能測試,而對于性能的標(biāo)準(zhǔn),具體性能指標(biāo)多少合適,測試同學(xué)是不清楚的。
這個(gè)時(shí)候就需要產(chǎn)品狗們提出性能要求,給測試同學(xué)作參考。
接下來我們說說性能需求咋提以及性能指標(biāo)。
文章較長,建議收藏吃灰~
一、性能需求什么時(shí)候提
性能需求屬于非功能需求,一般在需求文檔內(nèi)需要有單獨(dú)模塊對性能做說明。
在寫需求文檔的時(shí)候就可以把性能需求一起規(guī)定好,在需求評審時(shí)也要評審下性能需求,讓各方達(dá)成一致。
研發(fā)同學(xué)在做技術(shù)設(shè)計(jì)時(shí)考慮進(jìn)來,避免在項(xiàng)目后期,出現(xiàn)重大性能問題。
測試同學(xué)在準(zhǔn)備測試用例時(shí),把性能也提前規(guī)劃進(jìn)來,提前準(zhǔn)備好測試方案。
另外性能測試也會(huì)占用一定的項(xiàng)目時(shí)間,需要在制定項(xiàng)目計(jì)劃時(shí),把性能測試的時(shí)間也納入計(jì)劃中。
二、性能需求怎么提
性能需求是指對系統(tǒng)性能進(jìn)行規(guī)范化描述,提出明確、合理的性能指標(biāo)要求。
主要分為2個(gè)方面:
1.系統(tǒng)整體性能需求
主要指標(biāo)包括
- 在線用戶數(shù)數(shù)量:如支持在線用戶數(shù)200w
- 平穩(wěn)運(yùn)行時(shí)間:如7×24h
- 平均響應(yīng)時(shí)間:如頁面打開時(shí)間低于2s。(對于一些主要頁面可以在做單獨(dú)性能要求)
- CPU:CPU使用率<75%
2.不同功能/接口性能需求
由于不同功能、不同接口的使用頻率、重要程度不同,我們可以對不同功能、不同接口單獨(dú)提出性能需求。
可以從下邊幾個(gè)標(biāo)準(zhǔn)來確定需要單獨(dú)明確的功能/接口
- 高頻:系統(tǒng)中高頻率使用的功能,高頻調(diào)用的接口,像刷動(dòng)態(tài)
- 關(guān)鍵:系統(tǒng)中不能出現(xiàn)問題的功能,像登錄、注冊、支付
- 特色:系統(tǒng)中的亮點(diǎn)功能,產(chǎn)品的賣點(diǎn),比如處方合理性審核系統(tǒng)、風(fēng)險(xiǎn)監(jiān)控系統(tǒng),還有像交友的在線匹配功能。
- 涉及大量數(shù)據(jù):比如說報(bào)表查詢。
舉個(gè)“登錄”功能的例子:
并發(fā)用戶數(shù)500,響應(yīng)時(shí)間2s,TPS到500/s,CPU不得超過75%。
下邊我們詳細(xì)說說性能指標(biāo)以及性能指標(biāo)的標(biāo)準(zhǔn)
三、常見的性能指標(biāo)有哪些
主要有響應(yīng)時(shí)間、并發(fā)數(shù)、吞吐量、CPU等,對于App需要關(guān)注FPS、啟動(dòng)時(shí)間、耗電量等。
我們一個(gè)個(gè)看看:
1. 響應(yīng)時(shí)間——最直觀的表現(xiàn)
“系統(tǒng)應(yīng)該讓用戶知道發(fā)生了什么,在適當(dāng)?shù)臅r(shí)間內(nèi)做出適當(dāng)?shù)姆答??!蹦釥柹捎眯允瓌t——狀態(tài)可見性
在尼爾森可用性十原則中的“狀態(tài)可見性原則”提到的“適當(dāng)?shù)臅r(shí)間”就可以理解為響應(yīng)時(shí)間。
站在用戶角度描述就是點(diǎn)擊一下按鈕,系統(tǒng)在頁面上給出反饋的時(shí)間。這個(gè)反饋時(shí)間是用戶最能直觀感受到的,也是對用戶體驗(yàn)影響最大的地方。
當(dāng)響應(yīng)時(shí)間>5秒后,74%的PC端用戶、50%以上的App用戶會(huì)選擇放棄操作,30%的用戶會(huì)選擇卸載應(yīng)用,33%以上的用戶會(huì)轉(zhuǎn)身使用競品。
嚇人不?
我們接著看下響應(yīng)時(shí)間的定義:提交請求和返回該請求的響應(yīng)之間使用的時(shí)間。主要由網(wǎng)絡(luò)傳輸時(shí)間和業(yè)務(wù)處理、數(shù)據(jù)處理時(shí)間組成。
而對于產(chǎn)品來說,需要關(guān)注的是頁面響應(yīng)時(shí)間,就算接口處理完成,數(shù)據(jù)傳到客戶端上了,在前端也需要解析出來,也會(huì)消耗一定時(shí)間。
響應(yīng)時(shí)間多長才能滿足要求呢?
之前有個(gè)2-5-10原則,而現(xiàn)在隨著技術(shù)、硬件的更新?lián)Q代,響應(yīng)時(shí)間也有了1-3-5標(biāo)準(zhǔn)。
即1s內(nèi)用戶完全可以接受,3s內(nèi)用戶覺得還可以,5s用戶就會(huì)開始焦躁不安。
當(dāng)然這只是個(gè)通用標(biāo)準(zhǔn),不是個(gè)固定標(biāo)準(zhǔn)。我們在提出需求時(shí),可以結(jié)合業(yè)務(wù)重要性、數(shù)據(jù)量大小、使用頻次來做綜合考慮。
舉個(gè)例子:導(dǎo)出excel報(bào)表。對于很多B端產(chǎn)品,這是個(gè)剛需、高頻的功能。
我們可以這樣提出性能要求:
- 1萬條數(shù)據(jù),導(dǎo)出完成用時(shí)3s。
- 3萬條數(shù)據(jù),導(dǎo)出完成用時(shí)5s。
- 10萬條數(shù)據(jù),導(dǎo)出完成用時(shí)8s。
我從網(wǎng)上找到一些響應(yīng)時(shí)間參考指標(biāo),大家可以看下:
- 互聯(lián)網(wǎng)企業(yè):500毫秒以下,例如淘寶業(yè)務(wù)10毫秒左右。
- 金融企業(yè):1秒以下為佳,部分復(fù)雜業(yè)務(wù)3秒以下。
- 保險(xiǎn)企業(yè):3秒以下為佳。
- 制造業(yè):5秒以下為佳。
2. 并發(fā)用戶數(shù)——籠統(tǒng)也直觀的指標(biāo)
并發(fā)用戶數(shù)的定義是每秒同時(shí)向服務(wù)器提交請求的用戶總數(shù)量。
關(guān)于并發(fā)用戶數(shù)有2個(gè)理解:
- 多個(gè)用戶同一時(shí)間做不同操作,比如多個(gè)用戶有發(fā)動(dòng)態(tài)的,有刷動(dòng)態(tài)的。
- 多個(gè)用戶同一時(shí)間做同一個(gè)操作,比如多個(gè)用戶一起發(fā)動(dòng)態(tài)。
對于這2個(gè)理解,在性能需求上可以分開提,比如:
- 系統(tǒng)支持并發(fā)用戶數(shù)500
- 發(fā)布動(dòng)態(tài):支持300人并發(fā)發(fā)布動(dòng)態(tài)。
有幾種并發(fā)用戶數(shù)評估方法,大家可以看下:
1)公式1:
n:平均每天的訪問用戶數(shù)。App可以直接用日活代替。
L:一天內(nèi)用戶從登錄到退出的平均時(shí)間,可以理解為平均用戶使用時(shí)長。
T:考察時(shí)間長度,一天內(nèi)多長時(shí)間有用戶在使用系統(tǒng)。
舉個(gè)例子:
App日活是10w,用戶平均使用時(shí)長是10min,用戶每天活躍時(shí)間大約是從早上10點(diǎn)到晚上10點(diǎn)。
公式里的n=10w,L=10min,T=12h
C=(10w×10min)/12h,時(shí)間單位統(tǒng)一成秒
C=(10w×10×60)/(12×3600)≈1388人/秒
峰值C’=1388×3×根號1388≈1500人/秒
提需求時(shí)可以以峰值并發(fā)用戶數(shù)為準(zhǔn)
2)公式2:
C=(用戶總量/統(tǒng)計(jì)時(shí)間)*影響因子
影響因子一般為3
比如App的每天晚上8點(diǎn)-10點(diǎn)用戶最活躍,且活躍用戶有8w。
8w/2h×3≈33人/秒
3)公式3:
根據(jù)80~20原則:80%的請求在20%的時(shí)間內(nèi)產(chǎn)生。然后結(jié)合PV一起算(注意不是UV,因?yàn)橐粋€(gè)用UV產(chǎn)生多個(gè)PV)
比如1天的PV有100w
先算80%的PV:100w×80%=80w
20%的時(shí)間:24h×20%=4.8,換算出秒,就是4.8×3600=17280秒
并發(fā)數(shù)就是:80w/17280=46人/秒
如果是B端私有化部署的產(chǎn)品,一般使用人數(shù)比較固定,我們可以從企業(yè)人員數(shù)量做評估:用戶數(shù)量×比例,比例可以視具體情況而定,一般取8%-20%。
當(dāng)然這些都是評估方法,得出的具體數(shù)據(jù)量只是做個(gè)參考。
3. 吞吐量——衡量系統(tǒng)處理能力的重要指標(biāo)。
吞吐量是指單位時(shí)間內(nèi)系統(tǒng)能處理的請求數(shù)量,體現(xiàn)著系統(tǒng)處理請求的能力。
吞吐量的量化指標(biāo)有:TPS(每秒事務(wù)數(shù))、QPS(每秒查詢數(shù))
TPS:是指事務(wù)數(shù)/秒。一個(gè)事務(wù)是指服務(wù)器發(fā)送請求,服務(wù)器做出反應(yīng)的過程。
整體過程就是:用戶做出操作>>請求服務(wù)器>>服務(wù)器處理>>服務(wù)器處理完成返回到用戶。
每秒能完成多少個(gè)流程就是多少個(gè)TPS
簡單理解:就是登錄一次算一個(gè)事務(wù),每秒能完成2個(gè)登錄事務(wù),就是2個(gè)TPS。
QPS:是指每秒查詢率。指一臺服務(wù)器每秒能夠響應(yīng)的查詢次數(shù)。
QPS 基本類似于 TPS,不同的是:在完成一個(gè)事務(wù)時(shí),會(huì)存在多次查詢服務(wù)器,所以應(yīng)該是TPS≤QPS。
另外TPS、QPS響應(yīng)時(shí)間與并發(fā)用戶數(shù)有關(guān)系,對應(yīng)的公式是:
TPS=并發(fā)用戶數(shù)/平均響應(yīng)時(shí)間。
當(dāng)性能測試完,測試說500TPS,我們要有個(gè)大約概念,如果響應(yīng)時(shí)間按1s算,那并發(fā)數(shù)就是500。
一般的標(biāo)準(zhǔn)有:
- 互聯(lián)網(wǎng)電子商務(wù):10000TPS~100000TPS,例如天貓5萬TPS
- 互聯(lián)網(wǎng)中型網(wǎng)站:100TPS~500TPS
- 互聯(lián)網(wǎng)小型網(wǎng)站: 50TPS~100TPS
4. CPU
CPU指標(biāo)主要指的CPU利用率。
程序在運(yùn)行的時(shí)候,會(huì)使用CPU做處理計(jì)算。就會(huì)占用CPU的空間,如果占用過多,系統(tǒng)就會(huì)出現(xiàn)卡頓、無響應(yīng)的情況。
CPU標(biāo)準(zhǔn):
- CPU<20%的利用率為資源空閑
- 在20%~60%之間表示資源使用穩(wěn)定
- 在60%~80%之間表示資源使用飽和
當(dāng)>75%時(shí),就需要關(guān)注了。
對于web端,一般指服務(wù)器的CPU。而對于移動(dòng)端,常指手機(jī)的CPU 。
App的CPU一般在20-40%,最多不能超過75%,如果長時(shí)間cpu利用率過高,就會(huì)產(chǎn)生發(fā)燙、閃退。
5. 內(nèi)存
內(nèi)存主要是運(yùn)行處理CPU發(fā)出的指令,在內(nèi)存里處理完畢后,再反饋給CPU。
在網(wǎng)絡(luò)上或者硬盤上加載的資源,一定會(huì)通過內(nèi)存交換,可以理解為:頁面加載出來的圖片、文字會(huì)暫時(shí)存到內(nèi)存里的,處理完成后就刪掉。
內(nèi)存和CPU類似,資源都是有限的,如果占用過多,會(huì)出現(xiàn)卡頓或閃退的現(xiàn)象。
內(nèi)存常內(nèi)存使用率做為指標(biāo),一般<70%。
6. 磁盤吞吐量
磁盤吞吐量是指單位時(shí)間內(nèi)通過磁盤的數(shù)據(jù)量,主要是每秒的讀、寫請求大小。
一般用磁盤繁忙率來確定性能,磁盤繁忙率要<70%。
這個(gè)指標(biāo)了解即可。
7. 網(wǎng)絡(luò)吞吐量
是指有每秒有多少兆流量進(jìn)出,一般情況下不能超過設(shè)備最大傳輸能力的70%。
這個(gè)指標(biāo)了解即可。
8. 錯(cuò)誤率
錯(cuò)誤率=(失敗事務(wù)數(shù)/事務(wù)總數(shù))*100%。
在一定并發(fā)下,循環(huán)調(diào)用某個(gè)接口,會(huì)出現(xiàn)接口報(bào)錯(cuò)的情況。錯(cuò)誤率正常情況下要為0。
在高并發(fā)的情況下錯(cuò)誤率一般要低于0.6%,就是成功率要高于99.4%。
這個(gè)指標(biāo)了解即可。
像CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)是指服務(wù)器的資源利用率,主要是對公司內(nèi)部來說。
性能測試的同學(xué)對于這些指標(biāo)的標(biāo)準(zhǔn)都很清楚,對于我們產(chǎn)品,需要明白這些定義與具體標(biāo)準(zhǔn)即可,性能需求提不提問題都不大。
四、移動(dòng)端需要關(guān)注的性能指標(biāo)
1. FPS
FPS是指每秒顯示的幀數(shù),主要用來體現(xiàn)出app的流暢度。
App的FPS一般>24幀/秒,最好是60幀/秒。
FPS的越高并不意味著越流暢,F(xiàn)PS低也不意味著頁面卡。
還需要關(guān)注幀率的穩(wěn)定性。如果一直都是低幀率,卡頓現(xiàn)象感受不明顯,如果幀率忽高忽低,就會(huì)有明顯的掉幀、卡頓現(xiàn)象。
對于游戲類app幀率要求較高,對于非游戲類app,我認(rèn)為只要能保證沒有明顯的卡頓現(xiàn)象就可以了。
2. 耗電量
在App中,CPU處理、藍(lán)牙、定位、傳感器、GPU(圖形處理)都會(huì)加快耗電量。
對于不同的App單位時(shí)間耗電量是不同的,耗電量的標(biāo)準(zhǔn)可以通過對比得出:
- 與歷史版本間進(jìn)行對比。如果新版本與上一個(gè)版本單位時(shí)間內(nèi)耗電量相差過多,則需要優(yōu)化。
- 與競品對比,如果比競品多了10%以上的耗電量,也需要優(yōu)化。
3. App啟動(dòng)時(shí)間
在說響應(yīng)時(shí)間的時(shí)候,我們提到1-3-5原則,5s的時(shí)候用戶已經(jīng)開始焦慮了。
而App的啟動(dòng)時(shí)間,是用戶感知到的第一個(gè)時(shí)間段,直接影響用戶對App的首要體驗(yàn),第一次留不住,讓用戶再回來就更難了。
App的響應(yīng)時(shí)間標(biāo)準(zhǔn)是最大不能超過5s。
如果啟動(dòng)時(shí)間過長,該優(yōu)化就優(yōu)化。
當(dāng)然也可以對于歷史版本與競品進(jìn)行對比,看看自家App的水平在哪。像支付寶,啟動(dòng)時(shí)間是秒開。
性能指標(biāo)一般就以上這些,大家需要理解下。
五、性能需求達(dá)不到怎么辦
一般性能測試同學(xué)在測試完成后,會(huì)給出對應(yīng)的性能測試報(bào)告,我們可以通過解讀性能報(bào)告的內(nèi)容來判斷是否需要優(yōu)化性能。
在我的工作經(jīng)歷中,很多時(shí)候會(huì)出現(xiàn)性能不達(dá)標(biāo)的情況,如果性能需求不滿足,我們可以按照以下方式確定:
1. 重新分析指標(biāo)合不合理
一般在評估時(shí)會(huì)對性能要求過高,需要重新定義性能指標(biāo)再做判斷。
2. 判斷實(shí)際性能與性能需求是否相差太多
如果相差不大,可以先發(fā)版,延期處理性能問題。
如果相差太大,不能接受,就要與研發(fā)溝通,確定是否有優(yōu)化方案、優(yōu)化方案內(nèi)容、優(yōu)化是否會(huì)導(dǎo)致延期。
如果會(huì)引起延期,就要和領(lǐng)導(dǎo)反饋,以及同步各方。
六、如何從產(chǎn)品設(shè)計(jì)上提高性能
性能問題歸根到底是技術(shù)問題,而為了達(dá)到更好的性能指標(biāo),達(dá)到最好的用戶體驗(yàn),我們也可以從產(chǎn)品設(shè)計(jì)上整點(diǎn)花樣。
- 采用tab頁的方式:同一個(gè)頁面數(shù)據(jù)過多時(shí),使用tab頁分開加載。
- 分頁加載:一次加載10條/20條等。
- 盡量不采用全屏加載的方式,使用懶加載、預(yù)加載。
- 懶加載:比如圖片先展示縮略圖,然后點(diǎn)擊查看原圖。
- 預(yù)加載:提前把內(nèi)容加載好,用戶進(jìn)入到頁面時(shí),可以直接看。有些app的開屏廣告就是提前預(yù)加載好,用戶下次點(diǎn)擊進(jìn)入時(shí)可以直接觀看。
- 連接超時(shí)后進(jìn)行情感化提示:設(shè)置超時(shí)時(shí)間10s,當(dāng)超時(shí)后,通過有趣的方式提示用戶。
- “欺騙”用戶:在頁面顯示操作成功,但是后端還在處理。微信發(fā)朋友圈時(shí),就算在斷網(wǎng)的情況下也是可以發(fā)布出來,但是就自己能看到,等聯(lián)網(wǎng)后才能成功發(fā)布出來。
上邊的幾種方式雖然是和技術(shù)相關(guān)的,但是這些是直接影響產(chǎn)品用戶體驗(yàn),還是需要我們產(chǎn)品提出。
另外對于緩解用戶的焦慮感,可以使用有趣、好玩的加載動(dòng)畫,分散用戶的注意力。
也可以采用進(jìn)度條來體現(xiàn)系統(tǒng)處理的進(jìn)度。對于處理時(shí)間確實(shí)很長的,給用戶個(gè)大約用時(shí),讓用戶有個(gè)心理預(yù)期。
七、總結(jié)
性能需求是個(gè)容易忽視,卻無比重要的地方。如果你一直忽略性能需求,下次的需求文檔里一定要寫上。
如果你不提,一上線系統(tǒng)卡成狗,你是產(chǎn)品,就是你的鍋。
本文由 @王大鹿 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
有收獲
解釋的很清除,喜歡這樣的文章。
多謝支持,你的文章也很棒啊
哇哦,很好的文章了
多謝支持,有用就好
感謝分享
多謝支持
非常有用
多謝支持,有用就好
好。
哈哈哈多謝大佬
作者寫的很詳細(xì)呀,也很棒,感覺還是很有用的
多謝支持,能用到就好
性能的好壞的也是消費(fèi)者現(xiàn)在比較看重的一個(gè)問題。
用戶可以忍受交互上的不足,但沒辦法忍受性能上的不足
看起來很專業(yè),作者講的很詳細(xì)
多謝支持
作者講的很詳細(xì),理解了,感謝作者分享!
多謝支持,有用就好