基礎概念的交流有助于意識層面的溝通和理解保持一致。 **資源(resource)**：物理服務器的功能組件，一些軟件資源也可以被衡量，比如線程池、進程數等。系統的運行，需要各種資源，對于資源列表的確定，我們可以憑借對系統的了解確定，也可以通過繪制系統的功能塊圖的方式確定要衡量的資源。 常見的物理資源如下， CPU（cpu sockets）、CPU核（cores）、硬件線程（虛擬線程）hardware threads( virtual threads)、內存、網絡接口、存儲設備、存儲或者網絡的控制器、內部高速互聯 **負載(load)**：有多少任務正在施加給系統，也就是系統的輸入，要被處理的請求。對于數據庫，那么負荷就包括了客戶端段發送過來的命令和查詢。 負載如果超過了設計能力，往往導致性能問題。應用程序可能因為軟件應用的配置或者系統架構導致性能降低，比如，如果一個應用程序是單線程的，無疑它會受制于單線程架構，因為只能利用一個核，后續的請求都必須排隊，不能利用其他核，但也可能僅僅是因為負載太多了。負載太多將導致排隊、高延時，比如，一個多線程應用程序，你發現所有cpu都是忙的，都在處理任務，這個時候，仍然發生排隊，系統負載很高，這個時候很可能是施加了過高的負荷。 如果在云中，你也許可以簡單地增加更多的節點來處理過高的負荷，在一般的生產應用中，簡單增加節點有時解決不了問題，你需要進行調優和架構迭代。 **利用率(ulilization)**：利用率用來衡量提供服務的資源的忙碌程度，它基于某一段時間間隔內，系統資源用于真正執行工作的時間百分比。即， > 利用率 = 忙的時間 / 總計時間 利用率可以是基于時間的，比如cpu的利用率：某顆cpu的利用率或者整體系統的cpu利用率。比如磁盤的利用率，我們可使用iostat命令檢查%util。 利用率也可以是基于容量的，它可以表示我們的磁盤或者內存或者網絡的使用程度，比如90%的磁盤空間被使用，80%的內存被使用，80%的網絡帶寬被使用。 可以用高速公路的收費站的例子來類比： 利用率表現為當前有多少收費亭正在忙于服務。利用率100%，就表示所有收費亭都正在處理收費，找不到空閑的收費亭，就必須排隊。在高峰時刻，可能許多時候收費亭都是100%的利用率，但如果給出全天的利用率數據，也許只有40%，如果只關注全天的利用率數據就會掩蓋了高峰時段的利用率的一些問題。 往往利用率的高位意味著資源飽和。利用率100%往往意味著有瓶頸，檢查飽和度、系統性能可以確定。該資源不能提供服務的程度被標識為它的飽和度，見下面飽和的詳細解釋。 利用率超過60%也可能有問題，如果是檢測的結果百分比數值比較大，很可能掩蓋了偶爾的100%的峰值，意味著一些資源，如磁盤，在60%的利用率的時候，就開始性能變差了。 **響應時間(response time)**：也叫延遲，指操作執行需要的耗時。它包括了等待時間和執行時間。對于一個數據庫查詢，那么響應時間包括了從客戶端發布查詢命令到數據庫處理查詢，傳輸結果給客戶端的所有時間。延遲可以在不同的環節衡量，比如訪問站點的裝載時間包括DNS延遲、tcp連接延遲、tcp數據傳輸時間。延遲也可以在更高的級別理解，包括數據傳輸時間和其他時間，比如從用戶點擊鏈接到網頁內容傳輸，并在用戶的電腦屏幕上渲染完畢，這也是一種延遲。延遲是以時間做量度來衡量的，可以很方便地進行比較，其他的一些指標不容易衡量、比較，比如IOPS，那么，你可以轉化為延遲來進行比較。 **伸縮性(scalability)**：可以理解為兩個層面的意思。 一、在資源的利用率不斷增加的情況下，響應時間和資源利用率之間的關系，資源利用率越高，響應時間仍然能保持穩定，那么我們說他的伸縮性好，但如果資源利用率高，響應時間開始劣化，我們認為其伸縮性不佳。 二、伸縮性還有一層意義，表征系統不斷擴展的能力，系統通過不斷增加節點或者資源，處理不斷增長的負荷，同時依然能夠保持合理的響應時間。 **吞吐(throughput)**：處理任務的速率。對于網絡傳輸，吞吐一般指每秒傳輸的字節數，對于數據庫來說，指的是每秒查詢數（QPS）或者每秒事務數。 **并發(concurrency)**：指得是系統能夠并行執行多個操作的能力。如果數據庫能夠充分利用CPU的多核能力，那么往往意味著更高的并發處理能力。 **容量(capacity)**：容量指的是系統可以提供的處理負荷的能力。我們日常運維中有一項很重要的工作就是容量規劃，即確保隨著負荷增長，我們的系統仍然能夠處理負荷，也就是說，當我們的吞吐增加后，我們仍然能夠確保服務良好、穩定。容量也指我們的資源使用極限，比如我們的磁盤空間占用，在磁盤空間到達一定閥值后，我們可能要考慮擴容。 熟悉以上概念，并且了解他們之間的關系，一般來說，隨著負荷上升，吞吐率將上升，吞吐曲線會一直是線性的，我們的系統的響應時間開始一個階段會保持穩定，但是到達某個點后，性能開始變差，響應時間變得更長，以后隨著負荷繼續增加，此時我們的吞吐將不能再繼續增長，甚至下降，而響應時間可能變得不可接受。 有一種例外情況是，應用服務器返回錯誤狀態碼，比如web服務器返回503錯誤，由于基本不消耗資源，難以到達極限，所以返回錯誤碼的的吞吐曲線還會繼續保持線性。