SAE支持通過PTS工具進行性能壓測，以便系統性地模擬真實場景下的高并發請求，從而有效地評估應用在不同負載條件下的性能表現。本文介紹單實例并發請求數與QPS的關系、如何根據業務場景選擇規格配置以及PTS壓測配置。
術語定義
單實例并發請求數上限：配置SAE每個實例可同時執行的請求數上限。如果初次評估，建議使用壓測工具PTS或者JMeter壓測摸底極限值。默認情況下，每個實例可以同時接收10個請求，您最多可以將單實例并發請求數上限設置為1000。
下圖展示了單實例的并發請求數上限與應對并發請求所需實例數量的關系。
QPS（Queries Per Second）：每秒向服務器發送的請求數量峰值，即每個API每秒可以允許請求的并發上限數。當用戶在SAE上部署應用對外提供服務時，QPS可用來衡量該應用每秒能夠響應和處理的客戶端請求數量，包括但不限于HTTP請求、數據庫查詢或其他類型的API調用。
RT（Response Time）：響應時間，指的是業務從客戶端發起到客戶端接收的時間。
單實例并發請求數和QPS換算
請求的端到端耗時=請求執行時長+請求端到端的延遲，單位：秒。單實例能承受的QPS：
QPS=（1/請求的端到端耗時）×單實例并發請求數，請求的端到端耗時單位：秒。單個應用能承受的QPS：
QPS=（1/請求的端到端耗時）×單實例并發請求數×最大實例個數，請求的端到端耗時單位：秒。
舉例說明：假如一個應用請求的端到端耗時為0.1s，單個實例并發請求數為2，最大實例個數為6，那么這個單實例能承受的QPS為（1/0.1）×2=20，單個應用能承受的QPS為（1/0.1）×2×6=120。
規格選擇
如何根據實際業務場景進行調優單實例并發請求數和規格？
SAE提供了多種實例規格，每種規格的CPU、內存配置以及可處理的并發能力都不同。因此，在選擇最適合的規格配置時，需要結合業務運行邏輯與詳盡的性能壓測結果進行綜合評估。對于配置單實例并發請求數，只對總時長計費，能夠降低成本，但是過高的單實例并發請求數會導致實例性能惡化，從而導致延時增大。因此，根據壓測基線數據進行分析，可以得到單實例性能惡化的轉折點（即拐點），選取拐點附近的并發度值，可以作為單實例性能與成本平衡的最佳并發度參考值。
綜上所述，在進行壓測后得到的最大并發數位置，可以作為推薦的并發請求數量配置標準，以確保系統高效穩定運行。
通過壓測獲得的并發請求數閾值數據，可以作為業務首次上線的初始值，但需注意，這個數值不能直接等同于線上環境的理想配置標準。
使用PTS進行性能壓測
登錄PTS控制臺。
在左側導航欄選擇，然后單擊PTS壓測，創建PTS壓測場景，填寫壓測場景名。
在場景配置頁簽中，填寫被壓測業務的API名稱，然后單擊GET，填寫壓測URL。
說明壓測URL可以是公網訪問地址，也可以是自定義域名。
如果使用公網訪問地址進行壓測，公網訪問IP白名單不為空，會導致PTS壓測機無法訪問應用公網地址，建議臨時刪除白名單。
單擊調試API。
登錄SAE控制臺，在目標實例的版本列表頁面，單擊新建版本，在新建版本面板的容量設置區域，將應用的單實例并發請求數/秒，設置為最大值1000。
在PTS控制臺施壓配置頁簽中，壓力來源選擇公網，壓力模式選擇并發模式（虛擬用戶模式），遞增模式選擇自動遞增，最大并發填寫1000，遞增百分比填寫10%，單量級持續時長設置為1分鐘，壓測總時長設置為11分鐘。
在量級及數據配置區域，串聯鏈路的最大并發權重設置為100，起始百分比設置為1%，然后單擊保存去壓測。
在左側導航欄選擇，在目標壓測報告操作列單擊查看報告，在報告詳情頁面查看壓測數據。
分析數據后，可以發現在并發度80左右的時候，RT開始出現拐點，即再增加并發度后實例的性能會惡化。因此建議將性能基準并發數設置在70~80左右，此時的基準單實例QPS為1600左右。如果需要對更細粒度的并發請求數下的實例性能進行測試，可以將遞增模式設置為手動調速，以便在壓測過程中實時進行調速。
壓測基準數據
使用性能測試 PTS（Performance Testing）工具，針對SAE單實例在不同配置規格及不同并發用戶數場景下的QPS進行了壓力測試。本次測試的地域設定為華北3（張家口），采用registry.cn-zhangjiakou.aliyuncs.com/serverless_devs/sae-demo:helloworld-f395abd5da77鏡像作為基準鏡像進行測試，該鏡像是基于Express框架構建的簡單邏輯的Node.js的Web應用，對此簡單邏輯的應用進行壓測得到不同規格的性能數據。
下表展示了不同規格配置在不同QPS下的執行時長與并發數的數據。
由于0.5 Core 1 GiB和1 Core 2 GiB的資源配置相對較小，為了更精確地捕捉其性能表現，我們選擇了更細致的QPS粒度進行探測。
在此次測試中，RT表示在SAE執行環境內部的請求響應時間，不包括客戶端到SAE的網絡延時。客戶端到SAE的延遲約為50 ms，即下列測試數據中請求的端到端耗時為
50 ms+RT。RT avg指所有請求完成所需的平均時長。
通過QPS和請求的端到端耗時計算各個規格下的實例并發數，并對其進行了取整處理。
QPS（次/秒） | 執行時長與并發數 | 0.5 Core 1 GiB | 1 Core 2 GiB |
230 | RT avg | 0.8 ms | 0.8 ms |
并發數 | 11并發 | 11并發 | |
400 | RT avg | 4 ms | 0.8 ms |
QPS | 21并發 | 20并發 | |
500 | RT avg | 34 ms | 0.8 ms |
QPS | 42并發 | 25并發 | |
650 | RT avg | 無 | 0.8 ms |
QPS | 無 | 33并發 | |
850 | RT avg | 無 | 1.6 ms |
QPS | 無 | 43并發 | |
950 | RT avg | 無 | 7 ms |
QPS | 無 | 54并發 | |
1000 | RT avg | 無 | 13 ms |
QPS | 無 | 63并發 |
QPS（次/秒） | 執行時長與并發數 | 2 Core 4 GiB | 4 Core 8 GiB | 8 Core 16 GiB | 12 Core 12 GiB | 16 Core 16 GiB |
470 | RT avg | 0.9 ms | 0.9 ms | 0.7 ms | 0.7 ms | 0.7 ms |
并發數 | 23并發 | 23并發 | 23并發 | 23并發 | 23并發 | |
880 | RT avg | 1.3 ms | 0.9 ms | 0.9 ms | 0.8 ms | 0.8 ms |
并發數 | 45并發 | 44并發 | 44并發 | 44并發 | 44并發 | |
1300 | RT avg | 1.6 ms | 1.2 ms | 1.2 ms | 1.2 ms | 1.1 ms |
并發數 | 67并發 | 66并發 | 66并發 | 66并發 | 66并發 | |
1700 | RT avg | 3.2 ms | 1.7 ms | 1.7 ms | 1.7 ms | 1.7 ms |
并發數 | 90并發 | 87并發 | 87并發 | 87并發 | 87并發 | |
2000 | RT avg | 4.2 ms | 2.4 ms | 2.5 ms | 2.4 ms | 2.3 ms |
并發數 | 108/并發 | 104并發 | 105并發 | 104并發 | 104并發 | |
2400 | RT avg | 無 | 4 ms | 3.7 ms | 3.5 ms | 3.5 ms |
并發數 | 無 | 129并發 | 128并發 | 128并發 | 128并發 | |
2600 | RT avg | 無 | 7 ms | 6 ms | 7 ms | 6 ms |
并發數 | 無 | 148并發 | 145并發 | 148并發 | 145并發 | |
2600 | RT avg | 無 | 11 ms | 11 ms | 11 ms | 10 ms |
并發數 | 無 | 158并發 | 158并發 | 158并發 | 156并發 | |
2800 | RT avg | 無 | 無 | 無 | 無 | 19 ms |
并發數 | 無 | 無 | 無 | 無 | 193并發 |
基于以上基準數據分析，可以得出如下結論：
對于2 Core 4 GiB規格的實例，當QPS從470次/秒提升至1700次/秒的過程中，平均響應時間（RT avg）出現了顯著上升的變化趨勢。當QPS增加到1700次/秒時，響應時間增長尤為明顯。隨著QPS的不斷增加，響應時間增長幅度放緩，在QPS增至2400次/秒時系統處理能力已達到極限，并呈現出明顯的性能瓶頸。通過QPS和請求的端到端耗時計算得到該實例對應的最大并發數約為90并發。
據此，我們可以合理推測，對于這個2 Core 4 GiB規格的實例而言，其能夠有效處理并發請求的最大性能上限可能是90并發。因此，為了確保服務質量和系統的性能穩定性，建議在實際業務場景中對并發用戶數加以控制，避免超過此臨界值導致系統性能急劇下滑。