• 網(wǎng)站越快，用戶的黏性就越高；

• 網(wǎng)站越快，用戶忠誠度更高；

• 網(wǎng)站越快，用戶轉(zhuǎn)化率越高。

簡言之，速度是關(guān)鍵。

——《Web 性能權(quán)威指南》

顯然，高性能意味著“快”。但對快的定義，在不同的系統(tǒng)中，標準是不一樣的。為了獲得快的體驗，通常我們需要平衡成本和收益等方面制定優(yōu)化方法。

如果說“快”的標準不好把握的話，但我們都對類似這樣的典型論述有一致的結(jié)論，比如：

• 內(nèi)存是快的

• U 盤是慢的

之所以對這些問題容易有統(tǒng)一的認知，是因為我們已經(jīng)對需要度量的范圍與標準有了較清晰的概念，我們不自覺地預設一些應該受到控制的變量，并將它們與其他某些事物做了對比。比如，在談 U 盤慢時，往往指的是在同一臺計算機上與硬盤、內(nèi)存等其他存儲方法作比較。

類似地，當我們談論應用的性能時，也需要把應用所在的環(huán)境、處理的數(shù)據(jù)量等情況一同納入考慮范圍內(nèi)。這些因素常常讓速度的定義變得復雜。因此，在談論高性能之前，我們首先需要對性能進行建模，確定合適的用于反映性能狀況的指標，并據(jù)此制定明確在各項因素在各種情況下的性能目標。比如，在談論 Web 應用程序的速度時，我們經(jīng)常談到 QPS、TPS 和響應時間等指標，而確定性能目標時，則往往要考慮數(shù)據(jù)量的多少、并發(fā)用戶數(shù)目和網(wǎng)絡帶寬等情況。

在性能建模時，越細致、越全面的數(shù)據(jù)就越真實地反映出系統(tǒng)的狀況，從而能為做出正確的決策提供更準確的依據(jù)。一般來說，網(wǎng)絡、磁盤等 IO 設備、操作系統(tǒng)，以及應用程序運行時（如 CLR、JVM）往往都提供了豐富的性能數(shù)據(jù)。對于 Web 和云原生系統(tǒng)而言，設計良好的服務端框架（如 Kubernetes），以及對開發(fā)人員友好的瀏覽器（如 Chrome）等也都會提供相關(guān)的性能接口。

舉例來說，如果考慮一個桌面應用程序，我們需要收集的指標有：

• 第一個界面出現(xiàn)的時間

• 第一個界面加載完畢的時間

• 某些典型事務處理時間

• 關(guān)閉窗口時的等待時間

• 從開始加載文件到能夠編輯文件的時間

在制定性能目標時，我們要選用一些典型的用戶機型進行模擬。在收集測試數(shù)據(jù)時，擺在面前的第一個問題是如何準確獲得這么多種類時間？靠人肉掐秒表也是一種思路，不過還是顯得太原始了一些。這時，我們需要在應用中添加一些性能埋點，并利用統(tǒng)一的工具收集這些數(shù)據(jù)（如操作系統(tǒng)提供的性能計數(shù)器）。

下面是利用 Windows 性能工具來查看 IO 操作在物理磁盤上執(zhí)行的情況：

這些性能數(shù)據(jù)不但能夠在制定科學的性能目標時提供幫助，更能夠在系統(tǒng)的性能未達預期時，在第一時間展示出系統(tǒng)瓶頸所在。一段時間以來，當網(wǎng)站慢時，我總是能夠通過 Chrome 開發(fā)人員工具提供的網(wǎng)絡時間線和性能分析工具快速地發(fā)現(xiàn)問題所在，并且運用《高性能網(wǎng)站建設指南》等經(jīng)典書籍中給出的切實的建議針對性地做出優(yōu)化。

下面是一個 Chrome 瀏覽器中加載資源時的資源瀑布圖：

有人說，所發(fā)現(xiàn)了問題時，就是解決了一半，對于一些容易解決的問題尤其如此。不過，一般來說，性能問題往往沒那么容易解決——除非是程序的實現(xiàn)有明顯的瑕疵（比如陷入了死循環(huán)）。相比于邏輯錯誤問題，解決性能問題一般需要具有一定經(jīng)驗的工程師才能勝任。

在優(yōu)化應用程序的性能時，一般會由根據(jù)距離應用的遠近，從外部到內(nèi)部將優(yōu)化分為這三個層次：

• 鏈路上的優(yōu)化

• 結(jié)構(gòu)性優(yōu)化

• 應用內(nèi)優(yōu)化

鏈路上的優(yōu)化指的是在用戶操作發(fā)出之后、真正到達應用程序邏輯執(zhí)行之前的過程期間執(zhí)行的優(yōu)化；結(jié)構(gòu)性優(yōu)化指的是對應用程序所處的環(huán)境、依賴的資源，以及應用本身的子系統(tǒng)間的關(guān)系等方面的優(yōu)化；而應用內(nèi)優(yōu)化則指的是對應用內(nèi)的實現(xiàn)方式（比如算法和數(shù)據(jù)結(jié)構(gòu)）進行優(yōu)化。

舉例來說，下圖是一個簡單的 Web 系統(tǒng)的結(jié)構(gòu)，用戶的操作指令發(fā)出之后，需要經(jīng)過互聯(lián)網(wǎng)到達負載均衡服務器，最后到達兩臺應用服務器中執(zhí)行運算邏輯，而應用依賴了讀寫分離的兩個數(shù)據(jù)庫。

在上述三種層次上，對系統(tǒng)的性能進行優(yōu)化時，可以考慮以下措施：

• （鏈路上）使用 DNS prefetch 技術(shù)減少域名查找時間

• （鏈路上）增加負載均衡服務器的出口帶寬

• （結(jié)構(gòu)性）增加一個新的應用服務器

• （結(jié)構(gòu)性）在應用服務器增加 CPU 核心數(shù)和內(nèi)存

• （應用內(nèi)）用多線程技術(shù)把操作數(shù)據(jù)庫和訪問磁盤的操作同步進行

• （應用內(nèi)）消除應用加載數(shù)據(jù)時的 n+1 問題

一般來說，鏈路上和結(jié)構(gòu)性方面的優(yōu)化，對于使用各類編程平臺實現(xiàn)的應用程序都一樣適用。對于一個 Web 系統(tǒng)來說，HTTP 請求到達 Web 應用之前的所有優(yōu)化，都屬于這兩類。時下，關(guān)于大流量、大并發(fā)系統(tǒng)的性能優(yōu)化方法，人們已經(jīng)討論的很多了。不過，縱觀那些優(yōu)化方法，實際上也都可以從應用內(nèi)的優(yōu)化方法上看到類似的方法，可以認為這些優(yōu)化思想大體是相通的。

從應用內(nèi)部優(yōu)化時，業(yè)務專家可以通過一些業(yè)務流程上的簡化等方法來有效地改善應用程序的性能，例如，在某些情形下省略一些不必要的運算等。這類優(yōu)化主要取決于業(yè)務規(guī)則的自身特點，難以統(tǒng)一地歸納出具體的經(jīng)驗。而在業(yè)務之外的優(yōu)化方法，各種應用程序之間卻是相通的。

通常，在應用內(nèi)，要在業(yè)務流程之外進行性能優(yōu)化，我們考慮以下方法：

并發(fā)與并行?也就是讓程序同時做多件事，以及將一件事分為多個小塊同時完成。 將按順序執(zhí)行（串行）的多個任務改為并行之后，處理時間從多個任務之和變成了多個任務中最慢的任務的時間。計算機系統(tǒng)中某個層次（如應用程序）的并行能力是由它的底層（如操作系統(tǒng)）的并發(fā)能力提供支持的。既然多核計算機早已普及，那么就沒有理由不好好利用并行處理能力了。

異步?在計算機系統(tǒng)中，運算往往要比輸入輸出（IO）操作快得多，不少看起來很慢的系統(tǒng)經(jīng)常是在空置地等待完成 IO 操作。異步化 IO 操作能讓計算機不再等待 IO 完成，從而能最大化地利用系統(tǒng)的運算能力。

緩存?不論是運算，還是 IO 操作都是要耗費時間的。“利用空間換時間”經(jīng)常是有效的優(yōu)化方法：典型地，在運算斐波那契數(shù)列時，如果不是有通項公式，在不用緩存的情況下幾乎不可能寫出符合時間要求的算法。

精減與壓縮?還是 IO 的問題。如果 IO 慢，就更不能讓它執(zhí)行不必要的操作了——比如多執(zhí)行的 SQL、多加載的 JavaScript 文件等。經(jīng)常，當數(shù)據(jù)量少了之后，由于需要處理的內(nèi)容少了，還同時能夠節(jié)省運算的時間。

技巧性優(yōu)化?上面所述的幾種方式，是在代碼級別的“通用”方法。而面對具體的問題，經(jīng)常會有一些技巧性優(yōu)化方法。比如，采用更具針對性的數(shù)據(jù)結(jié)構(gòu)，或已經(jīng)證實更高效的算法，更利于運行時進行垃圾回收的代碼風格等。

在上述這些方面的優(yōu)化，在不同類型的應用程序里，有具體的表現(xiàn)形式；而在不同編程平臺上，又可能有不同的實現(xiàn)。舉例來說，在 Web 前端應用里，異步可表現(xiàn)為異步加載 JavaScript/CSS 文件和異步執(zhí)行 Ajax；而在一個 Web 后端應用里，異步則表現(xiàn)為對文件、網(wǎng)絡等操作的異步執(zhí)行。如果具體到編程語言，Node.js 應用可能使用一個?nextTick?操作，而一個 ASP.NET 應用則使用一個?async?方法。需要參考其對應編程平臺的優(yōu)化經(jīng)驗進行實施。

最后，當我們掌握了優(yōu)化性能的方法，也不意味著我們一定要用盡各種方法去優(yōu)化我們編寫的每一個應用程序。在編寫代碼過程中，優(yōu)先選用更高性能的寫法通常是有益的（例如，使用 HashSet 替換 List 來存儲需要快速查找的集合）。另一方面，過早優(yōu)化是所有開發(fā)人員都容易忽略的陷阱（例如，集合的元素并不多，又大量用于循環(huán)時用 HashSet 替換了 List）。幾乎所有新的開發(fā)人員都聽說過“字符串是不可變量，應該盡量使用 StringBuilder”、“反射的性能很糟糕，應該盡量避免使用”之類的經(jīng)驗之談。單從字面來理解確實都是金玉良言，但作為一種優(yōu)化手段，性能優(yōu)化往往會要求應用程序遵守一些約束，這些約束有時會破壞代碼的可讀性，有時會改變編寫代碼的習慣，而這些往往意味著在更廣的維度上給團隊帶來成本。

---

作者和其他三位 ThoughtWorks 同事一同翻譯的《.NET 性能優(yōu)化》一書已于近日出版，各大在線書店有售。本書詳細解釋了影響應用程序性能的 Windows、CLR 的內(nèi)部結(jié)構(gòu)，并為讀者提供了衡量代碼如何獨立于外部因素執(zhí)行優(yōu)化的知識和工具。書中提供了大量的 C# 代碼示例和技巧，將幫您最大限度地提高算法和應用的性能。

盡管成書于數(shù)年之前，書中所述的大多數(shù)經(jīng)驗仍適用于最新的 .NET 框架和運行時。它不光講述適用于 .NET 平臺的性能優(yōu)化方法，還詳細地講解了性能度量的指標，以及普適性的性能優(yōu)化的思路和原理。既授人以魚，又授人以漁，是不可多得的上佳之作。

歡迎留下您對本文的討論，以及在日常開展性能優(yōu)化工作中的感悟。評論獲點贊最多的前五位讀者將獲贈《.NET 性能優(yōu)化》圖書一本（包郵）。

dotNET 跨平臺讀者獨享優(yōu)惠！公眾號讀者可以通過掃碼、點擊鏈接等方式在異步社區(qū)購買 《.NET 性能優(yōu)化》時，在結(jié)算時輸入優(yōu)惠碼?d4c43c-e?即可獲得10元現(xiàn)金優(yōu)惠。優(yōu)惠購買鏈接：https://www.epubit.com/book/detail/921?，也可通過亞馬遜、京東和當當?shù)染W(wǎng)站自行購買

原文鏈接：https://blog.jijiechen.com/post/high-performance-considerations/

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的当我们谈高性能时，我们谈些什么？（送书活动）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。