一、通常的性能問題類型
讓我們一起看看那些公共的性能問題,看看他們是或者不是.我們將了解到為什么我們常常在開發期間會錯過這些問題.我們也會看看當我們考慮性能時語言的選擇、延遲、帶寬、計算等因素.
二、語言的考慮
人們經常關注所使用的編程語言的速度。然而，這經常沒有抓住要點。這是一個非常簡單的觀點，掩蓋了技術選擇的細微差別,用任何語言編寫速度慢的軟件都很容易。由於當今計算機的處理速度非常強大，所以解釋性能相對較慢的語言通常足夠快，而開發中性能的提高是值得的.要理解所涉及的論點和權衡是很重要的，即使在讀完這本書之后您決定使用C#和.NET.
編寫速度最快的軟件的方法是深入了解底層硬件並用匯編語言編寫。（甚至機器代碼）。但開發、調試和測試都很復雜，這需要專家形知識。我們現在很少這樣做，除了非常小的應用程序（如虛擬現實游戲、科學數據處理，有時還有嵌入式設備），但通常只用於軟件的一小部分.
C＃在速度和靈活性之間提供了良好的平衡，使其適用於各種各樣的應用程序，尤其是服務器端Web應用程序
三、性能問題的類別
1.延遲
內存延遲
網絡延遲
磁盤IO延遲
繁瑣的交互/握手
2.帶寬
過載的負荷
未優化的數據
壓縮的平衡
3.計算問題
工作於過於大量的數據
計算非必須的結果
暴力的算法
4.響應
可離線處理的同步操作
緩存及處理作廢的數據
在為平台編寫軟件時，通常會受到兩種資源的限制。即:計算處理速度和訪問遠程（到處理器）資源。處理速度如今很少是一個限制因素，這可以用於與其他資源進行交易,例如，壓縮一些數據以減少網絡傳輸時間。訪問遠程資源（如主內存，磁盤和網絡）將產生各種時間成本。了解處理速度不是受單個值影響，而是多個參數影響非常重要。這些參數中帶寬和延遲是最重要的,
延遲是操作開始之前的滯后時間，而帶寬是數據在操作開始后轉移的速率。提交一個硬盤驅動事件的帶寬是非常高的，也是具有非常高的延遲的。這會使來回發送大量文本文件變得非常慢，但是或許，發送大量3D視頻是一個不錯的選擇（取決於Weissman
得分了）。
移動電話數據連接可能更適合文本文件。 雖然這是一個人為的例子，但是同樣的問題通常適用於計算堆棧的每一層，其時間差的數量級相似。 問題在於差異太快無法察覺，我們需要使用工具和科學來看待它們。
解決性能問題的秘訣是對該技術有更深入的了解,並知道在較低級別會發生什么。 您應該了解框架在網絡級別上的說明。 掌握這些命令如何在底層硬件上運行以及它們如何受到部署到的基礎架構的影響也很重要。
四、什么時候性能是重要的
性能並不總是很重要。知道什么時候是重要的,什么時候不重要,是非常必要的技能。一般的經驗法則是，如果用戶需要花事件來等待事情發生，那么就應該讓性能良好。如果可以異步執行對用戶沒有影響,就可以按照異步地方式執行,如:隊列,或者其他非UI線程.
某些情況下,程序被設計為看起來緩慢,主要的原因是為了系統安全,例如一些解密算法.
五、為什么常常沒有發現性能問題
在開發中沒有注意到性能問題的主要原因之一是一些問題在開發系統上是不可感知的。在延遲增加之前可能不會出現問題。這可能是因為大量的數據被加載到系統中並且檢索特定的記錄需要更長的時間。這也可能是因為每個系統被部署到單獨的服務器上，從而增加了網絡等待時間。另外當數據量沒有上來,或者請求量沒有上來,這些問題都是難以發現的.所以提前的壓測是很有必要的.
當您從一開始就考慮性能時，解決問題的成本更低、速度更快。對於軟件開發中的大多數問題來說，這都是正確的。越早抓到BUG，越好。發現錯誤的最糟糕的時間是一旦部署，然后由用戶報告。與功能性BUG相比，性能問題有點不同，因為它們通常只在規模上顯示出來，除非您去尋找它們，否則在實際部署之前您不會注意到它們。您可以編寫集成測試和負載測試，以對照具體的量化目標檢查性能，我們將在本書后面討論這些目標。