VM 上的 AlloyDB Omni 效能測試方法

選取說明文件版本:

本文說明在 VM 上對 AlloyDB Omni 執行效能測試的建議做法。本文假設您熟悉 PostgreSQL。

評估成效時,請先定義您希望從測試中瞭解哪些資訊,例如:

  • 系統可達到的最大處理量為何?
  • 特定查詢或工作負載需要多少時間?
  • 資料量增加時,成效會如何變化?
  • 這兩個系統的成效有何差異?
  • 資料欄引擎可將查詢效能的回應時間縮短多少?
  • 資料庫可處理多少負載,我才需要考慮升級至效能更強大的機器?

瞭解成效研究的目標,有助於判斷要執行哪些基準測試、需要哪些環境,以及要收集哪些指標。

重複性

如要從效能測試得出結論,測試結果必須可重複。如果測試結果差異很大,您就難以評估應用程式或系統設定變更的影響。多次執行測試或延長測試時間,有助於提供更多資料,進而降低變異量。

理想情況下,效能測試應在與其他系統隔離的系統上執行。在外部系統可能會影響應用程式效能的環境中執行,可能會導致您得出錯誤的結論。在多租戶雲端環境中執行時,通常無法完全隔離,因此結果的變異程度會較大

可重複性的一部分是確保測試工作負載在執行之間保持不變。只要隨機性不會導致應用程式行為出現顯著差異,測試輸入內容中有些隨機性是可以接受的。如果隨機產生的用戶端輸入內容會改變每次執行的讀取和寫入組合,效能就會有顯著差異。

資料庫大小、快取和 I/O 模式

請確保測試資料量足以代表您的應用程式。如果資料量達到數百 GB 或 TB,但測試時只使用少量資料,可能無法如實呈現應用程式的效能。資料集大小也會影響查詢最佳化工具的選擇。針對小型測試資料表的查詢可能會使用資料表掃描,這在較大規模時效能不佳,而且您不會在這個設定中找出缺少的索引。

盡量複製應用程式的 I/O 模式。讀取與寫入的比率對應用程式的效能設定檔非常重要。

基準時間長度

在複雜的系統中,系統執行時會維護大量狀態資訊:建立資料庫連線、填入快取,以及衍生程序和執行緒。在效能測試開始時,如果工作負載的執行階段過短,這些元件的初始化作業可能會佔用系統資源,進而對測得的效能造成負面影響。

建議您執行效能測試至少 20 分鐘,盡量減少系統升溫的影響。在啟動後一段時間,待系統進入穩定狀態後,再進行成效評估,確保資料庫作業的各個層面都納入評估範圍。舉例來說,資料庫檢查點是資料庫系統的重要功能,可能會對效能造成重大影響。如果執行時間短於檢查點間隔的基準測試,應用程式行為中的這項重要因素就會遭到隱藏。

有條不紊的測試

調整成效時,請一次只變更一個變數。如果您在執行期間變更多個變數,就無法判斷是哪個變數提升了成效。事實上,多項變更可能會相互抵銷,因此您不會看到適當變更帶來的效益。如果資料庫伺服器過度使用資源,請嘗試改用 vCPU 數量較多的機器,同時維持負載量不變。如果資料庫伺服器未充分利用資源,請嘗試增加負載,同時維持 CPU 設定不變。

網路拓撲和延遲

系統的網路拓撲可能會影響效能測試結果。可用區之間的延遲時間不同。執行效能測試時,請務必確保用戶端和資料庫叢集位於同一區域,這樣可將網路延遲時間降到最低,並獲得最佳效能,特別是對於高處理量、交易時間短的應用程式而言,因為網路延遲時間可能會是整體交易回應時間的重要組成部分。

比較兩個不同系統的效能時,請確保兩個系統的網路拓撲相同。請注意,即使在同一區域內,由於底層網路拓撲的差異,延遲時間仍可能有所不同,因此無法完全消除網路延遲變異性。

部署應用程式時,您可以考慮使用一般高流量網路應用程式,進一步瞭解跨區域延遲時間的影響。應用程式的負載平衡器會將要求傳送至部署在多個可用區的網路伺服器,以確保高可用性。由於跨區域延遲時間不同,處理要求的網路伺服器不同,延遲時間也可能不同。

下圖顯示使用 AlloyDB Omni 的網路應用程式一般架構。用戶端要求會由負載平衡器處理,並將每個要求轉送至多個網路伺服器中的其中一個。所有網路伺服器都已連線至 AlloyDB Omni。部分伺服器與 AlloyDB Omni 執行的區域不同,因此發出資料庫要求時會遇到較高的延遲。

流程圖:顯示典型的網路應用程式架構。
圖 1:一般網路應用程式架構的圖示。當可用區 B 中的網路伺服器向資料庫發出要求時,我們預期延遲時間會較短,因為這些伺服器與 AlloyDB Omni 資料庫位於同一可用區。

資源監控

如要提升資料庫系統的效能,您需要監控資料庫系統和使用資料庫系統的用戶端系統資源用量。同時監控這兩個系統,即可確保用戶端系統提供足夠的工作負載,在資料庫系統中取得有意義的測量結果。監控所測試系統的資源用量至關重要。監控用於驅動工作負載的用戶端系統資源用量,也同樣重要。舉例來說,如要判斷資料庫系統在 CPU 資源耗盡前可支援的用戶端數量上限,您需要有足夠的用戶端系統,才能產生工作負載,用盡資料庫系統中的所有 CPU 資源。如果產生負載的用戶端電腦本身沒有足夠的 CPU,您就無法充分驅動資料庫系統。

擴充性測試

擴充性測試是效能測試的另一個面向。可擴充性是指工作負載的某項特徵發生變化時,效能指標的變化情形。可擴展性研究的範例如下:

  • 並行要求數量增加時,輸送量和回應時間會如何變化?
  • 資料庫大小增加時,輸送量和回應時間會如何變化?

可擴充性測試包含多次執行工作負載,每次執行時會變更單一維度,並收集及繪製一或多個指標。這類測試可協助您瞭解系統有哪些瓶頸、在特定設定下系統可處理的負載量、系統可支援的最大負載量,以及負載量超出這些等級時系統的行為。

機器大小注意事項

AlloyDB Omni 為 Postgres 導入許多新功能,可提升資料庫的可靠性和可用性。執行這項作業所需的監控功能會使用執行 AlloyDB Omni 的機器資源。極小的機器大小一開始就只有有限的記憶體和 CPU 資源,因此建議您至少使用四個 vCPU 的機器大小進行基準化測試。