リクエストタイムアウトのトラブルシューティング

SCAPI リクエストには、リクエストのタイムアウト制限があります。リクエスト処理が制限を超えると、504 ゲートウェイタイムアウトレスポンスがクライアントに送信されます。

デフォルトのタイムアウト制限は次のとおりです。

  • Shopper-API: 10 秒
  • Admin-API: 60 秒
  • Custom-API: 10 秒

SLAS や Omnichannel Inventory (OCI) などの一部の API ファミリーには、ゲートウェイのタイムアウトがありません。

ゲートウェイのタイムアウトは、さまざまな理由で発生する可能性があります。タイムアウトの根本原因を特定するには、次の手順を使用します。

すべての SCAPI レスポンスには、リクエストの詳細を識別および追跡するために使用できる correlationID レスポンスヘッダーが含まれています。

タイムアウトが発生したリクエストから correlationID を特定し、ログ情報を収集します。

  1. Business Manager で、管理 > サイトの開発 > 開発セットアップの順に移動します。
  2. ログファイルセクションで、Log Center を選択します。
  3. Day of Year (年間通算日) を選択します。
  4. LCQLcorrelationID を入力します。
  5. 次の手順のために、API-FamilyAPI の値をメモします。

Reports & Dashboards (CIP) のデータを使用して、タイムアウト制限に近いレスポンス時間や処理時間がないか確認します。

  1. Business Manager で、マーチャントツール に移動し サイトを選択します。
  2. Analytics > ** Reports & Dashboards** に移動します。
  3. API のAverage Response time (平均レスポンス時間) を確認します。

平均レスポンス時間がタイムアウトしきい値に近い場合、高負荷時に制限を超える可能性があります。 平均レスポンス時間が短いにもかかわらずタイムアウトエラーが発生する場合は、レスポンスが制限を超えることがあることを示しています。 まれではありますが、ネットワークの問題によってタイムアウトの問題が発生することもあります。

ゲートウェイのタイムアウトの根本原因を特定するには、追加のリクエストの詳細が必要です。

  • リクエストの詳細
  • レスポンスの詳細
  • customApi script (リクエストがカスタム API リクエストの場合)
  • リクエスト処理中に実行されたフック (各フックの実行時間を含む)

verbose ログ記録を有効にした状態で、疑わしいリクエストの再現を試みます。詳細については、追加のリクエストの詳細を参照してください。 Log Center は、verbose ログフィルターを使用してリクエストの詳細提供します。したがって、correlationID とログレベルカテゴリ scapi.verbose を組み合わせて使用してください。

Log Center では、クエリヒットを使用して errors をフィルタリングし、リクエスト処理中に発生したエラーを見つけます。

スクリプトエラーの調査を参照してください。

これらのエラーが定期的に発生しているかどうかを確認し、実行時間の長いリクエストとの関連付けを試みます。

カスタム API で実行されるフックまたはカスタムスクリプトが、タイムアウトの根本的な原因である可能性があります。

フックを含む API は、実行するコードが追加されるため、フックのない API よりも常に遅くなります。さらに、カスタム API とフックにはサーキットブレーカーメカニズムが組み込まれており、特定のエラーしきい値を超えると API リクエストをブロックします。

サーキットブレーカーを参照してください。

Log Center クエリのヒットで、次の例外タイプを確認します。

  • HookInvocationException
  • HookCircuitBreakerException
  • CustomApiInvocationException

スタックトレースを選択して、エラーの根本原因に関する情報が含まれている可能性がある Caused by セクションを見つけます。以下のような原因が考えられます。

  • タイムアウトを超過する外部リクエスト
  • 複雑な計算
  • スクリプトエラー

API ゲートウェイから返される 504 レスポンスコードは、Log Center に表示されるレスポンスコードと同じではない可能性があります。

Code Profiler を使用してパフォーマンスを監視し、パフォーマンスのボトルネックを特定します。

追加のログステートメントとメトリクスを使用して、詳細を収集します。

一般的なガイダンス:

  • リクエストされた展開を確認し、必要なデータのみを選択します。詳細については、サーバー側の Web 階層キャッシングを参照してください。
  • 必要な入手可能性とパーソナライズされたデータのみをリクエストします。
  • カテゴリ ID や商品 ID など、複数の値を使用できるリソース識別子には注意が必要です。その結果、レスポンスデータが大量になり、レスポンス時間が長くなる可能性があります。

クライアント側のガイダンス:

  • 圧縮を使用します。
  • 認証トークンを再利用します。
  • 外部リクエストを回避するか、非同期処理 (ジョブ) を使用します。
  • 複雑な処理や計算は避けます。