研究の需要 - デザインシーン - 製造スクリプト - 環境を準備 - コンフィギュレーションのための - 最適化の提案
私たちは皆知っているべき測定圧力：
1.圧力試験シナリオ、ユーザーの行動
2.圧力測定サービスの設定：
ネットワークの圧力を感知監査、使用可能なメモリ、ネットワーク帯域幅（レート=アップロードおよびダウンロードネットワークの帯域幅/ 8）、（なし帯域幅の制約、制限や部屋のドアに動作しないのと同じである）、外部圧力センシングネットワーク（帯域幅の制限があります）
3.アプリケーションサーバ、データベースサービス：
例えば、MQサーバーのCPUのキャッシュが高すぎる、または高すぎる彼は、衰退を遅らせることMQサーバーのCPUを入れて、それがこのような高いCPUなどの不要なアプリケーションの数を減らし、あまりにも多くのものを置くMQを示している可能性があり、あなたは、ブロードバンドを高める20キロバイトの元の50キロバイトから追加することができ、サーバーのダウンロードブロードバンドが小さすぎると、カーネルパラメータを調整することを検討します。
重要：そのサーバーのリリースの特定のアプリケーションがハングアップした場合は、このビジネスを入力するには、このアプリケーションは、次のような機能を麻痺させ、ビジネスの損失につながることができ、これは物事の負荷ではありません、麻痺されます。注文入力MQが、対応するMQこのサーバは、ビジネスが欠落している場合でも、その後、注文処理をハングアップ、それはプログラムの負荷がそのサーバーノードを入力するために何時どのような状況の下でどのように明確にする必要があり、サーバーは前方に置く勧告を配布しています。
4.各アプリケーションを理解します：
各アプリケーションは何をしているのですか？彼らは何をやっていることを特徴としていますか？彼らは、これらのリソースを消費することを行いますか？（例：メモリのより多くの消費量は、それらを食べるブロードバンドに比べて、それらを消費CPUとの比較します）
5.分析インデックス：
CPU、メモリ、および変曲点でのその他の変更、サーバはやって？
最悪の状態どのくらいのCPU使用率の到着時間/最高の状態を達成するために最善/最悪の状態、キャッシュ、IOとそんなにあります
すべての指標間の関係を理解し、スループット（TPS）、だけでなく、いくつかの応答時間：重合を報告します。
6.最適化のヒント：
CPUが高すぎる：カーネルパラメータを調整します
メモリが高すぎる：メモリ、タスク分配比調整を増やし、小さな調整
KB /秒を受けた： 改善し、ネットワークの帯域幅を広げ、帯域幅の上限に達した：率=アップロードとダウンロードのネットワーク帯域幅/ 8
アプリケーションサービスの展開アーキテクチャは：例えば、MQサーバーのCPUのキャッシュが高すぎる、または高すぎる、彼は落ちるかもしれない遅いMQサーバーのCPUを入れて、それはあまりにも多くのものを入れて、MQ、不要なアプリケーションの数を減らすことを示している可能性があり
重要：そのサーバーのリリースの特定のアプリケーションがハングアップする場合は、この事業に参入するには、このアプリケーションは、次のような機能を麻痺させ、ビジネスの損失につながることができ、これは物事の負荷ではありません、麻痺されます。注文入力MQが、対応するMQこのサーバは、ビジネスが欠落している場合でも、その後、注文処理をハングアップ、それはプログラムの負荷がそのサーバーノードを入力するために何時どのような状況の下でどのように明確にする必要があり、サーバーは前方に置く勧告を配布しています。
最適化SQL、データベースの最適化：SQLクエリをスロー。
コードの冗長性：オプティマイザ。
7.実際には、我々は、上記のこれらの指標ごとに場所を彼らのボトルネックシナリオで見えるように設計されていることができます
、TPS：秒あたりのトランザクション（毎秒送信されるものの数の処理）、すなわち、第2のサーバプロセスごとのトランザクションの数。TPSは、データベースにアクセスするためのメッセージにメッセージ及びプラス一人のユーザを含みます。（平均当たり×TPS = CAPSは、TPSを呼び出します）
TPSは、測定ソフトウェアのテスト結果の単位です。トランザクションは、クライアントのプロセスは、サーバーおよび対応するサーバーにリクエストを送信しています。クライアントは、使用時と完了したトランザクションの数を計算するために、サーバの応答を受信した後、送信開始タイミング、終了タイミングを要求します。
一般的には、性能評価システムの数を測定するために、毎秒技術取引を終えています。システム全体としては、最小値TPS処理パワーモジュールの処理能力に依存します。
二つは、QPS：ドメインネームシステムサーバマシンのパフォーマンスは、多くの場合、毎秒のクエリを測定するために使用されるように、第2の割合あたりQPSクエリは、インターネット上で、処理フローのどのくらいの指定された時間内に特定のクエリ・サーバの尺度です。
すなわち、毎秒の要求に応じて、すなわち、最大スループットであり、フェッチ/秒に相当します。
ここではTPSで測定された圧力が増大しない理由について話をします：
1、ネットワーク帯域幅
ストレステストでは、時にはあなたは、単位時間に通過した場合、ユーザー要求の多数をシミュレートするパケットである大きすぎる、伝送帯域幅の容量を超えて、それは間接的に、ネットワークリソースの競合を引き起こすの数で受信したサービス要求につながりますエンドキャップのサービス処理能力よりも少ないです。
2、接続プール
待つための要求が生じ、あまりにも利用可能な接続の数。一般に（Tomcatなど）サーバ接続プール接続プールとデータベース接続プール（または接続の最大許容数がOKであると理解されている）に分割されます。
（接続プールの詳細については、以前のブログを参照してください：パフォーマンステスト：コネクションプーリングとスレッド）
3、ガベージコレクション
エデンとサバイバー分野の新世代が頻繁にマイナーGC、も回収老齢フルGCを実施した場合のためにJavaスタックメモリのTomcatなどの一般的なアプリケーション・サーバは、動的に割り当てられていることから、回復メカニズムは、特定のアルゴリズムに基づいていますより頻繁に、そして、TPS
ガベージコレクションは、独自のリソースの一部を取り上げるのでまた、一定の影響力を持っています。
4、データベース設定
要求データがデータベースに書き込むための時間を必要とし、複数のテーブルが書き込まれる、そうでない場合は、データベースへの接続の最大数、またはデータSQLを書き込む場合に高い並行性は、何のインデックス変数が結合しない、またはマスターから分離されていません、分離を書き、
データベースのトランザクション処理につながるTPSに影響を与え、遅すぎます。
図5に示すように、通信接続機構
シリアル、パラレル、長い接続、配管接続等、異なる接続に影響を与えるだけでなく、間接的TPSです。
（接続に関する協定、以前のブログを参照してください：HTTPプロトコルの拡張：接続管理）
6、ハードウェアリソース
CPU（設定、使用方法、など）、メモリ（占有率）、ディスク（I / O、ページ・スワッピングなど）を含んでいます。
7、プレス
ユーザの要求をシミュレートする必要がその負荷の制限を超えた場合の例のJMeter、スタンドアローンの限定された負荷容量についても、間接的にTPS（その単一の負荷の問題を解決するために、分散圧力試験の必要性について、この時間）に影響を与えます。
8、圧力テストスクリプト
または、例えばjemterでは、職場の同僚に遭遇する前には、要求のシミュレーションの最大数が不十分なスレッドで、その結果、スレッドの数を超え、圧力試験を強化されました。
ある意味を表現したい、この理由を言及：時々、テストスクリプトの設定パラメータやその他の要因も、試験結果に影響を与えます。
9、ビジネスロジック
低トラフィック、より複雑なのデカップリングは、トランザクション全体が発生した行の問題を長くします。
10、システムアーキテクチャ
こうしたキャッシュ、キャッシュサーバの設定、キャッシュヒット率、キャッシュとキャッシュの有効期限の浸透などがあるかどうかなどのサービスは、テスト結果に影響を与えます。
PS：パフォーマンスのボトルネック分析だけではなく地元の分析から、問題の多次元分析、一緒にします。上記のいくつかは、参考のために、そこに存在しないか、不適切に記述されてもよいです。。。
正確ではないがあれば、私のコメントを修正してください、ありがとうございました！