選擇什么來衡量

在搜集數據測試數據前，你需要知道你要以怎樣的指標來衡量測試結果。這聽起來很容易，但實際上比你想象中的要難許多。如果你想降低內存使用量，你會選擇什么方式呢？

• 私有工作集（Private working set）

• 提交大小（Commit size）

• 內存頁（Paged pool）

• 峰值大小（Peak working set）

• 內存堆大小（.NET heap size）

• 大對象堆（Large object heap）
  and so on

為了追蹤內存的使用情況，我們還需要記錄一個小時內的平均值和峰值？內存與處理器進程負載的關系？正如你所看到的，隨便就能舉出十幾個甚至更多與內存相關的性能指標。

我們需要盡可能的準確描述要測試的東西

一旦你決定要測試某個產品，你需要為每個性能指標提出一個目標。在早期開發階段，訂立的目標可能不夠準確，或者與實際情況不符。但重點是，不是說一定要達到一開始規劃的目標，而是強迫你構建一套可以自動測試你說提出這些性能指標的體系結構。
你的目標應該是可量化的嗎，你的程序目標也許是“快”，這個是一個不錯的指標，但不是一個好的指標，因為“快”是一個很主觀的因素，你沒有一個明確的東西來表示你是否達到了快這個目標。你需要給目標定一個數字，并且這個數字是要可以測試出來的。

壞：“用戶界面需要正常相應”
好：“任何操作不應該造成UI線程卡住超過20毫秒”

能量化還不夠好，還需要有更具體的描述，例如下面說的內存指標

壞：“內存應小于1G”
好：“內存在 100次/秒的峰值查詢情況下，內存使用不超過1G”

對于第二個例子，給出了一個具體的情景，要在這個情景下達成怎樣的目標就是一個比較好的測試用例

另外一個重要的決定性因素，是你寫的應用的目標是什么。如果是以一個帶GUI界面的引用，那么你需要必須保證任何時刻都能響應用戶的操作請求。如果你寫的是一個每秒處理幾百幾千訪問的服務器程序，你的目標就算要保證I/O和CPU的利用率在一個很低的范圍內。如果你設計的是一個與市面上不一樣的服務器應用，那么從效率的角度上看，一旦你的架構除出問題（性能上的），在重新修改架構就非常麻煩了。

在設計新系統時，我們需要對性能指標做一些規劃。這時你需要了解一些會對性能產生影響的地方，例如CPU，內存，IO的使用率等情況。舉個栗子，如果你有一臺16核，64G內存的機器以及10G的網絡帶寬，這時候你需要設定好一個閾值，如“每秒可以處理多少數據”，這個可以在一臺機器無法滿足需要時，你知道你還需要多少臺機器。這些信息都是你在做規劃時需要寫在規劃目標里的。

你可能聽過 _Donald Knuth 說過的：“過早優化是萬惡之源”。但這只適合代碼級別的優化。你必須清楚你在設計上的缺陷會對應用產生多大的影響。你必須把性能目標考慮到設計中。你必須在一開始時就有一個明確的目標。性能和安全以及一些東西時不能事后設計，否則你會被架構重構教會你做人的道理。

性能分析（設計）放在項目的開始，比在寫完代碼后進入測試階段再考慮性能，思路是不一樣的。在項目開始前，你可以設計出達到你想要的在性能上的擴展性，而不會陷入一些架構陷阱里（我暫時沒明白這里說的架構陷阱是指那些東西）。在進入項目的測試，部署和維護階段，你才有更多的時間在代碼層級的優化上，對熱點函數代碼做分析，減少cpu，內存的消耗。

最后，你需要了解Ahmdals定律(See [pdf]:http://www.writinghighperf.net/go/3)，特別是如何適用于順序（序列化）編程以及選擇哪個部分進行優化。在代碼級別的優化堆整體性能用處不大，甚至會浪費時間。但你總是希望優化代碼里效率最低的那部分。不過，聰明的你應該會知道，你不會有足夠時間去干這件事情。這就是為什么你需要有一個好的性能監控系統（工具），否則，你甚至不知道從哪里改起。

原文地址：http://www.cnblogs.com/yahle/p/6267039.html

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的[翻译]编写高性能 .NET 代码 第一章：性能测试与工具 -- 选择什么来衡量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。