まず、パフォーマンステストの概念
ストレステスト：ボトルネック（開始にエラー応答）を超えて、システムを識別するためのシステムの性能は、圧力に耐えることができます
負荷テスト：テストシステムは最大圧力の問題ではないが、圧力勾配を増加させます
安定性試験：（所与の圧力よりも大きい）は、特定の圧力条件下で、長時間実行される（7 * 24時間）、システムは問題ありません
性能試験：所定の（同時）条件で、テストシステムのスループット、応答時間
いくつかの誤解：ユーザーの数？=オンライン？同時ユーザーの数=、オンラインの数、同時= 100：10：1
第二に、注目の性能試験の指標
同時に、平均応答時間、スループット
三、JMeterのツール導入（）
1、生産のスクリプト
1）記録、2）手動で書き込み
2、再生
リスナーを追加します。3.
1）結果ツリーを確認してください; 2）サマリーレポート
4、パラメトリック
1）CSVのデータ構成の設定。
2）構成要素 - >ユーザー定義変数。
3）試験計画 - >ユーザー定義変数。
4）正規表現の抽出
5、アサーションを設定します
6、同時セット
7、こうした視聴結果の数として、リスナーはリソースを大量に消費オフ
8、他の（待機時間、ループコントローラ、スニファなど）
四、JMeterのツールの高度な使い方
図1に示すように、圧力勾配
図2に示すように、分散圧力測定
3 Beashell Samper
4、引用外部Java包
5、デバッグサンプラー
6、拡張
7、唯一の詳細なエラー情報要求を保存
第五に、パフォーマンス・テスト・ケース・プレゼンテーション
1、UAC-usercenterログインインタフェース：
1）試験）2000（2-5-8コンカレント。
2）サーバのパフォーマンス監視ツールのAPMの影響を追加します。
3）性能要件：スループット複雑3000（3000 1秒の平均応答時間）
2、パフォーマンスの最適化プロセス
1）データベースからのRedisに読み出したデータからデータを読み取ります。
2）プログレッシブコード解析および最適化（@Transactionalアノテーションを削除、重複判定を減らします）。
3）は、2つから4つのコンテナの数の増加、およびその後6に増加し、
4）接続の数は16、32、16、8からのRedis
3、パフォーマンス分析は、成果物を紹介APM
1）CPU 2）メモリ3）IO 4）ネットワーク5）スレッド
6）時間のインターフェースのそれぞれの統計的特性に応じて、試験中、及び図表。
各インタフェースの応答時間をより詳細に示す7）スプリット（処理された各方法の精度）
第六に、パフォーマンステストの経験が（A）
1）プロジェクトの高い性能要件を、それぞれの方法、コードの行を変更する、我々は再びパフォーマンス、性能データ、再試験、それに影響を評価しなければなりません。
2）多くの場合ではない、完全に一貫した応答時間、単一のユーザーと多数の同時を加工。
3）明白な欠陥のないコードは、最初のデータベースのパフォーマンスの最適化、続くキャッシュを考慮する場合には、最適化されたコードは、最後の内部ロジックです。
七、解決すべき問題をテストし、パフォーマンス
JARパッケージをエクスポートするMavenのコマンドを使用して1は、他のプログラムで参照することはできません。
2、同時テストは、ランダムな待ち時間を追加した後、平均応答時間が劇的に減少している、私は理由を知りません。
図3は、並流のシナリオに合わせて、さまざまな事業を設定するにはどのような良い方法は、同時と異なるビューの数が異なります。