假設平台性能基於 Nginx - ngx_http_stub_status_module
Nginx 被放置在我們沒有任何洞察力的微服務架構的前面。我們檢索由http 存根狀態公開的指標，並想計算平台性能的指標：我們不能在負載測試中使用延遲，因為我們想比較地理位置不同的站點。
到目前為止，我們嘗試了什麼：
- 計算每單位時間總請求的增量。問題：它不反映性能，所有站點處理相同的請求量（每 100 毫秒 100 個請求）
- 使用等待連接量規*
*使用此指標，我們觀察到不同的行為。兩個極端是：
2012伺服器（E5-2620 v1，24執行緒）：平均每100ms有68,62個等待連接
2021 伺服器（AMD EPYC 7642，96 執行緒）：平均每 100 毫秒 91,96 個等待連接
第一個問題。似乎應該將儀表讀取為“越高越好”。為什麼？該文件沒有提供詳細資訊，但據我們所知，此處應出現等待答案的連接。或者這個量表是否僅由空閒連接組成（即已經服務的連接）？
第二個問題。在相同的負載測試中，最新伺服器上接受/處理的連接指標要高得多（大約兩倍）。為什麼？兩者都服務於由 100 個連接池發送的相同數量的請求。我們看到的是，處理的連接數量在開始時進展非常迅速，根據架構達到不同的上限，之後進展非常線性。我們無法在此圖上找到對此行為的任何解釋：已處理連接圖
我們不能在負載測試中使用延遲，因為我們想比較地理位置不同的站點。
真的嗎？請求的響應時間是一個指標，它實際上對應於事物對使用者來說有多慢。當然，不同的地理區域可能會導致更複雜的統計分佈，但它仍然有助於分析。
$$ Waiting connections $$儀表應理解為“越高越好”。為什麼？
讀寫活動連接在做 I/O，做工作。等待是保持活動狀態，等待客戶端，在他們已經完成請求之後。
在每秒相同的請求級別下，較低的讀取和寫入是好的，因為這與快速服務的連接相關。可能這意味著更多的客戶端等待，所以更高的等待數，但連接數是有限制的。
第二個問題。在相同的負載測試中，最新伺服器上接受/處理的連接指標要高得多（大約兩倍）。為什麼？
隨著時間的推移，這兩個連接的前幾秒有點異常，幾乎立即跳了起來。我不完全清楚為什麼會發生這種情況，但也許 nginx 在測試之前執行了更長的時間，所以計數器更高。
我會忽略前幾秒鐘作為熱身。並且可能隨著時間的推移繪製每秒的請求數，因為可能更容易看到應該是直線的趨勢。