作者：京東零售 張強
導讀
本文主要講解了Forcebot壓測平台之中“并發模式”與“RPS模式”兩種模式對于服務端性能名額的影響。通過“商品查詢标簽”的壓測作為具體實踐案例，簡要闡述了“并發模式”與“RPS模式”兩種模式壓測過程中TPS、TP99以及TP999差異性。希望通過本文，讀者可以對“并發模式”與“RPS模式”兩種模式相關概念有更清晰的認識，并且能夠将它們應用到具體的業務場景之中，幫助大家在實際代碼研發、壓測的時候，提供一些參考思路。
1、背景
網際網路的頭部公司，對于接口服務性能要求非常高，各個應用鍊路之間接口要求TP99響應時間在100ms以下，甚至還有要求TP999。為了達到此目标需要不斷的優化接口邏輯性能和伺服器性能。基于此前提之下，最近開發了一個“商品查詢标簽”傑夫接口（RPC），外部門要求單機200QPS、TP999響應時間要小于40ms。我們在整個壓測過程中采用了“并發模式”與“RPS模式”兩種模式，但是它們給出的展現效果有一定差異性。其中“并發模式”适用于摸底業務系統各節點能同時承載的線上使用者數，“RPC模式”适用于衡量系統的吞吐能力。
2、并發模式（虛拟使用者模式）
“并發”是指虛拟并發使用者數，從業務角度，也可以了解為同時線上的使用者數。 适用場景：如果需要從用戶端的角度出發，摸底業務系統各節點能同時承載的線上使用者數，可以使用該模式設定目标并發。以下是通過并發模式（虛拟使用者模式）簡單的請求流程圖：
綜上所述：
1）發壓機按照設定的并發數，持續向目标服務端發起請求，經過網絡傳輸和傑夫線程池後，到達具體的方法内部執行邏輯。
2）壓力機監控的性能名額（TP99、TP999）的總時長為網絡傳輸耗時、傑夫線程等待耗時和方法耗時三者相加。
3）壓力機監控的TPS名額為機關時間内持續發出的請求總和。
實踐案例：
• forcebot監控（并發使用者數:1；TPS平均:330；TP99:4ms；TP999:5ms）
•umpkey監控（QPS:300；TP99:1ms；TP999:1ms）
3、RPS模式
RPS（Requests Per Second）是指每秒請求數。 适用場景：RPS模式即“吞吐量模式”，通過設定每秒發出的請求數，從服務端的角度出發，直接衡量系統的吞吐能力，免去并發到RPS的繁瑣轉化一步到位。以下是通過RPS簡單的請求流程圖：
•綜上所述：
1）發壓機按照設定的并發數，同時向目标服務端發起請求，經過網絡傳輸和傑夫線程池後，到達具體的方法内部執行邏輯。
2）壓力機監控的性能名額（TP99、TP999）的總時長為網絡傳輸耗時、傑夫線程等待耗時和方法耗時三者相加。
3）壓力機監控的TPS名額為機關内一次性發出的請求數量。
•實踐案例：
•forcebot監控（并發使用者數:50；TPS平均:47；TP99:6ms；TP999:60ms）
•umpkey監控（QPS:50；TP99:1ms；TP999:1ms）
4、總結
經過“并發模式”與“RPS模式”兩種模式實踐應用資料的對比，總結出以下經驗可以供大家參考。希望此文對大家後續做服務接口性能壓測有一定的幫助和啟發。
1）“并發模式”并發使用者數少于“RPS模式”并發使用者數，但是forcebot壓測事務對應TPS(最大/平均)的數量前者大于後者以及服務端UMP監控到QPS也是前者大于後者。
具體原因：“并發模式”是按照預先設定并發使用者數持續不斷的發送請求，是以在秒級收到的請求數量總和為QPS。然而“RPS模式”是按照預先設定并發使用者數同時一次性将請求發出，并且秒級時間範圍内不持續。是以它的秒級QPS隻是這一次送出請求數量。
2）“并發模式”的并發使用者數少于“RPS模式”的并發使用者數并且服務端收到QPS前者大于後者的前提之下，forcebot壓測事務對應TP99/TP999的性能名額前者優于後者。
具體原因：“并發模式”的并發使用者數少于“RPS模式”的并發使用者數，同時能夠到達傑夫線程池的任務數前者少于後者，是以傑夫線程池任務緩沖區處于等待的任務就相對較少、等待時間較短。最終計算TP99/TP999性能的時候，“并發模式”的性能更優于“RPS模式”的性能。
3）“并發模式”和“RPS模式”方法内部UMP監控的時候，可用率、TP99和TP999等性能名額都遠遠優于forcebot壓測事務監控名額。
具體原因：壓測請求傳輸過程中，會經過跨網絡傳輸、傑夫線程池等重要節點，這兩個節點的耗時對于forcebot壓測事務監控名額也有非常大的影響。例如：服務端的young gc或full gc等都會影響到傑夫線程的暫停，導緻最終forcebot壓測事務監控名額遠遠高于實際方法内部UMP監控到的值。