•鉄の構成は？
•どのくらいの時間を「プル」する必要がありますか？
•初期データ量はいくらですか？
コントロールショット：「プル」とはどういう意味ですか？
しかし、望むなら、あなたは望んでいませんが、答えなければなりません。 この質問に対する答えを探すのが難しい検索について、私の次の投稿。
何を引っ張っていますか？
私たちの実験は、文書管理システムEVFRAT E1です。 Cognitive Technologies LLCの腸内で過去2〜3年にわたってほぼゼロから作成された完全に新しいシステム。
このシステムには、データベース（MS SQL）、IISベースのアプリケーションサーバー、およびシッククライアントとモバイルクライアントの3層アーキテクチャがあります。 メイン開発プラットフォームは.NET 3.5、メイン言語はC＃です。 よくあることですが、リリースプロセスでは負荷テストに注意が払われましたが、作成されたアーキテクチャの機能を理解するには十分ではありませんでした。 そして、人生で私がこの投稿の主要な質問に答えさせられたとき、ストレステストのためのインフラストラクチャがまだ存在していました。 MS Visual Studioの組み込みツールで作成されました。
中規模サーバー（Windows Server 2008 R2仮想マシン、6 CPU、10 GBのRAM）を含むスタンドを用意しました。このスタンドには、クライアントアプリケーションの動作をシミュレートするテストを備えたデータベース、アプリケーションサーバー、コンピューターが展開されました。 一般的なテストシナリオは、典型的な大規模な組織の稼働日をシミュレートします。 各テストシナリオは、事務処理におけるユーザーの特定の役割を実行しました：レジストラ、ドキュメントおよびルートコントローラー、割り当ての実行者、承認、およびメールを単に読んで利用可能なドキュメントを閲覧したユーザー。
一般的なシナリオでのユーザーロールの割合を図1に示します。 このディストリビューションは、システムの以前のバージョンに関する顧客の小規模なマーケティング調査の後に採用されました。
図1：シナリオの分布
長い議論の末、私たちは「引き寄せる」ことを自分で決めましたか？ これは、上記のシナリオモデルによるサーバーの中断のない操作であり、8営業時間以内にサーバーエラーが発生しません。 同時に、失敗したクライアントテストの割合は0.5％を超えてはなりません（テストのビジネスロジックのエラー、予期しないタイムアウトなどが発生する可能性があります）。 上記のすべての条件が満たされた場合、測定は、同時に接続されたユーザー（テスト）の最大可能数の対象となります。
引き方
解決しなければならなかった次の問題：最適なユーザー数をどのように正確に選択するか？ 多くの8時間の打ち上げを行うことは長くて恩知らずな仕事です。 したがって、8時間の1回の実行に最適なインジケータを取得するために、同時テストの数を動的に変更することが提案されました。 しかし、何に依存しますか？ サーバーの負荷を決定するための多くのオプションがあります：サーバー上のリクエスト処理キュー、クライアント上のクエリ実行速度、エラーテストの数など...
ここでは、詳細な説明をよりよく理解するために、少し余談します。 システムのアプリケーションサーバーは、次の方法でクライアント要求を処理します。すべての要求は1つのキューに到着し、処理を待機します。 あります
カスタムワークフロープール。 この例では、コアあたり12：2でした
プロセッサ。 キュー内の最後のリクエストは最初に送信されます
ワークフローを解放しました。
その結果、一連の実験の後、最適な
この場合のユーザー数を決定するには、ワークロードを測定します
これらのワークフロー。 混雑の時間とアイドル時間の比率として計算され、パーセンテージで表されます。 したがって、50％はワークフローが半分の時間、90％がアイドル状態であることを意味します-ワークフローはほとんど常に読み込まれます。 制御機能は非常にシンプルです。70〜90％以内のワークロードは正常と見なされます。 スレッドのワークロードが70％未満の場合、新しいテストが追加されましたが、90％を超える場合、テストの1つは開始されませんでした。
その結果、何を得ましたか？ この構成のテストの終了時に、最適なユーザー数を示す直線を取得することが理想です。 残念ながら、それは決して「落ち着き」ませんでした。 （図2のグラフを参照）
図2。 最適なユーザー数の自動決定の結果。
8時間のテスト操作の結果：
•データベースサイズ-9719.50 Mb。
•データベース内のドキュメント-4885;
•データベース内の指示-14478。
270ユーザーに等しい平均値からの偏差が小さいことがはっきりとわかります。 これにより、この鉄の構成に対するサーバー負荷の「集中」モードでの最適なユーザー数が決定されたことは明らかです。 当然、実生活では、ユーザーはそのようなシステムで作業することはありません。 より強力な構成での1000人以上の同時ユーザーのパフォーマンスは非常に困難です。
プロセスが非常に長いことをすぐに予約したい テスト中、サーバーの負荷を管理するためのパラメーターが長時間選択され、サーバーとクライアントのエラーが修正されました。
何を引き出しましたか？
システムがどれだけ「プル」するか、または同様の難しい質問に答える必要がある場合は、いくつかの簡単なルールに従う必要があります。
1.タスクを明確に設定します-特定の環境でのアーキテクチャについて何を知りたいですか？
2.正確に何を測定したいのか、この指標はどの値に対応すべきかを正式に決定しますか？
3.修正可能な他のすべてのテストパラメーターを修正します。ハードウェア構成、テストスクリプト、それらの配布など。
4.提起された質問の答えに近づく過程で、他の興味深く予測不可能な研究課題に気を取られないでください。
この一連のルールは、パフォーマンスの測定と改善のタスクを引き受けることを計画している人にとっての出発点と考えることができますが、どこから始めればよいかは明確ではありません。
そして、眼球には、ストレステストに関連する他の「不快な」問題の小さなヒットパレードがあります。
1.「XXXユーザーにはどのサーバーが必要ですか？」
2.「システムに入力できるオブジェクトの数は？ 場所は終わりますか？」
3.「すべてが迅速に機能するために、ネットワークはどの程度の速度が必要ですか？」
4.そして、私のお気に入り：「強力なサーバーを購入したら、それは落ちないでしょうか？」
ご覧のとおり、今後の作業の範囲が提供されます。 Visual Studioツールキットがこれに十分であることを願っています...