計算機性能是一門令人激動的，富于變化同時又充滿挑戰的領域。

系統性能是對整個計算機系統的性能的研究，包括主要硬件組件和軟件組件。所有數據路徑上和從存儲設備到應用軟件上所發生的事情都包括在內，因為這些都有可能影響性能。對于分布式系統來說，這意味著多臺服務器和多個應用。如果你還沒有關于你的環境的一張示意圖，用來顯示數據的路徑，趕緊找一張或者自己畫一張。它可以幫助你理解所有組件的關系，并確保你不會只見樹木不見森林。

系統性能的典型目標是通過減少延時和降低計算成本來改善終端用戶的體驗。降低成本可以通過消除低效之處、提高系統吞吐量和進行常規性能調優來實現。

下面是系統性能的一些重要概念

延時對于某些環境，延時是被唯一關注的性能焦點。而對于其他環境，它會是除了吞吐量以外，數一數二的分析要點。

作為延時的一個例子，圖 2.3 顯示了如 HTTP GET 請求的網絡傳輸，其響應時間被分成連接延時和數據傳輸時間兩部分。

延時是操作執行之前所花的等待時間。在這個例子里，操作是網絡服務的數據傳輸請求。在這個操作發生之前，系統必須等待建立網絡連接，這就是這個操作的延時。響應時間包括了延時和操作時間。

因為延時可以在不同點測量，所以通常會指明延時測量的對象。例如，網站的載入時間由三個從不同點測得的不同時間組成 ：DNS 延時、TCP 連接延時和 TCP 數據傳輸時間。DNS 延時指的是整個 DNS 操作的時間，TCP 連接延時僅僅指的是初始化時間（TCP 握手）。

由于延時是一個時間上的指標，因此可能有多種計算方法。性能問題可以用延時來進行量化和評級，因為是用相同的單位來表達的（時間）。通過考量所能減少或移除的延時，預計的加速也可以被計算出來。這兩者不能用 IOPS 指標很準確地描述出來。

時間的量級和縮寫列在了表 2.1 中，可作為參考。

如果可能，其他的指標也會轉化為延時或者時間，這樣就可以進行比較了。如果必須在 100 個網絡 I/O 和 50 個磁盤 I/O 之間做出選擇，怎樣才能知道哪個性能更好？這是一個復雜的選擇，因為其中包含了很多因素 ：網絡跳數、網絡丟包率和重傳率、I/O 的大小、隨機或順序的 I/O、磁盤類型，等等。但是如果你比較的是 100ms 的網絡 I/O 延時和 50ms 的磁盤 I/O 延時，那差別就很明顯了！

時間量級我們可以對時間進行量化的比較，同時最好對時間和各種來源的延時的合理預期有本能的認識。系統各組件的操作的時間量級差別巨大，表 2.2 中提供的延時示例，從訪問 3.5GHz 的 CPU 寄存器的延時開始，闡釋了各種操作時間量級的差別。表中所示的是發生單次操作的時間均值，等比放大為一個假想的系統，將 1 個 CPU 周期的 0.3ns（十億分之一秒的三分之一 1）放大為現實生活中的 1 秒。

正如你所見，1 個 CPU 周期的時間是很短暫的。0.5 米差不多是你的眼睛到這個頁面的距離，光線走過這段距離需要的時間大約是 1.7ns。在這段時間里，現代的 CPU 已經執行了 5 個 CPU 周期，處理了若干個指令。

權衡你應該知道某些性能權衡關系。圖 2.4 展示的是好 / 快 / 便宜“擇其二”的權衡關系，右圖所示的是對應于 IT 項目的術語。

許多 IT 項目選擇了及時和成本低，留下了性能問題在以后解決。當早期的決定阻礙了性能提高的可能性時，這樣的選擇會變得有問題，例如，選擇了非最優的存儲架構，或者使用的編程語言或操作系統缺乏完善的性能分析工具。

一個常見的性能調優的權衡是在 CPU 與內存之間，因為內存能用于緩存數據結果，降低 CPU 的使用率。在有著充足 CPU 資源的現代系統里，交換可以反向進行 ：CPU 可以壓縮數據來降低內存的使用。

調優的影響性能調優實施在越靠近工作執行的地方效果最顯著。對于工作負載驅動的應用程序，這意味著調優性能的地方就在應用程序本身。表 2.3 展示了一個軟件棧的例子，說明了性能調優的各種可能。

對應用程序層級進行調優，可能通過消除或減少數據庫查詢獲得很大的性能提升（例如，20 倍）。在存儲設備層級進行調優，可以精簡或提高存儲 I/O，但是性能提升的重要部分在更高層級的操作系統棧代碼，所以對存儲設備層級的調優對應用程序性能的提升有限，是百分比量級的（例如，20%）。

在應用程序層級尋求性能的巨大提升，還有一個理由。如今許多環境都致力于特性和功能的快速部署，按每周或每天將軟件的變更推入生產環境。 因此，應用程序的開發和測試傾向于關注正確性，在部署前留給性能測量和優化的時間很少甚至沒有。之后當性能成為問題時，才會去做這些與性能相關的事情。

雖然發生在應用程序層級的調優效果最顯著，但這個層級不一定是觀測效果最顯著的層級。數據庫查詢緩慢最好從其所花費的 CPU 時間、文件系統和所執行的磁盤 I/O 方面來考查。使用操作系統工具，這些都是可以觀測到的。

合適的層級不同的公司和環境對性能有著不同的需求。你可能加入過這樣的公司，其分析標準要比你之前所見過的嚴格得多，甚至可能聽都沒聽過。或者是這樣的公司，你覺得很基本的分析被認為很高端甚至從未使用過（這是好消息 ：事情簡單輕松！）

這并不意味著某些公司做的是對的，某些做的是錯的。這取決于性能技術投入的投資回報率（ROI）。擁有大型數據中心或大型云環境的組織可能會雇用一個性能工程師團隊來分析所有的事情，包括內核內部和 CPU 性能計數器，并頻繁使用各種跟蹤工具。他們還可能對性能進行正式建模，并對未來的增長進行準確預測。對于每年在計算上有數百萬花費的環境來說，雇用這樣一個性能團隊是值得的，因為他們進行的優化就是投資回報。小型創業公司的計算開支不大，可能只進行表面的檢查，利用第三方監測方案來檢查性能和提供警報。

何時停止分析做性能分析時的一個挑戰是如何知道何時停止。有這么多的工具，有這么多的東西要檢查！

當我教性能課程時（最近我又開始教了），我給我的學生一個有三個原因的性能問題，我發現有些學生在找到一個原因后就停止了，有些則是兩個，有些則是三個。有些學生則繼續努力，試圖為性能問題找到更多的原因。誰的做法是正確的？說你應該在找到所有三個原因后就停止，可能很容易，但對于現實生活中的問題，你并不知道原因的數量。

這里有三種情況，你可以考慮停止分析，并提供了一些個人的例子。

當你已經解釋了大部分性能問題的時候。一個 Java 應用程序消耗的 CPU 資源是原來的 3 倍。我發現的第一個問題是異常堆棧消耗了 CPU。然后我量化了這些堆棧的時間，發現它們只占整個 CPU 占用的 12%。如果這個數字接近 66%，我就可以停止分析了。但在這種情況下，在 12% 的情況下，我需要繼續尋找。

當潛在的投資回報率低于分析的成本的時候。我所處理的一些性能問題可以帶來每年數千萬美元的收益。對于這些問題，我可以證明花幾個月的時間（工程成本）進行分析是合理的。其他的性能問題，比如說微服務，可能是以數百美元計算的，甚至不值得花 1 個小時的工程時間來分析它們。例外情況可能包括 ：當我沒有更好的事情可做時（這在實踐中從未發生過），或者如果我懷疑這可能是日后更大問題的隱患，值得在問題擴大之前進行調試時。

當其他地方有更大的投資回報率的時候。即使前兩種情況沒有得到滿足，其他地方有更大的投資回報時經常需要優先考慮。如果你是全職的性能工程師，根據潛在的投資回報率對不同的問題進行有選擇的分析可能是一項日常工作。

性能推薦的時間點環境的性能特性會隨著時間改變，更多的用戶、新的硬件、升級的軟件或固件都是變化的因素。一種環境，受限于速度 10Gb/s 的網絡基礎設施，當升級到 100Gb/s 時，很可能會發現磁盤或 CPU 的性能變得緊張。

性能推薦，尤其是可調優的參數值，僅僅在一段特定時間內有效。一周內從性能專家那里得到的好建議，可能到了下一周，經過一次軟件或硬件升級，或者用戶增多后就無效了。

在網上搜索找到的調優參數值對于某些情況可能能快速見效。但如果對于你的系統或者工作負載并不合適，它們也可能會對性能有所損害，或者合適過一次，就不再合適了，或者只是作為軟件的某個 bug 修復升級之前暫時的應急措施。這和從別人的醫藥箱里拿藥吃很像，那些藥可能不適合你，或者可能已經過期，或者只適合短期服用。

如果僅僅是出于要了解有哪些參數可調以及哪些參數在過去是需要調整的，那么瀏覽這些性能建議是有用的。針對你的系統和工作負載，這項工作就變成了考慮這些參數是不是要調，以及調整成什么值。如果其他人不需要調整那個值，或者調整了但并未將經驗分享出來，那么你有可能漏掉了重要的參數。

負載與架構應用程序性能差可能是因為軟件配置和硬件的問題，也就是它的架構和實現問題。另外，應用程序性能差還可能是由于有太多負載，而導致了排隊和長延時。負載和架構見圖 2.5。

如果對架構的分析顯示只是工作任務在排隊，處理任務沒有任何問題，那么問題就可能出在施加的負載太多上。在云計算環境里，這是需要引入更多的服務器實例來處理任務的征兆。

舉個例子，架構的問題可能是一個單線程的應用程序在單個 CPU 上忙碌，從而導致請求排隊，但是其他的 CPU 卻是可用且空閑的。在這個例子里，性能就被應用程序的單一線程架構限制住了。架構的另一個問題可能是一個程序的多個線程爭奪一個鎖，這樣只有一個線程可以向前推進，而其他線程在等待。

負載的問題可能會是一個多線程程序在所有的 CPU 上都忙碌，但是請求依然排隊的情況。在這個例子里，性能可能被限制于 CPU 的性能，或者說是負載超出了 CPU 所能處理的范圍。

指標性能指標是由系統、應用程序，或者其他工具選定的統計數據，用于測量感興趣的活動。性能指標用于性能分析和監測，可以由命令行提供數據，也可以由可視化工具提供圖表。

常見的系統性能指標如下。

吞吐量 ：每秒的數據量或操作量。

IOPS ：每秒的 I/O 操作數。

使用率 ：資源的繁忙程度，以百分比表示。

延時 ：操作時間，以平均數或百分數表示。

吞吐量的使用取決于上下文環境。數據庫吞吐量通常用來度量每秒查詢或請求的數目（操作量）。網絡吞吐量度量的是每秒傳輸的比特數或字節數（數據量）。IOPS 度量的是吞吐量，但只針對 I/O 操作（讀取和寫入）。再次重申，上下文很關鍵，上下文不同，定義可能會有不同。

緩存緩存被頻繁使用來提高性能。緩存是將較慢的存儲層的結果存放在較快的存儲層中。

把磁盤的塊緩存在主存（RAM）中就是一例。

一般使用的都是多級緩存。CPU 通常利用多級硬件緩存作為主緩存（L1、L2 和L3），開始是一個非常快但是很小的緩存（L1），后續的 L2 和 L3 逐漸增加了緩存容量和訪問延時。這是一個在密度和延時之間經濟上的權衡。緩存的級數和大小的選擇以CPU 芯片內可用空間為準，確保達到最優的性能。

一個了解緩存性能的重要指標是每個緩存的命中率—所需數據在緩存中被找到的次數（hits，命中）與總訪問次數（hits+misses）的比例。

命中率 = 命中次數 /（命中次數 + 失效次數）

命中率越高越好，更高的命中率意味著更多的數據能成功地從較快的介質中訪問獲得。

98% 和 99% 之間的性能差異要比 10% 和 11% 之間的性能差異大很多。由于緩存命中和失效之間的速度差異（兩個存儲層級），導致了這是一條非線性曲線。兩個存儲層級速度差異越大，曲線越陡峭。

已知的未知已知的已知、已知的未知、未知的未知在性能領域是很重要的概念。下面是詳細的解釋，并提供了系統性能分析的例子。

已知的已知 ：有些東西你知道。你知道你應該檢查性能指標，你也知道它的當前值。舉個例子，你知道你應該檢查 CPU 使用率，而且你也知道當前均值是10%。

已知的未知 ：有些東西你知道你不知道。你知道你可以檢查一個指標或者判斷一個子系統是否存在，但是你還沒去做。舉個例子，你知道你能用剖析檢查是什么致使 CPU 忙碌，但你還沒去做這件事。

未知的未知 ：有些東西你不知道你不知道。舉個例子，你可能不知道設備中斷可以消耗大量 CPU 資源，因此你對此并不做檢查。在性能領域，“你知道的越多，你不知道的也就越多”。這和學習系統是一樣的原理：你了解的越多，你就能意識到未知的未知越多，然后這些未知的未知會變成你可以去查看的已知的未知。

原文標題：Go 性能：你知道的越多，不知道的也就越多

文章出處：【微信公眾號：馬哥Linux運維】歡迎添加關注！文章轉載請注明出處。