まず、パフォーマンステストプロセス：
全体的なプロセス：要件収集 - >テスト環境をセットアップする - >デザイン・パフォーマンス・テスト・シナリオ - >開発テストスクリプト - >テストの実行 - >収集データ - >分析とレポート
1、要件収集：
- ときにパフォーマンステストの終わり？パフォーマンステスト期間はどのくらいです
- パフォーマンステストは、内部および外部のリソースを必要とします
- デザインのテスト環境は、テスト環境では、これは時間がかかるかもしれことなど、実際の環境と一致し、できるだけ多くの注意を必要とし
- コードのパフォーマンステストの各ラウンドが変更されるべきではないことを確認するためのコードフリーズ処理、
- テスト環境は、他の人のテスト環境を使用していないことを確実にするためにのみ性能試験、換言すれば性能試験として使用されていることを確認する工程
- パフォーマンステストの目標を決定します。一般的にはプロジェクトリーダーの拍子木を必要とします
- コアの使用例ことを確認しました。あなたはコアユースケースを把握していない場合はコアユースケースでは、ドキュメントのユースケース、およびレビューを確認した後、可能な限り、コアビジネスから来ている必要があり、有用な作業性能試験になる可能性があります
- それは独立した事業であるため、テストケースの一部は、（そのようにログや検索など）を別々に監視する必要がある（マイクロサービス？）
- （その後、少なくとも事前にいくつかのテストユーザーを作成するには、そのようなマルチユーザのログインなど）の入力、対象とテストデータのユースケースを確認して、テストデータは、アカウントへのデータのセキュリティと機密性を取って、真と可能な限り正確です
- 負荷モデルの決定
- そのような仮想ユーザーの数などの設計・テスト・シナリオは、ユーザーが時間、走行速度などを考えます
- テストは、サーバーとネットワークの主要なパフォーマンス指標の下でシステムを決定
- 一般試験報告書の形で、出力性能テストを決定する、ベストプラクティスは、テストレポートテンプレートを形成することです
- パフォーマンス欠陥決意のプロセスフロー
2、テスト環境を設定します。
- 環境を設定するにはもう少し時間を最大化
- 展開モデルを考えてみましょう。例えば、異なる環境を取得するように構成することができる環境を作ってみます
- スタブ外部リンクを考えてみましょう
- 時々、私たちは十分な大きさの負荷を生成する必要があるため、自分の負荷生成能力を考えてみましょう
- 適切なシステムの展開を確認してください
- 十分なサポートおよびソフトウェアを提供するために、システムのライセンス
- 設定と展開のパフォーマンステストツール（分散）
- 展開の監視ツール
3、デザイン・パフォーマンス・テスト・シナリオ：
- 試験タイプ（基準容量、分離、ストレス試験、安定性）
- 時間や実行速度を考えて
- 各ユースケースの負荷を決定します
- 各ユースケースの負荷モデル（最大同時、ランプアップ、混合モード）を決定
- 右側の出口のパフォーマンステストをしてみましょう（実行時間まで、繰り返しが行わ達成、データが完成し、消費、その十分なデータを確実にするために準備する必要があります）
- 異なる帯域幅をシミュレートする必要があります
- バックグラウンド監視戦略を決定します
- ブラウザのキャッシュを無視する必要があります
4、テストスクリプトの開発：
- セッションデータの決定：セッションデータは、トランザクション全体の把握がより困難に何回で、事前にセッションデータや対象データの使用を決定する必要があります
- 入力されたデータを決定します
- 持参再生パフォーマンスに必要なスクリプトを決定する追加の変更：プロジェクトの必要性に作成された例のwordpressのポストのためには、コードの後ろを変更します
- 正しく再生スクリプトのパフォーマンスを確認してください：シングルユーザー、マルチユーザー
5、パフォーマンステストの実行
二、APDEX
システムのパフォーマンスを決定するためにどのように良いか悪いですか？分析直感的には、応答時間によりシステム性能の品質に基づくことができます。応答時間が短い場合は、のようなシステムのパフォーマンス、応答時間が長いのに対し、システムのパフォーマンスが悪いです。しかし、次のような問題があります。
- 私は、特定のユーザーの応答時間に満足しているかわからない、またはそれになります、またはそれは立つことができないことです。
- システム性能を測定するための平均応答時間は、問題があるだろう、おそらくシステムの応答時間の多くのユーザーが存在する非常に高いユーザのこの部分の平均応答時間よりも、システムが耐えられない、完全に利用不可能です
- それはあなたが2秒をレンダリングするためのインタフェースが必要な場合、それは明らかに非現実的である、そして、モバイルアプリケーションであれば、このようなユーザーの2S内のWebアプリケーションの応答時間などの様々な用途有する異なる応答時間は、おそらく許容可能です。
APDEXは、上記課題を解決するために表示され、APDEXの支持者は、良いか悪いパフォーマンスを記述するためのより良い方法があるはずだと思います。APDEXは、0と1の間の値に全てのユーザ応答時間を変換し、0 1は、すべてのユーザーの満足度ことを示し、どのユーザーの満足度を示していません。
図2は、最初の応答時間を決定し、各ユーザが許容時間Tであり、ユーザは、時間Fに耐えることができません
- 満足（満足）：システムの応答時間が少ないT未満であれば、良好なシステム性能であると考えることができます
- 容認（許容）：Tが少ないシステムの応答時間よりもFよりも大きい場合、システム性能が容易であると考えられています
- イライラ（短気期間）：システムの応答時間がFよりも大きい場合には、システムの性能は耐えられないと考えることができます
1、公式：
すべての要求に加えて許容の半分の数の数に満足していること、この式手段は、すべての要求の数、apdexの得られた値で割った要請しました。
2、例：
100個のサンプルがあり、我々は12S、3S-12Sとの間に30個のサンプル、60個のサンプル未満3Sより、= 12秒FをT = 3Sを定義し、以下のように値apdex次いで、他のサンプルよりも大きいです。
詳細：クリック
三、Linuxのパフォーマンス指標
Linuxはオープンソースのオペレーティングシステムを作成するために、世界中の開発者間のコラボレーションです。Linuxのソースコードは、インターネット上で自由に利用できるようにし、GPL（GNU一般公衆利用許諾契約書）プロトコルを使用して自由であることができます。