網路延遲最佳做法

本文列出使用 Cloud Healthcare API 的最佳做法。本頁面的規範旨在提高服務的效率和準確性，並實現最佳回應時間。

瞭解延遲效能

Cloud Healthcare API 的效能會根據以下項目的延遲時間來評估：

  1. 向 Cloud Healthcare API 傳送要求時。
  2. 收到要求的完整回覆。

延遲時間包含三個部分：

  • 封包往返時間 (RTT)
  • 伺服器處理延遲時間
  • 伺服器總處理量

您與要求的伺服器之間的地理距離，可能會對 RTT 和伺服器傳輸量造成重大影響。您可以在即時資訊主頁中，查看測量的區域間延遲時間和 Google Cloud 網路吞吐量。資訊主頁會顯示用戶端向 Cloud Healthcare API 伺服器提出要求時，從不同位置可預期的效能。

測量延遲時間效能

下列工具和資訊主頁可協助您評估 Cloud Healthcare API 伺服器的傳入和傳出要求效能：

  • Google Cloud 主控台延遲指標：您可以在 Google Cloud 主控台中查看 Cloud Healthcare API 要求的伺服器端延遲時間。詳情請參閱 Google Cloud 指標。

  • Cloud Logging 自訂指標：您可以使用 Logging 建立分佈指標。您可以使用分布指標設定及瞭解應用程式中的端對端延遲時間。您也可以監控及回報任何自訂定義的延遲時間測量值。

  • Chrome 網路面板：您可以在 Chrome 開發人員工具中檢查網路活動，查看瀏覽器傳送的 HTTP 要求的效能詳細資料。

縮短要求延遲時間

本節說明各種方法，可減少傳送至 Cloud Healthcare API 的要求延遲時間。

將要求傳送至最近的區域位置

如要獲得最佳 RTT 和伺服器總處理量效能，請從用戶端將要求傳送至最近的 Cloud Healthcare API 區域位置。如需可用地區的清單，請參閱「地區」。

傳送暖機要求

當用戶端在工作階段中首次向 Cloud Healthcare API 伺服器傳送要求時，用戶端會與伺服器執行 TCP 握手，以建立 HTTP 要求的連線。後續的任何要求都可以繼續使用這些已建立的連線，讓用戶端避免通常與要求相關聯的 TCP 額外負擔。這可在傳送要求時提升效能。

同時傳送 HTTP/1.1 或 HTTP/2 要求

如要為一系列要求獲得最佳效能，請同時傳送要求。傳送並行要求時，請遵守下列規範：

  • 傳送並行要求時，請嘗試找出並行要求的理想數量。理想的數量取決於多項因素，包括硬體和網路功能，以及傳送的要求數量。進行測試找出理想的數量。
  • 盡可能使用 HTTP/2 從用戶端傳送要求。HTTP/2 的效能比 HTTP/1.1 更佳，因為 HTTP/2 在依序或同時傳送多個要求時，只需要一個 TCP 連線。因此，您可以避免 TCP 握手的額外負擔。

  • 如果無法使用 HTTP/2，請使用 HTTP/1.1 搭配永久連線。如果已傳送暖機要求，您可以避免 TCP 握手的額外負擔。使用永久連線時，您可能需要為 HTTP 程式庫管理經過最佳化的連線與連線集區。

    舉例來說，如要使用 Java 專用 Google HTTP 用戶端程式庫設定含有 20 個並發要求的連線集區，程式碼應包含以下內容：

    PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
// Support 20 concurrent requests.
cm.setDefaultMaxPerRoute(20);
cm.setMaxTotal(100);
HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();

    如要使用 Node.js 設定連線集區，並讓集區支援 20 個並行要求，程式碼應包含以下內容：

    require('http').globalAgent.maxSockets = 20