編輯導語：一件産品的完成，最重要的一環便是它的性能，好産品的性能必定是被人們所需要的。這篇文章詳細闡述了産品性能需求的重要性，推薦想要了解性能要求的童鞋閱讀。

我剛工作時，和政府部門做了個産品，功能就是個表單錄入，錄入完保存到系統。拿去給用戶演示，一切很完美。

但是當開始試運行時，出現了問題——單據錄入完成後，保存無反應。

後來一看是用戶在每次會同時錄入很多條内容，在保存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個理解：

1. 多個用戶同一時間做不同操作，比如多個用戶有發動态的，有刷動态的。
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~100TPS

4. CPU

CPU指标主要指的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. FPS

FPS是指每秒顯示的幀數，主要用來體現出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. 判斷實際性能與性能需求是否相差太多

如果相差不大，可以先發版，延期處理性能問題。

如果相差太大，不能接受，就要與研發溝通，确定是否有優化方案、優化方案内容、優化是否會導緻延期。

如果會引起延期，就要和領導反饋，以及同步各方。

性能問題歸根到底是技術問題，而為了達到更好的性能指标，達到最好的用戶體驗，我們也可以從産品設計上整點花樣。

1. 采用tab頁的方式：同一個頁面數據過多時，使用tab頁分開加載。
2. 分頁加載：一次加載10條/20條等。
3. 盡量不采用全屏加載的方式，使用懶加載、預加載。
4. 懶加載：比如圖片先展示縮略圖，然後點擊查看原圖。
5. 預加載：提前把内容加載好，用戶進入到頁面時，可以直接看。有些app的開屏廣告就是提前預加載好，用戶下次點擊進入時可以直接觀看。
6. 連接超時後進行情感化提示：設置超時時間10s，當超時後，通過有趣的方式提示用戶。
7. “欺騙”用戶：在頁面顯示操作成功，但是後端還在處理。微信發朋友圈時，就算在斷網的情況下也是可以發布出來，但是就自己能看到，等聯網後才能成功發布出來。

上邊的幾種方式雖然是和技術相關的，但是這些是直接影響産品用戶體驗，還是需要我們産品提出。

另外對于緩解用戶的焦慮感，可以使用有趣、好玩的加載動畫，分散用戶的注意力。

也可以采用進度條來體現系統處理的進度。對于處理時間确實很長的，給用戶個大約用時，讓用戶有個心理預期。

性能需求是個容易忽視，卻無比重要的地方。如果你一直忽略性能需求，下次的需求文檔裡一定要寫上。

如果你不提，一上線系統卡成狗，你是産品，就是你的鍋。

本文由 @王大鹿 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!