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