このドキュメントでは、Route Optimization API リクエストのタイムアウトと期限の設定方法について説明します。これらの値を設定しない場合や、誤って設定した場合は、接続やレスポンスの品質に問題が生じる可能性があります。
タイムアウトはリクエストの本文で定義し、期限はリクエスト ヘッダーで定義します。Route Optimization API は、これらのパラメータで定義された制限時間内にリクエストを処理します。このとき、最も短い時間値が優先されます。
タイムアウトと期限を構成すると、次のように処理時間を管理できます。
- 処理時間を増やす:
- 複雑なリクエストを解決する。
- より高品質のレスポンスを取得する。
- 処理時間を短縮する:
- デフォルトよりも早く、複雑度の低いリクエストを解決する。
- リクエストを短時間で解決するが、レスポンスの品質は低下する。
注: タイムアウト パラメータと期限パラメータは、solvingMode が
デフォルト値の DEFAULT_SOLVE に設定されている場合にのみ適用されます。VALIDATE_ONLY、DETECT_SOME_INFEASIBLE_SHIPMENTS、TRANSFORM_AND_RETURN_REQUEST などの他の solvingMode オプションは、通常、大幅に高速であるため、タイムアウトの調整は必要ありません。
タイムアウトと期限のニーズを把握する
タイムアウトと期限を構成する前に、このセクションを確認して、エンドポイントとプロトコルの選択がこれらの設定にどのように影響するかを理解してください。
次のガイドラインは、目標に適した設定を使用しているかどうかを確認するのに役立ちます。
- 継続的かつ繰り返しリクエストを行う場合や、解決に時間がかかる複雑なリクエストの場合は、ノンブロッキング エンドポイント を使用します。
- 小さなリクエストや結果の迅速な配信には、ブロッキング エンドポイント を使用します。この場合、品質が低下する可能性があります。
- 日々のワークフロー、特に本番環境のアプリケーションには gRPC を使用します。
- テスト、試験運用、1 回限りのリクエストには REST を使用します。
下のボタンをクリックすると、このドキュメントのどのセクションが設定に最も関連しているかを判断するのに役立つ図が表示されます。
timeout パラメータを設定する
リクエストの本文で timeout パラメータの値を設定して、
サーバーがレスポンスを返す前にリクエストを処理する最大時間を指定します。API が割り当てられた最大時間に達する前に最適なソリューションを見つけた場合、実際に費やされる時間は割り当てられた時間よりも短くなることがあります。
timeout パラメータは、期間プロトコル
バッファを使用して設定します。これは、1 秒から 1,800 秒までの範囲の秒数です。
allowLargeDeadlineDespiteInterruptionRisk を使用すると、この値を最大 3,600 秒まで増やすことができます。
推奨される timeout 値
次の表に、リクエストの
複雑さ、配送と車両の数に基づいて推奨される timeout 値を示します。
| 配送と車両の数 | 制約なし | 時間枠と負荷の制約が緩い、またはルートが長い | 時間枠、負荷の制約、複雑な制約が厳しい、またはルートが非常に長い |
| 1 - 8 | 2 秒 | 2 秒 | 5 秒 |
| 9 - 32 | 5 秒 | 10 秒 | 20 秒 |
| 33 - 100 | 15 秒 | 30 秒 | 60 秒 |
| 101 - 1,000 | 45 秒 | 90 秒 | 180 秒 |
| 1,001 - 10,000 | 120 秒 | 360 秒 | 900 秒 |
| 10,001 以上 | 60 秒 + 10,000 件の配送ごとに 120 秒 | 10,000 件の配送ごとに 360 秒 | 10,000 件の配送ごとに 900 秒 |
期限を設定する
リクエスト ヘッダーに期限を設定して、Route Optimization API がリクエストの処理に費やす最大時間を定義します。以降のサブセクションでは、REST リクエストと gRPC リクエストの期限を設定する方法について説明します。
REST リクエスト
REST を使用してブロッキング エンドポイントを呼び出す場合、期限をデフォルトの 60 秒を超えて延長できます。これは、複雑なリクエストでは短すぎる場合がよくあります。リクエストの本文でより長い期限を指定している場合でも、これを行う必要があります。これは、デフォルトの期限が、リクエストの本文で設定された 60 秒を超える timeout 値をオーバーライドするためです。
X-Server-Timeout リクエスト ヘッダーを設定して、期限をデフォルトの 60 秒を超えて延長します。リクエストの本文とは異なり、ヘッダーの値は秒数ですが、「s」サフィックスはありません。このヘッダーに設定できる最大値
は、timeout パラメータの
制限に沿っています。
次のコードサンプルは、X-Server-Timeout が 1,800 秒に設定された HTTP ヘッダーを示しています。
curl -X POST 'https://routeoptimization.googleapis.com/v1/projects/:optimizeTours' \
-H "Content-Type: application/json" \
-H "X-Server-Timeout: 1800" \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
--data @- << EOM
{
"model": {
...
}
}
EOM
クライアント ライブラリと gRPC リクエスト
クライアント ライブラリまたは gRPC を使用する場合は、期限を構成する必要はありません。これらを使用する場合のデフォルトの期限は 3, 600 秒で、この API の最大リクエスト時間です。リクエストの本文で timeout プロパティを設定するだけで、解決時間を構成できます。
タイムアウトと期限に影響するパラメータ
次のパラメータは、タイムアウトと期限の両方の機能に影響します。
allowLargeDeadlineDespiteInterruptionRiskを使用して、リクエストの最大期限を制御します。searchModeを使用して、検索の動作を定義し、レイテンシとソリューションの品質のバランスを取ります。
allowLargeDeadlineDespiteInterruptionRisk
allowLargeDeadlineDespiteInterruptionRisk パラメータは、
リクエストの最大期限を 3,600 秒に増やします。このパラメータが設定されていない場合、timeout パラメータと期限パラメータの最大値は 1, 800 秒です。
allowLargeDeadline DespiteInterruptionRisk を true に設定すると、timeout パラメータと期限パラメータの値が最大 3,600 秒に増えます。
allowLargeDeadline DespiteInterruptionRisk に指定できる値は次のとおりです。
true: 中断のリスクを認識しながら、timeout パラメータと期限パラメータの最大値を 3,600 秒に増やします。false(デフォルト): timeout パラメータと期限パラメータの最大値を 1,800 秒に維持します。
3, 600 秒を超えるタイムアウトが必要と思われる場合は、Google の担当者にお問い合わせください。
searchMode
searchMode パラメータは、オプティマイザーが
ソリューションを検索する方法を制御します。これにより、迅速なレスポンス(レイテンシの短縮)
または高品質のソリューションを優先できます。
ソリューションの品質を優先する場合、オプティマイザーは高品質のソリューションを見つけるまでにかなりの時間を要します。このような長いリクエストの場合は、接続の問題を回避するために、タイムアウトを長く設定し、ノンブロッキング エンドポイントを使用することを検討してください。
searchMode に指定できる値は次のとおりです。
SEARCH_MODE_UNSPECIFIED(デフォルト): 指定されていない検索モード。RETURN_FASTと同等です。RETURN_FAST: 最初の適切なソリューションが見つかったら検索を停止します。CONSUME_ALL_AVAILABLE_TIME: より良いソリューションを探すために、利用可能な時間をすべて費やします。最適なソリューションが早期に見つかった場合、API は利用可能な時間をすべて使用しません。
キープアライブ ping を有効にする
タイムアウトが 60 秒を超えるブロッキング エンドポイントにリクエストを行う場合、キープアライブ ping はレスポンスを待機している間の接続の切断を防ぎます。キープアライブ ping は、接続アクティビティを維持し、接続の切断を検出して防止するために送信される小さなパケットです。
使用する API プロトコルに基づいて、次のパラメータを構成します。
- REST: TCP 接続レベルでキープアライブを構成します。
- gRPC: 基盤となる TCP ソケットまたは gRPC プロトコルで直接キープアライブ ping を構成します。
以降のセクションでは、両方のプロトコルのキープアライブ ping を設定する方法について説明します。
REST キープアライブ
REST を使用する場合のキープアライブ ping の構成は、HTTP クライアント ライブラリによって異なります。curl などのクライアント ライブラリとツールでは、特定の構成オプションが用意されているか、ping が自動的に有効になっている場合があります。
ライブラリが基盤となる TCP ソケットを公開している場合は、SO_KEEPALIVE などのオプションを使用して、TCP ソケットで直接キープアライブ ping を構成できます。これを行うには、setsockopt() などの関数または同等の関数を使用します。
GitHub でホストされているこの関数は、Python の組み込み HTTP クライアントでこれを正しく設定する方法を 示しています。
TCP レベルのキープアライブの詳細については、TLDP キープアライブ の概要または HTTP クライアント ライブラリのドキュメントをご覧ください。
gRPC キープアライブ
gRPC には、プロトコルの一部として独自の組み込みキープアライブ メカニズムが用意されています。クライアント言語でこれを設定する方法については、gRPC キープアライブ ガイドをご覧ください。
注: gRPC サーバーは、ping を送信しすぎるクライアントを拒否する可能性があります。キープアライブ ping の頻度を高く設定しすぎないようにしてください。
キープアライブを使用した gRPC サンプル リクエスト
次の例は、Python クライアント ライブラリと gRPC レベルのキープアライブ ping を使用して optimizeTours リクエストを行う方法を示しています。
from google.maps import routeoptimization_v1 as ro
from google.maps.routeoptimization_v1.services.route_optimization.transports import grpc as grpc_transport
import sys
_REQUEST_TIMEOUT_SECONDS = 1800
_KEEPALIVE_PING_SECONDS = 30
def create_channel(*args, **kwargs):
raw_options = kwargs.pop("options", ())
options = dict(raw_options)
options["grpc.keepalive_time_ms"] = _KEEPALIVE_PING_SECONDS * 1000
options["grpc.keepalive_timeout_ms"] = 5000
# Allow any number of pings between the request and the response.
options["grpc.http2.max_pings_without_data"] = 0
print(f"Using options: {options}", file=sys.stderr)
return grpc_transport.RouteOptimizationGrpcTransport.create_channel(
*args,
options=list(options.items()),
**kwargs,
)
def create_grpc_transport(*args, **kwargs):
if "channel" in kwargs:
raise ValueError(
"`channel` is overridden by this function, and must not be provided."
)
return grpc_transport.RouteOptimizationGrpcTransport(
*args,
channel=create_channel,
**kwargs,
)
def run_optimize_tours(request):
client = ro.RouteOptimizationClient(transport=create_grpc_transport)
return client.optimize_tours(request, timeout=_REQUEST_TIMEOUT_SECONDS)