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 的機器大小進行基準化測試。