許多人沒有理解透徹的一些基礎概念

基礎概念的交流和理解一致，才有助於意識的溝通一致。才有助於意識層面的交流。

資源(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錯誤，由於基本不消耗資源，難以到達極限，所以返回錯誤碼的的吞吐曲線會保持線性。