這篇部落格文章的標題看起來是個顯而易見、很容易回答的問題，但其實值得我們更仔細地思考效能真正的含義：人們很容易混淆延展性與效能，而且若以資料庫系統為例，要將效能拆解為不同的主要組成部分，也並非那麼簡單。在這篇短文中，我想試著寫下我目前對於在資料庫系統的脈絡下，效能究竟是什麼的看法。

一個不錯的切入點，或許是我最近在談論 Redis 時常用到的第一張投影片。這張投影片談的正是效能，它指出效能主要包含三個不同的面向。

1. 延遲：取得一次查詢回應所需的時間。
2. 每核心每單位時間的作業數：在給定的參考運算單元下，系統每秒能夠回應多少次查詢（作業）？
3. 作業品質：這些作業能夠完成多少工作？

延遲

這大概是效能當中最單純的一個組成部分。在許多應用場景中，我們都希望從系統取得回應所需的時間越短越好。然而，除了平均時間很重要之外，另一個值得關注的重點是延遲數值的可預測性，以及平均情況與最差情況之間的差距有多大。若使用得當，記憶體內系統能夠提供非常優異的延遲特性，也能在長時間內維持穩定的延遲表現。

每核心每秒作業數

我所列舉的第二個組成部分，正是區分原始效能與延展性的關鍵。我們關心的是，在給定的參考運算單元下，系統在單位時間內能夠完成多少工作。具備線性可擴展性的系統可以透過增加節點數量來達到很高的每秒作業數，但這代表的是它具有延展性，而不一定代表它高效能。

每核心每秒作業數通常也與每瓦能夠執行的查詢數量相關，因此也關係到系統的能源效率。

作業品質

最後一點雖然在開發者之間受到的重視可能不如吞吐量與延遲，但在某些類型的系統中，特別是記憶體內系統，卻非常重要。

一個每秒能執行 100 次作業、但作業「品質不佳」的系統（以 Redis 來說，例如只有 GET 和 SET），相較於另一個在相同延遲與每秒作業數特性下，還能執行 INCR 這類操作的系統，其效能是比較低的。舉例來說，如果當前的問題是要遞增計數器，前者會需要兩次作業才能完成一次遞增（在此我們先不考慮競爭條件），而提供 INCR 的系統只需要一次作業就能完成。因此，後者實際上能夠提供前者兩倍的效能。

由此可見，作業品質並不是一個絕對的衡量標準，而是取決於要解決的問題類型。同樣的兩個系統，如果目的是要快取 HTML 片段，那麼兩者的表現是等價的，因為 INCR 操作在這種情況下毫無用處。

作業品質在記憶體內系統中尤其重要，因為通常運算本身所需的時間，相較於接收、分派指令與產生回應所需的時間，幾乎可以忽略不計，因此像 Redis 這樣具備豐富操作指令的系統，能夠在許多場景下幾乎不增加額外成本就提供更好的效能，僅僅是讓使用者透過單一操作就能完成更多工作。這個「做更多」可以有很多種含意：可能是針對更複雜的問題提供回應，例如 Redis 的 ZRANK 指令，也可能只是能夠提供更具選擇性的回應，例如 HMGET 指令，它能夠只針對構成 Hash 值的其中一部分欄位提供資訊，從而減少伺服器與客戶端之間所需的頻寬。

一般來說，作業品質不僅會影響效能表現，因為它讓系統每秒所能執行的作業數具有或多或少的價值：作業品質也會直接影響延遲，因為較複雜的操作能夠避免為了將多個簡單操作組合成更複雜的運算，而需要在客戶端與伺服器之間來回傳輸資料。

結論

希望這篇關於效能是什麼的簡短探討，能揭示從這個特定角度評估資料庫系統能力時所涉及的一些複雜性。關於這個主題還有很多可以討論的地方，但我認為上述效能的三個組成部分，是在評估一套系統，以及在思考如何演進現有系統以改善其效能特性時，最有趣也最重要的幾個面向。

感謝 Yiftach Shoolman 針對這個主題提供的回饋。