针对网络延迟进行优化

本文档列出了使用 Cloud Healthcare API 的最佳做法。本页面中的指导准则旨在提高效率和准确性，并保证服务的最佳响应时间。

了解延迟时间性能

Cloud Healthcare API 的性能根据以下两者之间的延迟时间来衡量：

延迟时间由三个部分组成：

您和您向其发送请求的服务器之间的地理距离对 RTT 和服务器吞吐量有重大影响。您可以在实时信息中心查看所测量的 Google Cloud 网络的地区间延迟时间和吞吐量。信息中心显示在向 Cloud Healthcare API 服务器发出请求时，客户端可从不同位置获得的性能。

以下工具和信息中心提供了衡量 Cloud Healthcare API 服务器发出和收到的请求的性能的方法：

Google Cloud Console 延迟时间指标：您可以在 Google Cloud 控制台中查看 Cloud Healthcare API 请求的服务器端延迟时间。如需了解详情，请参阅 Google Cloud 指标。
Cloud Logging 自定义指标：您可以使用 Logging 创建分布指标。分布指标可让您配置和了解应用中的端到端延迟时间。您还可以监控和报告任何自定义定义的延迟时间测量结果。
Chrome 网络面板：您可以在 Chrome DevTools 中检查网络活动，以查看从浏览器发送的 HTTP 请求的性能详情。

本节介绍缩短发送到 Cloud Healthcare API 的请求的延迟时间的各种方法。

为了获得最佳的 RTT 和服务器吞吐量性能，请将来自客户端的请求发送到最近的 Cloud Healthcare API 地区位置。请参阅地区查看可用地区的列表。

如果客户端的带宽有限，要减少每个请求所需的带宽，一种简单的方法是启用 gzip 压缩。gzip 是一种数据压缩格式，通常用来缩减文件的大小。与非 gzip 文件相比，gzip 文件传输得更快，并且占用的存储空间也更少。压缩文件有助于减少费用并缩短传输时间。

虽然启用 gzip 压缩需要额外的 CPU 时间来对结果进行解压缩，但考虑到节约的带宽，使用 gzip 压缩通常还是很值得的。但是，如果有限的带宽不是问题，则 gzip 压缩提供的优势并不划算。

为了接收 gzip 编码的响应，您必须在请求中设置 Accept-Encoding 标头。

以下示例展示了一个用于启用 gzip 压缩的格式正确的 HTTP 标头：

Accept-Encoding: gzip

当客户端在会话中首次向 Cloud Healthcare API 服务器发送请求时，客户端会与服务器进行 TCP 握手，以建立 HTTP 请求的连接。任何后续请求都可以继续使用这些已建立的连接，从而允许客户端避免通常与请求相关的 TCP 开销。这提高了发送请求时的性能。

要获取一系列请求的最佳性能，请同时发送请求。发送并发请求时，请遵循以下准则：

发送并发请求时，请尝试确定并发请求的理想数量。理想的数量取决于多个因素，包括硬件和网络功能以及发送的请求数量。进行测试以确定理想的数量。
尽可能使用 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
```