《ASP.NET Core 高性能系列》關於性能的閒聊

1、一般的性能問題類型

讓咱們一塊兒看看那些公共的性能問題,看看他們是或者不是.咱們將瞭解到爲何咱們經常在開發期間會錯過這些問題.咱們也會看看當咱們考慮性能時語言的選擇、延遲、帶寬、計算等因素.

2、語言的考慮

　　人們常常關注所使用的編程語言的速度。然而，這常常沒有抓住要點。這是一個很是簡單的觀點，掩蓋了技術選擇的細微差異,用任何語言編寫速度慢的軟件都很容易。因爲當今計算機的處理速度很是強大，因此解釋性能相對較慢的語言一般足夠快，而開發中性能的提升是值得的.要理解所涉及的論點和權衡是很重要的，即便在讀完這本書以後您決定使用C#和.NET.

　　編寫速度最快的軟件的方法是深刻了解底層硬件並用彙編語言編寫。（甚至機器代碼）。但開發、調試和測試都很複雜，這須要專家形知識。咱們如今不多這樣作，除了很是小的應用程序（如虛擬現實遊戲、科學數據處理，有時還有嵌入式設備），但一般只用於軟件的一小部分.

 C＃在速度和靈活性之間提供了良好的平衡，使其適用於各類各樣的應用程序，尤爲是服務器端Web應用程序

3、性能問題的類別

1.延遲

內存延遲

網絡延遲

磁盤IO延遲

繁瑣的交互/握手

2.帶寬

過載的負荷

未優化的數據

壓縮的平衡

3.計算問題

工做於過於大量的數據

計算非必須的結果

暴力的算法

4.響應

可離線處理的同步操做

緩存及處理做廢的數據

　　在爲平臺編寫軟件時，一般會受到兩種資源的限制。即:計算處理速度和訪問遠程（處處理器）資源。處理速度現在不多是一個限制因素，這能夠用於與其餘資源進行交易,例如，壓縮一些數據以減小網絡傳輸時間。訪問遠程資源（如主內存，磁盤和網絡）將產生各類時間成本。瞭解處理速度不是受單個值影響，而是多個參數影響很是重要。這些參數中帶寬和延遲是最重要的,

　　延遲是操做開始以前的滯後時間，而帶寬是數據在操做開始後轉移的速率。提交一個硬盤驅動事件的帶寬是很是高的，也是具備很是高的延遲的。這會使來回發送大量文本文件變得很是慢，可是或許，發送大量3D視頻是一個不錯的選擇（取決於Weissman

得分了）。

　　移動電話數據鏈接可能更適合文本文件。 雖然這是一我的爲的例子，可是一樣的問題一般適用於計算堆棧的每一層，其時間差的數量級類似。 問題在於差別太快沒法察覺，咱們須要使用工具和科學來看待它們。

　　解決性能問題的祕訣是對該技術有更深刻的瞭解,並知道在較低級別會發生什麼。 您應該瞭解框架在網絡級別上的說明。 掌握這些命令如何在底層硬件上運行以及它們如何受到部署到的基礎架構的影響也很重要。

4、何時性能是重要的

　　性能並不老是很重要。知道何時是重要的,何時不重要,是很是必要的技能。通常的經驗法則是，若是用戶須要花事件來等待事情發生，那麼就應該讓性能良好。若是能夠異步執行對用戶沒有影響,就能夠按照異步地方式執行,如:隊列,或者其餘非UI線程.

某些狀況下,程序被設計爲看起來緩慢,主要的緣由是爲了系統安全,例如一些解密算法.

5、爲何經常沒有發現性能問題

　　在開發中沒有注意到性能問題的主要緣由之一是一些問題在開發系統上是不可感知的。在延遲增長以前可能不會出現問題。這多是由於大量的數據被加載到系統中而且檢索特定的記錄須要更長的時間。這也多是由於每一個系統被部署到單獨的服務器上，從而增長了網絡等待時間。另外當數據量沒有上來,或者請求量沒有上來,這些問題都是難以發現的.因此提早的壓測是頗有必要的.

　　當您從一開始就考慮性能時，解決問題的成本更低、速度更快。對於軟件開發中的大多數問題來講，這都是正確的。越早抓到BUG，越好。發現錯誤的最糟糕的時間是一旦部署，而後由用戶報告。與功能性BUG相比，性能問題有點不一樣，由於它們一般只在規模上顯示出來，除非您去尋找它們，不然在實際部署以前您不會注意到它們。您能夠編寫集成測試和負載測試，以對照具體的量化目標檢查性能，咱們將在本書後面討論這些目標。