网络延迟最佳实践

本文档列出了使用 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 DevTools 中检查网络活动，以查看从浏览器发送的 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