11

一日中、夜も朝も検索した後、すべてのアイデアを使い果たしたので、皆さんがこれを実行して、明るいアイデアがあるかどうかを確認したかっただけです。私たちが直面している問題は、タイムアウト、接続の切断/切断、データベースサーバーへのアクセス不能など、同時使用時(セレンテスト)のデータベース接続に常に集中しています。

同じデータベース(SQL Azure)を指す同じコードで同じセレンテストを実行している場合でも、ローカルで問題が発生していないため、この問題はAzureに限定されているようです。したがって、アウトバウンドの問題であることがわかります。 SQLAzureのデータベース接続。これまでのところ、次のことを試しました。

  1. Azureの一時的な障害処理–SQLAzureサービス自体に一時的な問題が発生した場合の再試行ロジックが用意されています。
  2. 通信プロトコルの変更– TCPと名前付きパイプの両方を試しましたが、両方で同じ問題が発生しました。
  3. データベース接続のタイムアウト間隔を調整する–これを無駄に増やしてみました。
  4. 複数のアクティブな結果セットの追加–これを接続文字列に追加しても無駄になります。
  5. すべてのクエリの接続状態チェック– DataContextを返すときに、接続をチェックし、必要に応じて再度開きます。
  6. 接続プールをオフにしました-これも試みましたが成功しませんでした。
  7. 変更されたデザインパターン–作業単位の設計パターンを実装するまでに至りました。データベース接続はすべての作業単位の後に起動されて破棄されていましたが、これにより、遅延読み込み、メソッドへのオブジェクトの受け渡しなどの問題が発生しました。この時点では、かなりのやり直しが必要でした。

  8. 役割のサイズを変更する– Windows Azureで暗黙的な接続制限が発生した場合に、役割のサイズを増やすことを最後に検討できます。これは現在展開されているため、機能する可能性はまだ半分です。

サイトのインフラストラクチャは次のとおりです。

  • コードファーストEFコンテキストであるDataContextクラス(DbContextを拡張)。
  • BusinessLayerクラスには、非静的なプライベートDataContextが含まれています。DataContextは、各Manager/Helperクラスに注入されるコンストラクターです。
  • BusinessLayerServiceクラスには、パブリックのスレッド静的BusinessLayerインスタンスが含まれています。
  • MVCサイトは、BusinessLayerService.Instanceを使用して、渡されたDataContextをクエリおよび更新するマネージャークラスにアクセスします。

どんな助けでも大歓迎です。

更新: VMサイズをMediumに上げましたが、同じ問題が発生するまでに時間がかかっただけでした。

問題が発生し始めたとき、チームメンバーは次の例外が発生したことに気づきました。

InvalidOperationException:コマンドを実行するには、開いている使用可能な接続が必要です。接続の現在の状態が切断されています。

これは、データベースがヒットするたびに発生し始めました(コードの特定の領域に固有ではありませんでした)。

4

1 に答える 1

5

私は以前にこの種の問題に遭遇しました。私の場合、それはEntity Framework ObjectContextが適切に破棄されなかったことと関係があり、最終的にはあまりにも多くのコンテキストがスピンアップされ、サイトが転倒しました。Entity Framework Profilerを使用して、エラーがスローされたときに閉じられていないObjectContextがたくさんあることを確認しました。

ビジネスレイヤーの書き直しが必要になるため、作業ユニットのデザインパターン(または同様のパターン)に移行することは不可能でした。そのため、ページリクエストごとにObjectContextsを手動で閉じることで解決しました。Global.asaxのEndRequestイベントでコンテキストを手動で破棄するアプローチを採用しましたが、他の有効なアプローチは、コンテキストをHttpContextに格納するか、「リクエストごとに」を使用してIoCコンテナー(Castle Windsorなど)を実装することでした。 「ライフスタイル。

于 2012-10-05T14:12:00.463 に答える