API 呼び出しのパフォーマンスの問題のトラブルシューティング
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": "トマト スープ","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 呼び出しレート制限に達しているように見えます。 おそらく、操作レベルで実装されている "レート制限" または "キーごとのレート制限" ポリシーがある場合は、チェックできます。
このようなポリシーが操作レベルで見つからない場合は、[ 有効なポリシーの計算 ] ボタンをクリックします。このボタンをクリックすると、この問題の原因となる可能性のあるポリシーが製品レベルにある場合など、さまざまなレベルから継承されたすべてのポリシーが表示されます。
ここで、一部のポリシーは API レベルで実装されており、API 呼び出し速度は実際には制限されませんが、カスタマイズされた応答を送信セクションで 'return-response' ポリシーと 'set-status' ポリシーを使用してクライアントに返すことによって、そのアクションを模倣しています。
<?xml version="1.0" encoding="UTF-8"?> <outbound> <!--base: Begin Api scope--> <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> <!--base: End Api scope--> </outbound>
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。