ネットワークレイテンシの最適化

このドキュメントでは、Cloud Healthcare API の使用に関するベストプラクティスについて説明します。このページのガイドラインの目的は、効率と精度を向上させることと、サービスからのレスポンス時間を最適化することです。

レイテンシのパフォーマンスを理解する

Cloud Healthcare API のパフォーマンスは、以下の間のレイテンシで測定されます。

Cloud Healthcare API にリクエストを送信したとき。
リクエストに対して完全なレスポンスを受け取ったとき。

レイテンシは、次の 3 つのコンポーネントで構成されます。

ラウンドトリップ時間（RTT）
サーバー処理レイテンシ
サーバースループット

リクエストの送信先のサーバーまでの地理的距離は、RTT とサーバースループットに大きな影響を与える可能性があります。Google Cloud ネットワークのリージョン間のレイテンシとスループットの測定値は、ライブダッシュボードで確認できます。このダッシュボードには、Cloud Healthcare API サーバーにリクエストを行ったときに、クライアントが想定できるさまざまな場所からのパフォーマンスが表示されます。

レイテンシパフォーマンスの測定

以下のツールとダッシュボードは、Cloud Healthcare API サーバーとのリクエストのパフォーマンスを測定する方法として活用できます。

Google Cloud Console のレイテンシ指標: Google Cloud コンソールで Cloud Healthcare API リクエストのサーバー側レイテンシを確認できます。詳しくは Google Cloud SKU をご覧ください。
Cloud Logging のカスタム指標: Logging を使用して分布指標を作成できます。分布指標を使用すると、アプリケーションのエンドツーエンドのレイテンシを構成して理解できます。カスタム定義のレイテンシ測定値をモニタリングしてレポートすることもできます。
Chrome ネットワークパネル: Chrome DevTools でネットワークアクティビティを検査して、ブラウザから送信された HTTP リクエストのパフォーマンスの詳細を確認できます。

リクエストレイテンシの削減

このセクションでは、Cloud Healthcare API に送信されるリクエストのレイテンシを短縮するさまざまな方法について説明します。

最も近いリージョンのロケーションへのリクエストの送信

RTT とサーバーのスループットパフォーマンスを最適化するには、クライアントから最も近い Cloud Healthcare API リージョンのロケーションにリクエストを送信します。使用可能なリージョンのリストについては、リージョンをご覧ください。

レスポンスの本文の圧縮

クライアントが帯域幅を制限している場合、各リクエストに必要な帯域幅を削減する簡単な方法は、gzip 圧縮を有効にすることです。gzipは、データ圧縮の 1 つの形式で、主にファイルのサイズを縮小します。圧縮されていない場合よりも高速でファイルを転送でき、より小さいスペースでの保存が可能です。ファイルを圧縮するとコストと転送時間の両方を減らすことが可能です。

gzip 圧縮を有効にすると結果を抽出するための CPU 時間が余分にかかりますが、一般的に帯域幅を節約できるメリットにより gzip 圧縮は役立っています。ただし、帯域幅の制限が問題にならない場合、gzip 圧縮にメリットはありません。

gzip でエンコードされたレスポンスを受信するには、リクエストに Accept-Encoding ヘッダーを設定する必要があります。

次のサンプルは、gzip 圧縮を有効にするための、適切な形式の HTTP ヘッダーを示しています。

Accept-Encoding: gzip

ウォームアップリクエストの送信

クライアントがセッション中に初めて Cloud Healthcare API サーバーにリクエストを送信すると、クライアントはサーバーとの TCP handshake を実行して HTTP リクエストの接続を確立します。後続のリクエストでは、これらの確立された接続を引き続き使用できるため、クライアントは一般にリクエストに関連付けられている TCP オーバーヘッドを回避できます。その結果、リクエストを送信する際のパフォーマンスが向上します。

HTTP/1.1 または HTTP/2 と同時のリクエストの送信

一連のリクエストのパフォーマンスを最適化するには、複数のリクエストを同時に送信します。同時リクエストを送信する場合は、次のガイドラインを参考にしてください。

同時リクエストを送信する場合は、同時リクエスト数の理想的な数を確認してください。最適な数は、ハードウェアとネットワークの機能、送信されるリクエストの数など、さまざまな要因によって異なります。テストを実施して、最適な数を見つけます。
可能な限り、HTTP/2 を使用してクライアントからリクエストを送信します。HTTP/2 では、複数のリクエストを順次または同時に送信する際に必要な TCP 接続が 1 つだけであるため、HTTP/1.1 よりもパフォーマンスが良好になります。その結果、TCP handshake のオーバーヘッドを回避できます。
HTTP/2 を使用できない場合は、永続的な接続で HTTP/1.1 を使用します。ウォームアップリクエストがすでに送信済みの場合は、TCP handshake のオーバーヘッドを回避できます。永続的な接続を使用する場合は、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
```

ネットワーク レイテンシの最適化