API 呼び出しのパフォーマンスに関する問題のトラブルシューティング

[アーティクル]
11/20/2024

Azure API Management トラブルシューティングシリーズに関するブログを参照してください、これはラボの 4 番目のシナリオです。問題を再現するには、このに従ってラボのセットアップ手順に従っていることを確認します。

元の製品バージョン: API Management サービス
元の KB 番号: 4464929

現象

APIM の API ProductStore はバックエンドエンドポイント (https://productstoreapp.azurewebsites.net) と通信して、必要に応じてレコードを簡単に作成、読み取り、更新、削除します。ただし、以下に示す API 操作の呼び出し中に、パフォーマンスの問題や例外が発生する可能性があります。テストを容易にするために、ID が 1 から 3 の 3 つの製品のみを保持します。

Products_GetAllProducts API 関数の 1 つは、結果を返すために 5 秒かかっています。一方、予想される応答時間は 1 秒未満です。
上記のいずれかの ID (1 から 3) を持つ製品を削除すると、Products_DeleteProduct操作を呼び出して、次のメッセージでHTTP 500 - 内部サーバーエラーが発生します。

{
"Message": "エラーが発生しました。"
}
製品Products_PutProduct 更新する操作が予期せず調整され、 HTTP 429 - 要求が多すぎます 要求で送信した製品 ID と要求本文に関係なく、次のエラーメッセージが表示されます。たとえば、顧客が製品 ID = 1 の "Tomato Soup" の製品価格を以下の Json 本文で更新すると、HTTP 429 状態コードが取得されます。

テンプレートパラメーター ID : 1
要求本文: {"Name": "Tomato soup","Category": "Groceries","Price": 2.45}
応答本文:
{
レート制限を超過しています。しばらくしてからもう一度試してください。
}

トラブルシューティングの手順

パフォーマンスの問題のトラブルシューティング中に、障害の分離手法として最適な方法は、[各セクション (受信/バックエンド/送信) にかかった時間を示す APIM インスペクタートレース] をキャプチャすることです。
最初の問題について API Inspector トレースを分析すると、バックエンドセクションにほとんどの時間 (約 5 秒) がかかっていることがわかります。これは、バックエンドで実行速度が低下しているか、実行時間が長くなっていることを意味します。

"source": "forward-request",
"timestamp": "2018-07-29T16:16:46.6615081Z",
"elapsed": "00:00:05.5844430","data": {
"response": {
"status": {
"code": 200,
"reason": "OK"
}
バックエンドでの速度低下を分離したら、Web API アプリケーションのバックエンドアプリケーションコードを調査する必要があります。バックエンドにアクセスできないシナリオでは、次のように APIM レベルでキャッシュを実装できます。 Azure API Management のパフォーマンスを向上させるために、キャッシュポリシーを実装する方法について説明します。
```
<?xml version="1.0" encoding="UTF-8"?>
<policies>
   <inbound>
      <base />
      <cache-lookup vary-by-developer="true" vary-by-developer-groups="true" must-revalidate="true" downstream-caching-type="public" />
   </inbound>
   <backend>
      <base />
   </backend>
   <outbound>
      <base />
      <cache-store duration="60" />
   </outbound>
   <on-error>
      <base />
   </on-error>
</policies>
```
2 つ目の問題 (HTTP 500 - 内部サーバーエラー) については、APIM インスペクタートレースの分析と同じ手順に従います。"forward-request" 応答属性の下に HTTP 500 状態コードが表示されます。
これは、バックエンドコードで何らかのハンドルされない例外が発生したためにバックエンド API から HTTP 500 が返されたことを意味します。APIM レベルでは問題はありません。

forward-request (841.060 ms)
{
"response": {
"status": {
"code": 500,
"reason": "内部サーバーエラー"
}
3 番目の問題 (HTTP 429 - 要求が多すぎます) では、API 呼び出しレート制限に達しているように見えます。おそらく、操作レベルで実装されている "rate-limit" または "rate-limit-by-key" ポリシーがあるかどうかを確認できます。
操作レベルでこのようなポリシーが見つからない場合は、 [有効なポリシーの計算 ] ボタンをクリックします。これにより、さまざまなレベルから継承されたすべてのポリシーが表示されます。たとえば、この問題の原因となる可能性のあるポリシーが製品レベルにある可能性があります。
ここでは、一部のポリシーが API レベルで実装されていることに注意してください。API 呼び出し速度は実際には制限されませんが、カスタマイズされた応答を送信セクションで 'return-response' ポリシーと 'set-status' ポリシーを使用してクライアントに返すことによって、そのアクションを模倣します。
```
<?xml version="1.0" encoding="UTF-8"?>
<outbound>
   
   <return-response>
      <set-status code="429" reason="Too many requests" />
      <set-body><![CDATA[{

Rate limit is exceeded. Try again after some time.

}]]></set-body>
   </return-response>
   
</outbound>
```

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティサポートにお問い合わせください。 Azure フィードバックコミュニティに製品フィードバックを送信することもできます。

次の方法で共有

API 呼び出しのパフォーマンスに関する問題のトラブルシューティング

現象

トラブルシューティングの手順

お問い合わせはこちらから

フィードバック

その他のリソース