大規模な多層アプリケーションを開始したいと考えています。サーバー側アプリケーションは、同時に 1000 人を超えるユーザーに応答する必要があります。サーバーアプリは64ビットコンパイラで、クライアントサイドは32ビットで作りたいです。この場合、DataSnap がすべてのクライアントに問題なく応答できるかどうかわかりません。この場合、サーバー コンピュータは非常に強力 (マルチプロセッサと 16GB 以上の RAM) で、データベース管理システムは FireBird 2.5 です。
3 に答える
現実的な負荷テストを実行する方法が必要です。
Firebird データベースの場合、無料の Apache JMeter ツールを使用して同時ユーザーをシミュレートできます。SQL ステートメントを実行し、実行時間の統計 (平均、最小/最大など) を記録できます。したがって、たとえば、20 の異なる SQL クエリを持つスレッド グループを作成し、それぞれがこれらのクエリを順番に実行する 20 のスレッドを実行できます。
JMeter では、SQL クエリの時間制限を定義できます。クエリがこの制限を超えると、JMeter はそれをエラーとして扱います。次に、全体的なエラー率がまだ (たとえば) 5% 未満である最大クライアント数を見つけようとすることができます。
ただし、予想されるデータベースの負荷がどの程度になるかを知る必要もあります。また、数レコードだけでなく、現実的なサイズのテスト データベースも必要です。また、レポートなどの一部のデータベース クエリは、より高い負荷を引き起こす可能性があります。これらも、全体的なパフォーマンスに影響を与える可能性があるため、シミュレーションに含める必要があります。JMeter では、異なる設定 (あまりシミュレートされていないクライアント) で実行時間の長いステートメント用に、最初のスレッド グループと並行して実行される 2 番目のスレッド グループを作成できます。
データベースをテストすると、この領域にすでにボトルネックがあるかどうかがわかります。たとえば、テスト結果は、データベースが合計平均トランザクション レート 20 TPS (1 秒あたりのトランザクション) で 20 のクライアントにサービスを提供できるということです。これは、1 つのクライアントが 1 秒あたり 1 つのトランザクションを実行することを意味します。ただし、この TPS 値は、ユーザー数が増えると減少します。
関連する質問: http://www.firebirdsql.org/en/case-studies-catalog/へのリンクもある大きなプロジェクトでの Firebird の使用
DataSnap クライアントの負荷シミュレーションについて: これは、スクリプト化されたクライアントを使用して実行できます。これは、接続を介して定義済みの一連のステートメント/コマンドを実行します。多数の負荷テスト クライアントを同時に実行するには、Amazon Elastic Compute Cloud ( EC2 ) などのサービスを使用してテスト マシン イメージのクローンを起動し、ハードウェア コストを節約できます。しかしもちろん、10 つか 20 のスクリプト化されたクライアントを実行するだけの小さなクライアント マシンから始めます。
私の知る限り、DataSnap は Indy をベースにしています。また、Indy の接続処理モデルはスケーラブルではありません。接続ごとに 1 つのスレッドであり、リソースを大量に消費します。Indy のスレッド プールを使用することさえ選択肢ではないと思います...たとえば Windows (32 ビット) では、作成できるスレッドの最大数に制限があります (2000 IIRC)。とにかく、多くのスレッドを使用することは良くなく、サーバーのパフォーマンスに影響を与えます (参照用 - Windows Internals book、Windows Performance Team blog など)。
スケーラブルで堅牢なプロフェッショナル アプリケーション サーバーは、データ処理に IO Completion ポート (IOCP) を使用します。しかし、DataSnap がそれを利用できるかどうかはわかりません。
更新: CodeRage7 で同様のスケーラビリティに関する質問をしました。答えは次のとおりです。
Q:最近、DataSnap のスケーラビリティ/パフォーマンスについて StackOverflow に質問がありました。DS は、ネットワークおよびアプリケーション レベルで、たとえば 2000 人以上の同時ユーザー リクエストを処理できますか?
A:スケーラビリティは、TCP/HTTP/HTTPs のスケーラビリティと、サーバー オペレーティング システムで許可されている接続数に基づいています。また、使用するメモリとハードウェアに基づいています。DataSnap には特定の制限はありません。
私のコメント:これは事実ですが、Indy の接続処理モデル、つまり接続ごとに 1 つのスレッドは、特に 32 ビット Windows (最大 2000 スレッド) でボトルネックをもたらします。Win64 ではそれほど問題にはならないはずですが、この種のデータ フローの処理はパフォーマンスの低下につながります。
Q: DataSnap はある種の負荷分散をサポートしていますか?
A:直接ではありません。これは、DataSnap サーバーのコードで行うことができます。
私のコメント: Andreano Lanusse のブログで、DataSnap でのフェイルオーバー/ロード バランシングの実装に関する非常に優れた論文を見つけました。
Q: DataSnap はスケーラビリティを向上させるために IO Completion ポートをサポートしていますか?
この私の質問は未回答のままでした。
お役に立てれば!
更新 2:
DS Performance に関する非常に興味深い投稿を見つけました:速度と安定性テストに基づく DataSnap 分析
更新3:
システムの仕様を作成するとき、それが複数のユーザーに関するものである場合、非常に正確である必要があります。
例: Web サイトを作成し、クライアントが 15.000 のユニーク ユーザーを期待しているとします。その後、クライアントは通常、システムが 15,000 人の同時ユーザーをサポートする必要があるという要件を提示しますが、これは非常に単純です。
それよりも詳細な仕様が必要になります。
通常、次のように言う方が賢明です: 99% のリクエストで、99% のユーザーが平均 5 秒以内にリクエストへの応答を得ることができます。
通常の使用では、すべてのユーザーが同じ秒内にリクエストを送信することはありません。ある時点でそれらがすべて同じ分以内に到着した場合 (これも非常にまれです)、同時ユーザー数が大幅に少なくなります。
何万人ものユーザーがいて、そのほとんどが毎日接続している Web サイトでさえ、Web サーバーはほとんどの場合アイドル状態であり、時々 5% に、極端な場合には 20% に跳ね上がります。これらすべてのユーザーに一度にサービスを提供する必要がある場合は大変なことになりますが、それは決して起こりません。そのような負荷に対してサーバーを準備するのは現実的ではありません。