0

ASP.NET アプリケーションでは、MySQL の上に構築されたデータ層を実装しました。これは、Entity Framework を実装するためにConnector/NETを使用します。

これはほとんどの CRUD アクションで問題なく機能しますが、数百のレコードで INSERT ステートメントを実行すると、「接続が多すぎます」という例外がスローされます。

多くの個別の読み取り/書き込み呼び出しを行っていることは承知していますが (すべての挿入の前に重複するエントリをクエリし、さらに、挿入ごとに個別のクエリを使用して書き込まれる監査ログもあります)、接続しないでください。プールはこれの世話をしますか？

また、この同様のスレッドでは、OP は私が完全に同意するusingステートメントを使用するように指示されました。別の要求がキューに入れられている場合。

とにかく、connect timeout現在は 50 です。これはすでにかなり小さいですよね? 500 まで上げても違いはありませんでしたが、10 まで下げても、同じ例外がスローされる前に挿入が約 50% 増えました。

では、DbContext のすべてのインスタンスがusingステートメントでラップされているのに、なぜ「接続が多すぎます」という例外が発生するのでしょうか?

更新:問題の根本原因は、実際にはリポジトリの 1 つがコンストラクターで DB 接続を開いていることが原因であることがわかりました。この接続は使用されていませんでした。申し訳ありませんが、これはニシンであることが判明しました。ご提案いただきありがとうございます。

4

2 に答える 2

0

正確にはあなたが探している答えではありません...しかし：

すべてのアクションで同じ接続を使用していない特定の理由はありますか?

例として：

連続して 50 回の挿入を実行し、その結果、同じ接続を使用して 50 回のクエリ (挿入ごとに 1 つ) を実行すると、システムのパフォーマンスが大幅に向上します。

于 2013-07-30T08:29:52.450 に答える
0

典型的な挿入の平均的な実行はどうですか? 前のものが処理される前に、新しい挿入 (すべての挿入サブクエリを含む) 要求の接続が取得される可能性はありますか? この重い挿入負荷の間に DAL 挿入関数がどのように実行されているかをプロファイル/ログに記録しようとしましたか? ロジックの一部を「純粋なエンティティ クエリ」からトリガー (監査ログ、 MySQL トリガーをプログラムして行を別のテーブルに挿入する方法を参照)に移動することで、パフォーマンス (これが問題になる場合) を大幅に改善できる場合があります。サーバーへのラウンドトリップが少なくなり、クエリをより細かく制御できるためです。

そして、最後のオプションとして、mysql 構成を掘り下げて、デフォルトで 100 接続である接続制限を増やすことができます。しかし、この考えは通常、DAL のボトルネックの検索を延期するだけです。

于 2013-07-30T10:25:58.710 に答える