比“快速”更糟？如何定義性能需求
摘要：面對“快速”等模糊化性能需求應該如何去處理？本文旨在拋磚引玉，在遇到模糊定義的性能需求時，會有一系列的問題擴展這些模糊的需求。當然與業務者的溝通有助于你發現可衡量的、特定的目標。
上面的引用應該會讓任何有經驗的工程師感到脊背發涼。這里的“快速”的具體含義是什么?
除非你對“快速”部分有一個定義，否則你將永遠陷入優化周期，因為每個應用都可以不斷的被創建的更快一些。然而在現實生活中，性能并不是唯一一個需要我們完成的要求。所以為了能提供最大的價值，我們應該知道什么時候該停止性能優化。或者更重要的是，引導我們的性能目標應該是什么樣的。
功能以外的需求
企業已經越來越好的表達軟件的功能需求。但是考慮到功能需求以外的事情，比如可用性、兼容性或者性能，這個時候企業主的描述常常是相當于一片空白。而這片空白最常見的形式就是“確保它快”或“有沒有更好的情況”，你對此會有類似于一下的處理方式：
相比較“確保它快”來說，以上兩種方式咋一看并不壞，畢竟它讓你有了一個明確的引導目標，不是嗎？事實上，上面的比“快”更糟糕。因為它包含了一些看起來可以用作終極目標的數字。
實際上，這些數字充其量只能作為基礎使用。你可以從這兩個出發擴充需求。
95%實施在系統內的業務的響應時間必須在5秒內
剩下的5%是什么？響應時間變為10秒或更多可以嗎？所以在設定的時候不要固定單一的目標，應該有一個可接受的延遲分布：
對于上面兩種情況我們設定的目標應該是不同的，第一種響應要求要比5秒短，而第二種則可以適當的放寬要求。
當使用到測量值時系統的負載是什么？有多少其他操作可以同時進行？這些都是你應該連接潛在相關的加載/吞吐量需求的地方。
響應時間是在終端用戶環境中測量的嗎（如瀏覽器響應或Android應用更新結果）？或者測量是按照最后一個字節從服務器端發出時算的？為了避免含糊不清的定義測量標準，在這里我們需要對延遲測量精確化。
批量處理作業/異步流程？每個月批量處理計算最終信用卡余額的延遲時間是兩小時還是5秒鐘？對于大型業務完整的財務報表異步的存入到CSV中并在10分鐘后通過郵件的方式發送？所以，明確一件事的操作延時是否要緊也是重要的。
通過以上幾段的分析，我們可以將第一種方式的性能描述細分為：
系統必須支持100個并發用戶
100個用戶通過CDN每10秒點擊一次你網站的靜態圖片，我想你閉著眼睛就可以構建這樣的一個系統。100個用戶同時在你的網站上編碼4K視頻文件，這時候就難以想象了。
當考慮到真正的并發性時事情從模糊轉向了毫無意義。比如將“100個并發用戶”理解為“100個操作并發的被100個線程處理”。假設每個這樣的操作過程需要10秒，然后系統的吞吐量為10ops/sec。如果你現在縮短10倍的操作時間，即每個操作過程需要1秒，系統的吞吐量將提高到100ops/sec。但是你會發現前一種并不滿足“100個真正的并發用戶”需求，只同時處理10個操作。這是一個失敗的需求
取代“并發用戶”或其他類似的條款，這類需求應該更清楚的表達某些用戶的行為。將這些描述轉化為潛在的負載測試，以允許你模擬所需要的負載。
在這里不推薦測量吞吐量，現實生活中的應用往往是多功能的并被用于動態情況。這使得很難通過吞吐量來表達性能目標。但是如果是特定的只用于某件事的應用，如發票支付，吞吐量就成了衡量特定目標的好方法。
產能計劃
結論
以上所列的描述是不完整的。舉例來說，當涉及到可伸縮性和可用性時，你會面臨一個全新的要求。本文旨在拋磚引玉，在你下次遇到模糊定義的性能需求時，你會有一系列的問題擴展這些模糊的需求。
與業務者的溝通有助于你發現可衡量的、特定的目標。從企業者來看，自然是希望所有操作的“超快速”。而為了實現這一目標，無外乎還是要歸結到成本上。