2017-12-11 26 views
1

ここ数日、Azure SQLデータベースと通信するEntity Frameworkによって断続的な例外が発生し始めました。それがスローする例外は、特に私たちのコードに関連していますが、メッセージは以下のとおりです:EntityCommandExecutionException:Entity FrameworkのAzure SQLが遅くなり、要求が拒否される

コマンド定義の実行中にエラーが発生しました。詳細については 内部例外を参照してください。実行タイムアウトが切れました。操作が完了する前にタイムアウト時間 が経過したか、サーバーが応答していません( )。待機操作がタイムアウトしました

明らかに、データベースへの要求はタイムアウトしましたが、突然起き始めました。直近の日では、平均応答時間も増加しています。 Azure SQL Response time 最適な応答時間は、洗練と最適化が必要なほど速くはありませんが、大幅な増加が見られます。

私たちのモバイルアプリケーションは、開始時にAPIから多くの情報を要求し、数分後に一緒に失敗するように見える多くのリクエストを行います。

ここに何が起こっているのでしょうか? Azureポータルには、私たちのAPIが通常よりも遅い(我々が知っているよりも遅い)という通知を除いてエラーはありません。

答えて

2

これは、私がこの問題に巻き込まれているので大変価値があったポスト。

これは、Azureが提供するデータベース層とDTUの制限の結果です。

DTUは、サービス層のパフォーマンスの測定単位であり、いくつかのデータベース特性の要約です。各サービス層には、1つの層のパフォーマンスレベルと別の層のパフォーマンスレベルを簡単に比較する方法として、特定の数のDTUが割り当てられています。 はから:Azure SQL Database "DTU percentage" metric

何が起こっているかについての手掛かりがhereを見つけることができます:ワークロードは、これらのリソースのいずれかの量を超えた場合

、あなたのスループットが絞られる - パフォーマンスの低下をもたらし、タイムアウト。

私たちは基本層データベースを使用していましたので、制限は5 DTUでした。アプリが起動してこのキャップに当たったときに、大量のデータを一度に(あまりにも多く)要求していました。 Azure SQlはクエリを絞って、いくつかの作業を遅くし、他のものを拒否しました。これまでのようなことを思い出して、私はAzureポータルでDTUグラフを確認しましたが、長い時間スケールを見ていたに違いないので、使い方の大きなスパイクは私に隠されていました。

Azureデータベース層とDTU制限を5から20(4倍のパフォーマンス)に向上させ、すべての例外と失敗したリクエストを停止しました。

これは、EntityFrameworkによって提供される曖昧な例外と遅い要求のため、特に厄介な問題です。今後、Azure SQLにDTU上限についての情報を含めると良いでしょう。

これを防止するために追加したもう1つの点は、私たちのDTU使用率が80%を超えて再び這い上がった場合に私たちに通知するアラートでした。 Azure Portal> AzureSQLデータベース>監視>アラートルールを参照してください。 Azure DTU cap alert

私の意見では、Azureはこのアラートを自動的に作成する必要があります。私はこれで焼けたことはないと確信しています!

関連する問題