サービスとして提供したいウェブサイトを作成しています。各顧客には独自のデータベースがあり、各サイトには 2 つのデータベースが必要です。100 人のアクティブな顧客がいて、全員がそれぞれのサイトで作業している場合、200 の個別の接続文字列を持つことができます。
多すぎる数を調べるにはどうすればよいですか? 問題が発生するまで待ちたくありません。事前に計画を立てておきたいのです。
サービスとして提供したいウェブサイトを作成しています。各顧客には独自のデータベースがあり、各サイトには 2 つのデータベースが必要です。100 人のアクティブな顧客がいて、全員がそれぞれのサイトで作業している場合、200 の個別の接続文字列を持つことができます。
多すぎる数を調べるにはどうすればよいですか? 問題が発生するまで待ちたくありません。事前に計画を立てておきたいのです。
接続の数は、制限を設けるのに特に役立つリソースではありません。サーバーの負荷は、これらの接続で行われていることにはるかに敏感です。あなたはその知識で何をしますか?制限に達したら接続を拒否しますか?その制限を超えると、ユーザーエクスペリエンスが低下し始めることをどのようにして知ることができますか?
ASP.NET を使用していますか? .NET は、接続プールを使用して SQL 接続を再利用します。本当の問題、直接開かれている接続の数:
select COUNT(*)
from master.dbo.sysprocesses p
join master.dbo.sysdatabases d on p.dbID = d.dbID
where d.name = '<database>'
このステートメントは DAL から呼び出すことができますが、必須ではないと思います。なんで?私は MSSQL 2000 の経験があります。何百もの開いた接続で安定しています。
Web サービスがステートレスである場合 (これは一般的で適切なパターンだと思います)、その接続の問題を回避できます。
ステートフル(永続的にオープンな接続があることを意味します) サービスでは、計画が難しく、設計を再考する必要があると思います。
負荷テスト。
確立したい多くの接続を開く小さなマルチスレッド コンソール アプリケーションを作成し、自分で確認します。各接続が実行するクエリの実行量を決定し、それをテストに含めるようにしてください。テストを実行するときは、db サーバーでパフォーマンス モニターを開き、CPU サイクルを監視します。CPU サイクルのベンチマークが何であるかを把握し、それを超えると答えが得られます。テスト用の db サーバーが、本番環境で実行するサーバーとまったく同じように設定されていることを確認してください。
問題が発生するまで待ってはいけません。あなたの顧客はそれでは満足しません。