“應用很慢，你可以确保它快速嗎？”

上面的引用應該會讓任何有經驗的工程師感到脊背發涼。這裡的“快速”的具體含義是什麼?

除非你對“快速”部分有一個定義，否則你将永遠陷入優化周期，因為每個應用都可以不斷的被創建的更快一些。然而在現實生活中，性能并不是唯一一個需要我們完成的要求。所以為了能提供最大的價值，我們應該知道什麼時候該停止性能優化。或者更重要的是，引導我們的性能目标應該是什麼樣的。

功能以外的需求

企業已經越來越好的表達軟件的功能需求。但是考慮到功能需求以外的事情，比如可用性、兼容性或者性能，這個時候企業主的描述常常是相當于一片空白。而這片空白最常見的形式就是“确保它快”或“有沒有更好的情況”，你對此會有類似于一下的處理方式：

• 95%實施在系統内的業務的響應時間必須在5秒内；
• 系統必須支持100個并發用戶。

相比較“确保它快”來說，以上兩種方式咋一看并不壞，畢竟它讓你有了一個明确的引導目标，不是嗎？事實上，上面的比“快”更糟糕。因為它包含了一些看起來可以用作終極目标的數字。

實際上，這些數字充其量隻能作為基礎使用。你可以從這兩個出發擴充需求。

95%實施在系統内的業務的響應時間必須在5秒内

剩下的5%是什麼？響應時間變為10秒或更多可以嗎？所以在設定的時候不要固定單一的目标，應該有一個可接受的延遲分布：

• “顯示我當前賬戶的結算”。這個每天可能會被執行數百萬次，因為每個零售客戶都會與銀行互動。
• “顯示我的賬戶在2013年的所有交易”。這個相比較前面的執行次數要少很多很多。

對于上面兩種情況我們設定的目标應該是不同的，第一種響應要求要比5秒短，而第二種則可以适當的放寬要求。

當使用到測量值時系統的負載是什麼？有多少其他操作可以同時進行？這些都是你應該連接潛在相關的加載/吞吐量需求的地方。

響應時間是在終端用戶環境中測量的嗎（如浏覽器響應或Android應用更新結果）？或者測量是按照最後一個字節從服務器端發出時算的？為了避免含糊不清的定義測量标準，在這裡我們需要對延遲測量精确化。

批量處理作業/異步流程？每個月批量處理計算最終信用卡餘額的延遲時間是兩小時還是5秒鐘？對于大型業務完整的财務報表異步的存入到CSV中并在10分鐘後通過郵件的方式發送？所以，明确一件事的操作延時是否要緊也是重要的。

通過以上幾段的分析，我們可以将第一種方式的性能描述細分為：

• 對不同的情況制定不同的延遲目标；
• 連接相關的加載/吞吐量需求；
• 對延遲測量精确化？即測量的标準是什麼；
• 确定該項操作是否緊要。

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

100個用戶通過CDN每10秒點擊一次你網站的靜态圖片，我想你閉着眼睛就可以構建這樣的一個系統。100個用戶同時在你的網站上編碼4K視頻文件，這時候就難以想象了。

當考慮到真正的并發性時事情從模糊轉向了毫無意義。比如将“100個并發用戶”理解為“100個操作并發的被100個線程處理”。假設每個這樣的操作過程需要10秒，然後系統的吞吐量為10ops/sec。如果你現在縮短10倍的操作時間，即每個操作過程需要1秒，系統的吞吐量将提高到100ops/sec。但是你會發現前一種并不滿足“100個真正的并發用戶”需求，隻同時處理10個操作。這是一個失敗的需求

取代“并發用戶”或其他類似的條款，這類需求應該更清楚的表達某些用戶的行為。将這些描述轉化為潛在的負載測試，以允許你模拟所需要的負載。

在這裡不推薦測量吞吐量，現實生活中的應用往往是多功能的并被用于動态情況。這使得很難通過吞吐量來表達性能目标。但是如果是特定的隻用于某件事的應用，如發票支付，吞吐量就成了衡量特定目标的好方法。

産能計劃

• 你的應用應該滿足性能要求的數據量是多少？要清楚系統中存在的數據量。
• 關于基礎設施的約束是什麼？比如内存、CPU的方案等， 知道這一點可以幫助你了解基礎設施的限制。
• 應用部署的環境是什麼？比如網絡帶寬是多少，是否支持離線操作等。你需要了解你應用将要部署的環境需求。

結論

以上所列的描述是不完整的。舉例來說，當涉及到可伸縮性和可用性時，你會面臨一個全新的要求。本文旨在抛磚引玉，在你下次遇到模糊定義的性能需求時，你會有一系列的問題擴展這些模糊的需求。

與業務者的溝通有助于你發現可衡量的、特定的目标。從企業者來看，自然是希望所有操作的“超快速”。而為了實現這一目标，無外乎還是要歸結到成本上。你說呢？（編譯：陳明）

原文來自：DZone

,

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

查看全部