本頁面中的部分或全部資訊可能不適用於 Trusted Cloud by S3NS。

本頁面由 Cloud Translation API 翻譯而成。

使用應用程式負載平衡器負載測試後端服務的規範

在將後端服務與應用程式負載平衡器整合時，請務必在沒有負載平衡器的情況下，自行評估後端服務的成效。在受控條件下進行負載測試，有助於評估不同效能維度 (例如吞吐量和延遲) 之間的容量規劃取捨。由於容量規劃可能仍會低估實際需求，因此建議您使用工作負載測試，主動判斷系統超載時，服務的可用性會受到什麼影響。

負載測試目標

一般負載測試會在不同負載維度下，評估後端服務的外部可見行為。這項測試最相關的維度如下：

要求傳輸量：每秒處理的要求數量。
要求並行：同時處理的要求數量。
連線吞吐量：用戶端每秒啟動的連線數。大多數使用傳輸層安全標準 (TLS) 的服務，都會在每個與要求處理無關的連線中，產生一些網路傳輸和 TLS 協商處理開銷。
連線並行處理：同時處理的用戶端連線數量。

注意： 這個數字可能低於要求並行作業，因為 HTTPS 用戶端經常重複使用多個要求的連線。請注意，即使連線未提供要求，也會耗用系統資源 (例如 RAM 和檔案句柄)。
要求延遲時間：從要求開始到回應結束之間的總時間長度。
錯誤率：要求導致錯誤的頻率，例如 HTTP 5xx 錯誤和提早關閉的連線。

為評估伺服器在負載下的健康狀況，負載測試程序也可能會收集下列內部服務指標：

系統資源使用情形：系統資源 (例如 CPU、RAM 和檔案句柄 (Socket)) 通常以百分比表示。

這些指標的重要性會因服務的導入方式而異。應用程式耗盡資源時，會發生效能降低、負載減少或當機的情形。因此，在主機負載過重時，判斷資源可用性就變得十分重要。
使用其他受限資源：在負載下可能耗盡的非系統資源，例如應用程式層。

以下是這類資源的範例：
- 工作站執行緒或程序的受限集區。
- 對於使用執行緒的應用程式伺服器，通常會限制同時運作的工作執行緒數量。執行緒集區大小限制可用於防止記憶體和 CPU 耗盡，但預設設定通常非常保守。限制值過低可能會導致系統資源無法充分使用。
- 部分伺服器會使用程序集區，而非執行緒集區。舉例來說，如果 Apache 伺服器設定為使用預先分支多重處理模式，就會為每個用戶端連線指派一個程序。因此，資源池的大小限制會決定連線並行處理的上限。
- 以前端形式部署的服務，該服務的後端連線集區大小受限。

容量規劃與超載測試

負載測試工具可協助您個別評估不同的縮放維度。在容量規劃方面，請根據多個維度判斷可接受的效能負載門檻。舉例來說，請不要測量服務要求的絕對限制，而是考慮測量下列項目：

服務可提供的請求率，其中 99 百分位數延遲時間小於指定的毫秒數。這個數字由服務的服務等級目標指定。
不會導致系統資源使用率超出最佳水準的最大要求速率。請注意，最佳使用率會因應用程式而異，且可能遠低於 100%。舉例來說，如果記憶體尖峰使用率為 80%，應用程式可能比尖峰使用率為 99% 時更能處理小型負載尖峰。

雖然使用負載測試結果來制定容量規劃決策很重要，但瞭解負載超出容量時服務的行為也很重要。以下是一些經常使用超載測試評估的伺服器行為：

負載分散：當服務收到過多傳入要求或連線時，可能會以減緩所有要求的速度或拒絕部分要求來回應，以便維持其餘要求的可接受效能。我們建議採用後者，以免在收到回應前發生用戶端逾時，並降低伺服器上的請求並行處理作業，進而降低記憶體耗盡的風險。
資源耗盡時的復原能力：服務通常會避免因資源耗盡而當機，因為如果服務當機，待處理的要求很難繼續處理。如果後端服務有多個執行個體，個別執行個體的穩健性對於服務的整體可用性至關重要。當執行個體因當機而重新啟動時，其他執行個體可能會承受更多負載，進而導致連鎖故障。

一般測試規範

定義測試案例時，請考量下列指南。

建立小規模測試

建立小規模測試，評估伺服器的效能極限。若伺服器容量過多，測試可能無法顯示服務本身的效能限制，但可能會揭露其他系統 (例如用戶端主機或網路層) 的瓶頸。

為獲得最佳結果，建議您使用單一虛擬機器 (VM) 執行個體或 Google Kubernetes Engine (GKE) Pod 的測試案例，獨立測試服務。如有需要，您可以使用多個 VM 來達成伺服器的完整負載，但請注意，這可能會使效能資料收集作業變得複雜。

選擇開放迴路負載模式

大多數負載產生器都會使用封閉迴圈模式，限制並延遲並行要求的數量，直到先前的請求完成為止。我們不建議使用這種做法，因為服務的實際工作環境用戶端可能不會出現這種節流行為。

相反地，開放迴路模式可讓負載產生器以穩定的速率傳送要求，模擬實際負載，不受伺服器回應傳送速率影響。

使用建議的負載產生器執行測試

我們建議您使用下列負載產生器，為後端服務進行負載測試：

Nighthawk

Nighthawk 是與 Envoy 專案協同開發的開放原始碼工具。您可以使用這項工具產生用戶端負載、以視覺化方式呈現基準測試，以及評估 HTTPS 服務的大多數負載測試情境中的伺服器效能。

測試 HTTP/1

如要測試 HTTP/1，請使用下列指令：

nighthawk_client URI \
    --duration DURATION \
    --open-loop \
    --no-default-failure-predicates \
    --protocol http1 \
    --request-body-size REQ_BODY_SIZE \
    --concurrency CONCURRENCY \
    --rps RPS \
    --connections CONNECTIONS

更改下列內容：

URI：要基準測試的 URI
DURATION：總測試執行時間 (以秒為單位)
REQ_BODY_SIZE：每項要求中的 POST 酬載大小
CONCURRENCY：並行事件迴圈的總數

這個數字應與用戶端 VM 的核心數量相符
RPS：每個事件迴圈的每秒要求目標速率
CONNECTIONS：每個事件迴圈的並行連線數量

請參閱以下範例：

nighthawk_client http://10.20.30.40:80 \
    --duration 600 --open-loop --no-default-failure-predicates \
    --protocol http1 --request-body-size 5000 \
    --concurrency 16 --rps 500 --connections 200

每個測試執行作業的輸出內容會提供回應延遲時間的直方圖。在 Nighthawk 說明文件中的範例中，第 99 百分位數的延遲時間約為 135 微秒。

Initiation to completion
    samples: 9992
    mean:    0s 000ms 113us
    pstdev:  0s 000ms 061us

    Percentile  Count       Latency
    0           1           0s 000ms 077us
    0.5         4996        0s 000ms 115us
    0.75        7495        0s 000ms 118us
    0.8         7998        0s 000ms 118us
    0.9         8993        0s 000ms 121us
    0.95        9493        0s 000ms 124us
    0.990625    9899        0s 000ms 135us
    0.999023    9983        0s 000ms 588us
    1           9992        0s 004ms 090us

測試 HTTP/2

如要測試 HTTP/2，請使用下列指令：

nighthawk_client URI \
    --duration DURATION \
    --open-loop \
    --no-default-failure-predicates \
    --protocol http2 \
    --request-body-size REQ_BODY_SIZE \
    --concurrency CONCURRENCY \
    --rps RPS \
    --max-active-requests MAX_ACTIVE_REQUESTS \
    --max-concurrent-streams MAX_CONCURRENT_STREAMS

更改下列內容：

URI：要基準測試的 URI
DURATION：總測試執行時間 (以秒為單位)
REQ_BODY_SIZE：每項要求中的 POST 酬載大小
CONCURRENCY：並行事件迴圈的總數

這個數字應與用戶端 VM 的核心數量相符
RPS：每個事件迴圈的每秒要求次數目標速率
MAX_ACTIVE_REQUESTS：每個事件迴圈的並行有效要求數量上限
MAX_CONCURRENT_STREAMS：每個 HTTP/2 連線允許的並行串流數量上限

請參閱以下範例：

nighthawk_client http://10.20.30.40:80 \
    --duration 600 --open-loop --no-default-failure-predicates \
    --protocol http2 --request-body-size 5000 \
    --concurrency 16 --rps 500 \
    --max-active-requests 200 --max-concurrent-streams 1

ab (Apache 基準工具)

ab 是 Nighthawk 的替代方案，靈活度較低，但幾乎所有 Linux 發行版本都提供此套件。ab 僅適用於快速簡單的測試。

如要安裝 ab，請使用下列指令：

在 Debian 和 Ubuntu 上，執行 sudo apt-get install apache2-utils。
在 RedHat 架構的發行版本上執行 sudo yum install httpd-utils。

安裝 ab 後，請使用下列指令執行它：

ab -c CONCURRENCY \
    -n NUM_REQUESTS \
    -t TIMELIMIT \
    -p POST_FILE URI

更改下列內容：

CONCURRENCY：要執行的並行要求數量
NUM_REQUESTS：要執行的要求數量
TIMELIMIT：要求的最大秒數
POST_FILE：包含 HTTP POST 酬載的本機檔案
URI：要基準測試的 URI

請參閱以下範例：

ab -c 200 -n 1000000 -t 600 -p body http://10.20.30.40:80

上述範例中的指令會以 200 個並行數量 (封閉迴路模式) 傳送要求，並在傳送 1,000,000 (一百萬) 個要求或經過 600 秒後停止。這個指令也包含檔案 body 的內容，做為 HTTP POST 酬載。

ab 指令會產生與 Nighthawk 類似的回應延遲時間直方圖，但其解析度僅限於毫秒，而非微秒：

Percentage of the requests served within a certain time (ms)
    50%     7
    66%     7
    75%     7
    80%     7
    90%    92
    95%   121
    98%   123
    99%   127
    100%  156 (longest request)

後續步驟

利用負載平衡進行容量管理