PolarDB Serverless是基於SIGMOD 2021論文中所提出的成熟技術最終產品化的結果。藉助於全域一致性（高效能模式）和無感秒切兩項核心技術，其在跨機擴充和跨機切換能力方面均達到了較高的水平。本文將使用Sysbench工具對PolarDB Serverless的彈效能力進行測試。您可以按照本文所述的方法自行進行測試，從而快速瞭解Serverless的彈效能力。
測試組態
ECS執行個體和PolarDB MySQL版叢集位於同一地區，同一Virtual Private Cloud內。
PolarDB MySQL版叢集配置如下：
叢集個數：1個
計費類型：Serverless
資料庫引擎：MySQL 8.0.1
產品版本：企業版
儲存類型：PSL5
說明在購買Serverless叢集時，規格及代理中的唯讀節點個數的伸縮上下限以及單節點的伸縮上下限保持預設設定即可。更多購買操作說明，請參見建立Serverless叢集。
ECS執行個體配置如下：
執行個體個數：1台
執行個體規格：ecs.g7.4xlarge（16 vCPU 64 GiB）
鏡像：Alibaba Cloud Linux 3.2104 LTS 64位
系統硬碟：ESSD雲端硬碟，效能PL0，容量100 GB
測試載入器
Sysbench是一款開源的、跨平台的效能基準測試載入器，主要用於評估資料庫（例如MySQL）的效能。該工具支援多線程測試，並提供靈活的配置選項。
準備工作
購買環境
根據測試組態，購買ECS執行個體以及PolarDB MySQL版 Serverless叢集。
安裝Sysbench工具
使用root帳號登入ECS執行個體，安裝Sysbench工具。
sudo yum -y install sysbench此處以Alibaba Cloud Linux系統為例。若您安裝的是其他動作系統，需調整相應的安裝命令，詳情請參見Sysbench官方文檔。
配置叢集資訊
前往PolarDB控制台，建立資料庫、建立資料庫帳號以及擷取串連地址和連接埠。
若ECS執行個體與PolarDB MySQL版叢集處於同一Virtual Private Cloud內，則無需進行叢集白名單的配置。建立叢集後，系統會預設將叢集所在的VPC網段添加至default分組。
若ECS執行個體與PolarDB MySQL版叢集未處於同一Virtual Private Cloud內，您可以選擇將ECS的公網IP地址添加至新的IP白名單分組，或將ECS所在的安全性群組添加至叢集白名單中。
串連地址請使用叢集地址，而非主地址。
資料準備
使用Sysbench工具在PolarDB MySQL版叢集中準備128張表，每張表包含1,000,000行資料。執行過程中，可能會導致Serverless叢集規格的自動彈升。請在資料準備完成後，耐心等待3至5分鐘，直至主節點的規格降回1 PCU。資料準備命令如下，請根據實際情況調整以下參數：
Serverless叢集參數：
<host>：叢集地址。<port>：叢集地址所對應的連接埠號碼，預設3306。<user>：資料庫帳號。<password>：資料庫帳號對應的密碼。<database>：資料庫名稱。
其他參數：
--db-ps-mode：disable代表禁用先行編譯語句（Prepared Statements），以確保所有的事務SQL以原始SQL語句的方式執行。--threads：線程數。不同的線程數可以構造不同的負載。此處以32為例，表示在資料準備過程中使用32個線程，預計期間為5分鐘。
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=<host> --mysql-port=<port> --mysql-user=<user> --mysql-password=<password> --mysql-db=<database> --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=32 --time=12000 prepare單節點縱向擴縮測試（Scale-up）
通過Sysbench工具驗證主節點的規格能夠根據負載自動進行伸縮。
調整Serverless配置
在驗證單節點的擴縮測試過程中，需要確保壓力測試期間不會有隻讀節點彈升出來。請前往PolarDB控制台，在叢集詳情頁面的資料庫節點地區調整Serverless配置，將單節點資源彈升上限設定為32，單節點資源彈升下限設定為1，唯讀節點個數伸縮上下限設定為0。
初步驗證：低負載（16線程）
首先，進行一次簡單測試，評估16個線程的測試效果，從而對Serverless的彈效能力進行初步瞭解。
執行以下壓測命令。將
--threads參數設定為16，其他參數請依據實際情況進行調整。具體資訊，請參見參數說明。sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=<host> --mysql-port=<port> --mysql-user=<user> --mysql-password=<password> --mysql-db=<database> --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=16 --time=12000 run壓測結果如下。根據執行結果分析，在並發數量固定為16的負載條件下，隨著時間的推移，輸送量TPS逐步增加，而延遲LAT逐步降低，最終達到了一個穩定值。這表明在觸發Serverless彈性後，系統效能得到了明顯提升。
返回PolarDB控制台，在效能監控頁面查看Serverless監控指標項。時間範圍選擇最近的5分鐘，可以看到如下監控資訊：
PCU數量由1彈升至7並保持穩定。在彈升過程中，CPU的使用率隨著資源的擴容而逐步降低。記憶體使用量率曲線在每次彈升時呈現脈衝形狀。這是由於每次PCU增加時，記憶體資源會進行擴容，此時的記憶體使用量率會瞬時下降。隨後，資料庫開始利用擴充的記憶體資源提升計算能力（例如Buffer Pool），因此記憶體使用量率會逐步增加，最終達到一個穩定點。
停止壓測命令，稍等5分鐘。隨後，調整時間範圍至最近的10分鐘，可以查看到以下監控資訊：
隨著壓力的停止，PCU數量從7逐步階梯式地降低至1。CPU使用率瞬間降至接近0。由於讀寫混合測試中包含
UPDATE請求，當壓力停止後，PolarDB仍會繼續執行purge undo操作，因此會佔用微量的CPU資源。接下來觀察記憶體使用量率，在每次縮容時，記憶體使用量率會立即降低，隨後再升高一個台階。這是由於PolarDB在縮容之前，會首先調整記憶體相關參數（如Buffer Pool、Table Open Cache等）以觸發緩衝回收，因此使用率會立刻降低。在參數調整完成後，只有在確保記憶體資源已被釋放的情況下，才會真正縮小容器的Mem規格。當Mem上限調小後，相當於分母變小，因此計算得出的記憶體使用量率將會上升。
深入驗證：高負載（128線程）
接下來，將線程數（--threads參數）設定為128，查看PolarDB Serverless叢集彈升至最大規格32 PCU所需的時間。在進行壓測一段時間後，停止測試。
執行以下壓測命令。將
--threads參數設定為128，其他參數請依據實際情況進行調整。具體資訊，請參見參數說明。sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=<host> --mysql-port=<port> --mysql-user=<user> --mysql-password=<password> --mysql-db=<database> --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=128 --time=12000 run壓測結果：根據執行結果，可以明顯看出來輸送量TPS和延遲LAT的變化。
前往PolarDB控制台，在效能監控頁面查看Serverless監控指標項。根據測試時間調整時間範圍，可以看到如下監控資訊：
從1 PCU彈升至32 PCU耗時大約需要23秒。縮容相比擴容稍顯平緩，耗時大約233秒。
多節點橫向擴縮測試（Scale-out）
傳統的MySQL主備一寫多讀叢集的唯讀節點面臨Binlog複寫延遲問題，通常不支援轉寄TP業務的讀操作，僅服務於對全域一致性不敏感的報表等業務。此外，由於Binlog複製僅同步已提交事務的日誌，這導致唯讀節點無法處理事務中的寫後讀。
PolarDB Serverless藉助於全域一致性（高效能模式），簡稱SCC，能夠實現跨節點的無損讀擴充。Serverless叢集會在所有彈出唯讀節點上預設啟用SCC。SCC加上Proxy的進階事務拆分技術，使得跨事務、事務前和事務中的寫後讀請求都可以輕鬆擴充到叢集的唯讀節點，並保證全域一致性。最終，主節點省下來的資源就可以支援更多的寫請求。使用唯一的叢集地址訪問Serverless叢集，您不會受到跨節點的讀一致性的問題困擾，即您無需關心請求是由主節點直接執行，還是被轉寄到唯讀節點執行。
調整Serverless配置
在驗證多節點的擴縮測試過程中，需要確保壓力測試期間會有隻讀節點自動彈升出來。請前往PolarDB控制台，在叢集詳情頁面的資料庫節點地區調整Serverless配置。將單節點資源彈升上限設定為32，單節點資源彈升下限設定為1，唯讀節點個數伸縮上限設定為7，唯讀節點個數伸縮下限設定為0。
初步驗證：低負載（128線程）
首先，進行一次128個線程的測試，初步瞭解一下Serverless的橫向擴縮彈效能力。
執行以下壓測命令。將
--threads參數設定為128，其他參數請依據實際情況進行調整。具體資訊，請參見參數說明。說明壓測前，請確保主節點在先前測試結束後已降至1 PCU。
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=<host> --mysql-port=<port> --mysql-user=<user> --mysql-password=<password> --mysql-db=<database> --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=128 --time=12000 run前往PolarDB控制台，在基本資料頁面的資料庫節點地區，可以看到，在壓力執行一段時間後，系統開始自動建立唯讀節點。
一段時間後進入穩定點，系統不再繼續建立唯讀節點。
進入穩定點後，壓測結果如下。與之前單節點同壓力的測試結果相比，效能有所提升，QPS從17萬～19萬上升到23萬～25萬。根據QPS的表現，已突破單節點彈性測試的最大輸送量。
返回PolarDB控制台，在效能監控頁面查看Serverless監控指標項。根據測試時間調整時間範圍，可以看到如下監控資訊：
主節點很快提升至32 PCU，建立的唯讀節點開始承擔部分讀負載，從而使主節點的CPU使用率下降。由於彈出的唯讀節點的CPU使用率未超過彈性閾值80%（預設配置），因此在該壓力下僅會擴容一個唯讀節點。
深入驗證：高負載（256線程）
接下來，停止當前的壓測，並將線程數提升至2倍，即將線程數（--threads參數）設定為256。
執行以下壓測命令。將
--threads參數設定為256，其他參數請依據實際情況進行調整。具體資訊，請參見參數說明。sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=<host> --mysql-port=<port> --mysql-user=<user> --mysql-password=<password> --mysql-db=<database> --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=256 --time=12000 run等待一段時間後，系統將開始彈出新的唯讀節點。
進入穩定點後，壓測結果如下。與之前單節點同壓力的測試結果相比，效能大幅提升，QPS從17萬～19萬上升到41萬～43萬。根據QPS的表現，已突破單節點彈性測試的最大輸送量。
前往PolarDB控制台，在效能監控頁面查看Serverless監控指標項。根據測試時間調整時間範圍，可以看到如下監控資訊：
在Serverless監控資訊中，會觀察到多個唯讀節點的負載曲線。當新的唯讀節點被彈出後，先前的節點負載將逐步降低，最終達到一個大致的均衡狀態。這表明Proxy成功地將負載平衡至新彈出的唯讀節點。由於目前Serverless為了避免頻繁的規格震蕩，彈升彈降的閾值是一個大區間。
運行一段時間後，停止壓測。根據測試時間調整時間範圍，可以看到如下監控資訊：
叢集的計算節點首先會自動進行縮容，大約2～3分鐘會逐步降至1 PCU。當壓力停止後，唯讀節點的CPU使用率會立刻降低，而主節點還需要執行
purge undo操作，CPU消耗會持續一小段時間，最終降到1 PCU。之後等待較長一段時間，新增的唯讀節點也會在15～20分鐘內逐步回收。為了避免唯讀節點頻繁的彈性震蕩，Serverless沒有選擇立即回收無負載的唯讀節點。
