データベース接続を1回またはすべてのdatabaseactionで開きますか?
-
03-07-2019 - |
質問
現在、データベースの使用に大きく依存しているASP.NETでwebportalを作成しています。基本的に、すべてのユーザーからの(ほぼすべての:P)GETクエリは、Webサーバーからデータベースへのクエリになります。
今、私はこれに本当に慣れていないので、パフォーマンスが非常に心配です。この分野での経験が不足しているため、何を期待すべきか本当にわかりません。
ADO.NETを使用して、Webサーバーからデータベースへの静的な接続を開いたままにして、データベースへの各クエリの前にこの接続サーバー側の整合性をチェックする方が賢明な選択でしょうか? -または、各クエリの前に接続を開いてから閉じますか?
最初のオプションは、各クエリの前にハンドシェイクなどの時間を節約し、データベースとサーバー側の両方でメモリを節約するので、接続は1つだけですが、このアプローチには欠点があります? 2つのクエリを同時に送信すると、互いに整合性が失われたり、返されたデータセットが混在したりする可能性がありますか?
こことWebのどこでも検索して、これに関するいくつかのベストプラクティスを見つけようとしましたが、運はありません。一番近いのはこれでした:安全ですかデータベース接続を長時間開いたままにしますが、データベースのユーザーが複数いる分散システムにはより適しているようですが、私は自分のウェブサーバーしか持っていません。
解決
パフォーマンスを心配するのは早い段階です。
とにかく、接続はフレームワークによってプールされます。それらを開き、使用し、できるだけ早く廃棄する必要があります。
次のようなもの...
public object Load()
{
using (SqlConnection cn = new SqlConnection(connectionString))
using (SqlCommand cm = new SqlCommand(commandString, cn))
{
cn.Open();
return cm.ExecuteScalar();
}
}
他のヒント
ADO.NETに接続プーリングを処理させる方が良いでしょう。必要と思われる場合は接続を維持しますが、静的な接続オブジェクトは使用しません。それはただ臭いです。接続オブジェクトを必要とするメソッドに渡し、 using
ブロックで接続を作成する方が良いでしょう。
DBの操作が終了したら、常に接続を閉じる必要があります。 ADO.NETには、効率的な接続の再利用を処理する接続プーリングがあります。 2番目、3番目以降の接続を開くたびに、ほとんどオーバーヘッドなしでプールから取得されます。
これがお役に立てば幸いです。
私は、高度な接続プーリングよりもキャッシュについてもっと考えています。すべての取得にはデータベースヒットが必要ですか?
ポータルが一般的なコンテンツとユーザー固有のコンテンツを持っている場合、キャッシュを使用して共通のアイテムを保存でき、マングルキー(ユーザーID)を使用してユーザー固有のアイテムを保存できます。
ADO.NETは接続プーリングを行います。接続オブジェクトでcloseを呼び出すと、接続がプールに保持され、次の接続がはるかに高速になります。
最初の予測は正しいです。必要なのは、データベース接続プーリング
です。データベースの呼び出しごとに接続を開くことは絶対に避けたほうがよいでしょう。その結果、パフォーマンスが極端に低下します。データベース接続の確立は非常に高価です。
代わりに、使用する必要があるのは接続プールです。プールは接続を管理し、可能な場合は既存の接続を再利用しようとします。
プラットフォームはわかりませんが、接続プーリングを検討します-手段を提供するライブラリまたはユーティリティが利用可能になっている必要があります(ベースシステムまたはアドオンとして、またはデータベースドライバに付属)データベースへの複数のアクティブな接続をプールします。これらの接続は、プールから接続を取得するときに使用できます。
正直に言うと、すべてのデータベース抽象化ライブラリでデフォルトでプーリングが発生することを期待しています(無効にするオプションがあります)。 ADO.NETがこれを行うようです。
本当に最初に尋ねる質問は、なぜパフォーマンスに非常に関心があるのですか?予想されるワークロードは何ですか?まだ試しましたか?
しかし、一般的には、はい、毎回データベース接続を再度開くよりも、しばらくの間開いたままにする方が賢明です。接続の種類、ネットワークの問題、月の満ち欠けに応じて、最初の接続を確立するのに1秒以上かかることがあります。 5秒ごとにGETを超えると予想されるワークロードの場合、接続が継続していれば満足できます。