你真的知道如何定義性能要求麼？

【編者按】本文做者是 Nikita Salnikov Tarnovski，是 plumbr 的聯合創始人，做爲一名高級開發者，他同時也是一位應用性能調優的專家，擁有多年的性能調優經驗。本文中他經過常見的性能需求誤區經驗，分享應該如何去設定實際的性能需求目標，本文系 OneAPM 工程師編譯呈現。

如下爲譯文：

「這個應用跑得太慢，你能讓它快起來嗎？」

——企業老闆這樣說道

若是你是個經驗豐富的工程師，對這種場景確定不陌生，一聽到這種話，整個脊椎毛骨悚然。筆者一直強調用「測量不猜想」的觀點處理性能優化問題。這意味着你要先明確經理所指的「快」是什麼。若是沒有這個定義，你可能永遠都會困在優化週期中，由於每一個重大應用總能在某些方面獲得改進，從而提升速度。

現實生活中，性能並不是是亟待解決的惟一任務；爲了提供最有價值的產品，咱們應該知道何時應該中止性能優化。更重要的是，咱們應該清楚地知道咱們的性能目標是什麼，並有一個明確的規劃去實現之。

錯誤定義的性能需求

相對以前，企業老闆在表達軟件功能需求上已經有所進步。但在功能性需求以外——好比應用的可用性、兼容性或性能——老闆內心其實徹底沒底。這個空白經常用「確保它夠快」這種模棱兩可的話，或者與下面相似的要求表達出來：

• 系統內95%的業務操做必須在 5 秒內獲得響應

• 系統必須支持 100 個併發用戶

乍一看這些要求，你可能會以爲沒那麼糟。再也不一直唸叨着「快快快」，你如今至少有了一個明確的目標，對吧？事實證實，上面的目標甚至比「快快快」的唸叨更加糟糕。雖然它包含了一些能夠設爲終極目標的具體數據；但實際狀況下，上述兩點要求最多隻能做爲提出更好優化問題的基礎。下面解釋這些要求的錯誤之處。

95%的業務操做必須在5秒內獲得響應

剩下的五個百分點要怎麼辦？若是將響應時間設爲10秒，這個目標是否切合實際呢？鏈接超時也能夠嗎？其實，你應該避免將時間設定爲惟一目標，而是設置一個可接受的延遲分佈範圍。這個要求的另外一個問題是，它將全部的操做等同化。若是有95%的操做在4.9秒內反應，就萬事大吉了麼？即使這些操做的速度還能夠更快？如下面這些操做爲例：

1. 顯示我當前的帳戶餘額：這個操做天天被執行數百萬次，也是每一個零售客戶與銀行互動的第一個問題。

2. 顯示2015年的全部交易：天天僅有少數用戶執行該操做。

顯然，你須要區別對待不一樣的操做，對第一個操做有更高要求，而第二次操做能夠有更寬鬆的要求。所以，你應該爲每一個操做類型設置可接受的延遲時間分佈，而不是對全部操做一視同仁。

你還應該將延遲需求與加載/吞吐量需求聯繫起來。所以在進行性能測量時，應該找出系統中的負載，併發掘有多少其餘操做能夠同時執行。而後用這些信息來構建延遲需求。

精確延遲測量的層。是在終端用戶的環境中進行響應時間測量呢 (好比，瀏覽器呈現響應時或一個安卓應用更新結果時)？仍是當最後一個字節從服務器端發送後進行測量呢？

大多數軟件老是能夠優化得更快，問題是它在經濟上是否可行。

最後，你應該肯定哪些操做徹底不用擔憂延遲。批處理做業和異步流程就是很好的例子。每個月運行的批處理任務須要兩個小時來計算最終的信用卡餘額，不該該視爲違反了5秒閾值。完整的會計 CSV 報表經過電子郵件發送得等到10分鐘後，屬於異步編譯，也不該該視做違反標準。

系統必須支持100個併發用戶

設想一個網站有100個用戶在線，每次點擊靜態圖像都經過 CDN 進行呈現須要10秒時間——我打賭你閉着眼睛就能構建出這樣一個系統。可是，100個用戶同時在網站上編碼 4K 視頻文件則要另當別論了。

當考慮真實併發性時，事情從模糊不清變得毫無心義，好比將「100個併發用戶」翻譯成「100次由100個線程併發處理的操做」。假設每個這樣的操做須要10秒的處理時間，那麼系統的吞吐量就是每秒10次操做。若是如今將操做時間減小十倍，每一個操做只需1秒鐘，你就已經將吞吐量提升到100次操做/秒。然而，你並未實現 「100個真實併發用戶」的要求，只是併發處理10個操做，這意味着你未能知足性能要求。

其實，在表達用戶的具體行爲時，應該避免「併發用戶」或任何相似的術語，要求應該更加明確，儘可能將這些描述轉化爲能夠模擬所需負載的負載測試。

須要注意，筆者並不是建議你測量吞吐量。這其實沒多大用，由於現實生活中的應用一般是多功能的、應用於動態的情況。因此很難明確表達出吞吐量的性能目標(每小時的操做量)。可是，若是一個應用被特定設計爲只實現一個功能，例如發票支付，那麼，設置相似於「1000個發票/分鐘」的吞吐量目標，是很是好的可測量的具體目標。

容量規劃

容量規劃是你應該精確指定的另外一重要性能需求。你的團隊是有望實現上文提到的目標——數據庫中容納一萬個賬戶和一千萬個事務？或者指望系統知足一百萬個帳戶和十億交易這些條件？請明確系統中儲存的數據量。

別忘了明確有關基礎設施的經濟約束。你是否準備使用價值 500美圓/月的 AWS 實現你的性能要求？或者你能財大氣粗地在32核和幾 TBs 容量的高端配置上部署解決方案？知道這些問題的答案能夠幫助你瞭解基礎設施能承受的性能目標。因此在肯定性能需求以前，你應該明確基礎設施的限制。

在制定性能需求時，還應該考慮客戶的網絡帶寬限制。網絡帶寬是否能接受對操做發送幾個 MBs 來回的要求？移動應用當然使用普遍，但你不能期望每一個客戶都使用全能的 4G 網絡，因此應該構建一組離線操做，能夠在本地進行處理，從而將流量從兆字節轉換爲千字節。

結論

本文所描述的各個方面還不夠完整。在可伸縮性和可用性方面，還有許多性能方面的考慮，能夠引導你進一步完善需求。即使如此，你應該更仔細地審視模糊的性能需求，列舉出能落實到現實須要的問題。和企業老闆合做制定可測量的具體目標。不然，你就沒有真正的目標去實現並衡量結果。

經過這個過程，也能夠了解相關的成本。企業老闆老是渴望更詳細地瞭解成本！若是你還記得，大多數軟件老是能夠優化得更快，問題是它在經濟上是否可行。從企業全部者的角度來看，他們天然想讓全部操做都儘量快。但只有當咱們瞭解了實現目標的成本限制，才能設置更爲現實的指望。

OneAPM 是應用性能管理領域的新興領軍企業，能幫助企業用戶和開發者輕鬆實現：緩慢的程序代碼和 SQL 語句的實時抓取。想閱讀更多技術文章，請訪問 OneAPM 官方博客。
本文轉自 OneAPM 官方博客