こんにちは、私は劉チャオです。
最終講義、私は時間を調整することの重要性を紹介し、彼がパフォーマンステストに言及しました。ますます複雑なシステムの顔は、パフォーマンスのボトルネックを事前に発見され、その後、チューニング戦略を開発することを目標とすることができ、合理的なパフォーマンステストを開発します。
それはこれに沸く「 -分析-テストチューニング」の3つの手順を。
今日、私たちは、「システムのチューニング戦略を作成する方法。」、これに基づいて良いのチャットです
パフォーマンステストレイダース
パフォーマンステストは、システム性能を安定させるために必要な措置を確実にするために早期のパフォーマンスのボトルネックを見つけることです。私はあなたが地表面にポイントからシステムのパフォーマンスをテストするのに役立つ2つの一般的に用いられる試験方法をご紹介しましょう。
1.マイクロベンチマーク
マイクロベンチマークは、正確に性能比較機能ブロックまたは異なる実装における方法に特に適した方法またはパフォーマンス問題のモジュールに配置することができます。例えば、比較方法は、同期と非同期の性能が達成達成するために使用されます。
2.マクロのベンチマーク
Acerは、包括的なベンチマークテスト、口座にテスト環境を取る必要があり、テストシナリオやテストの目的です。
テスト環境ではまず見て、我々は実世界のラインをシミュレートする必要があります。
そして、テストシナリオを見てください。我々は、干渉を作成、また、並行して実行中に他のサービス・インターフェースがあるかどうか、インタフェースをテストするときに決定する必要があります。もしそうなら、してください注意を払う、あなたはこの干渉を無視したら、テストの結果が偏差になりますので。
最後に、検査対象を見てください。私たちの目標は、システムが目標スループットと応答時間かどうかによって測定することができるパフォーマンステストを、持っていることです。非コンプライアンス、それが最適化され、コンプライアンスは、同時テストの数を増加させるためにそうする底TPS（第2最大当たりのトランザクション）インタフェース、インタフェースの性能に缶洞察を続けます。スループットテストインタフェースおよび応答時間に加えて、我々はまた、テストサイクルをインタフェースする必要がある様々な変更、サーバーのCPU、メモリ、およびI / Oの使用状況を観察し、パフォーマンスの問題につながることができます。
これらの詳細な2つのテスト方法があります。これは、干渉因子性能試験があることは注目に値する、テスト結果が不正確になります。だから、
ときに我々は、パフォーマンステストを行うだけでなく、いくつかの問題に注意を払います。
1.ウォームアップの問題
我々はパフォーマンステストを行うと、私たちのシステムは、より速くより速く倍に私たちの最初の訪問の背面へのアクセス速度よりも、より速く、より速く実行されます。これは、それが起こったのかですか？
Javaプログラミング言語および環境の後、.javaファイルを.classファイルにコンパイル、まだ直接の.classファイルのバイトコードインタプリタを実行することはできませんマシンが実行するためにネイティブのマシンコードに変換するバイトコードにする必要があります。コードが最初に実行されている間、メモリと実行効率を節約するために、最初は、インタープリタコードの実装を説明します。
時刻コードの数の増加が実行されると、仮想マシンコードブロックが非常に頻繁にメソッドまたは関数を見つけた場合、これらのコードは、ホットスポットコード（ホットスポットコード）として認識されるであろう。実行時にホットコードの効率を向上させるために、仮想マシンは、タイムコンパイラによって（JITコンパイラ、ジャストインタイムコンパイラ）ネイティブプラットフォームに関連付けられたマシンコードにコード、および最適化のすべてのレベルをコンパイルします各ラン後のコードは、メモリから直接取得する場合、その後、メモリに記憶されています。
だから、運転の初期段階では、仮想マシンは完全に最高のパフォーマンスを行うことができます後ろにコードを最適化するために長い時間がかかります。
これは、ウォームアッププロセスであり、パフォーマンステスト中に、ウォームアップ時間が長すぎる場合、それは最初のアクセス速度につながる遅すぎる、あなたは最適化を考慮して、テストすることができます。
2.パフォーマンステスト結果が不安定
私たちは、パフォーマンステストを行うとき、各処理されたデータ・セットが同じであることがわかったが、テスト結果に違いがあります。これは、そのような異なるマシンの他のプロセス、ネットワーク変動およびJVMのガベージコレクションのすべてのステージ等の影響など、多くの不確実性、とともにテスト、。
我々はテストの数を渡すことができ、試験結果が平均化される、または統計グラフは、限り我々の平均値が妥当な範囲内であるが、揮発性が、この場合には、大きくないように、性能テストが渡されます。
3.マルチJVM影響ケースの下で
弊社のサーバーは、私たちのサーバーが複数のJVMを持っていることを意味違うのTomcatに配備複数のJavaアプリケーションサービスを、持っている場合。任意のJVMは、システム全体のリソースを使用する権利を有します。単一のマシンのみJVM上で展開した場合のパフォーマンステストを行う場合、テスト結果は良い、または非常に良いチューニング結果であるが、マシンの複数の場合にはJVMのかもしれないができません。だから我々は、複数のJVMを展開するマシンオンライン環境を回避しようとしてください。
合理的な分析、戦略策定のチューニング
ここで私は組み合わせ応力の「三段」を分析し、チューニングします。
私たちのパフォーマンステストの完了後、パフォーマンスの出力にレポートをニーズをテストするには、我々は、システムのパフォーマンステストの分析に役立ちます。試験結果は平均値、最大値及び最小テストインターフェースのスループット、応答時間、CPU、メモリ、I / O、ネットワークIO使用率、GCサーバのJVM周波数を含む必要があります。
これらの標準的なチューニングを観察することで、パフォーマンスのボトルネックは、私たちがボトムアップアプローチを分析することによって、問題を見つけることができます、見つけることができます。その後、ボトルネックの原因を見つけるためにログを解析することにより、最終的には異常logコマンドを探し、そして、異常が存在する場合、最初は、オペレーティングシステムレベルから、システムのCPU、メモリ、I / O、ネットワークの使用率を表示し、また、使用可能なJavaアプリケーションのJVMから異常がある場合レベルは、ボトルネックの原因を見つけるために、ログ解析をJVMガベージコレクションの頻度とメモリの割り当てを参照してください。
システムJVMレベル場合と起こる珍しいことではないが、我々は読書やデータのボトルネックを書くというように、そのようなJavaプログラミングの問題などのアプリケーションサービス層ビジネス・パフォーマンスのボトルネックがあるかどうかを確認することができます。
分析の問題を見つけるためには、パフォーマンス上の問題が原因である可能性があり、またはそれはいくつかの理由の一般的な原因の結果である可能性があり、複雑で繊細なプロセスです。私たちは、問題分析、ボトムアップアプローチを用いることもできますし、我々は、システムのパフォーマンスの問題を解決し、レベルの最適化によるトップダウンレベルを使用することができます。私に紹介するオペレーティングシステム層へのダウン、アプリケーション層からのいくつかのチューニング戦略をしてみましょう。
1.最適化されたコード
問題のコードは、アプリケーション層は、多くの場合、暴露システムリソースが不足しているため。例えば、我々はメモリオーバーフローの原因コードの一部を持って、多くの場合、JVMで、メモリのこの時点で枯渇システムメモリのリソースを参照して実行され、また、JVMのガベージコレクションにつながる100％以上のCPUが高につながる、頻繁に発生しますこの時間は、彼らがCPUリソースシステムを消費します。
多くの場合困難であり、最適化するために、私たちの経験に頼る必要性を見つけるためにあなたのコードで問題によって引き起こされる非パフォーマンスの問題がいくつかあります。コンテナは、ループ反復するために使用されている場合たとえば、私たちは多くの場合、LinkedListのセットを使用して、読み取り効率が大幅に削減されますが、システムの性能パラメータの効率の低下は、異常が発生することは困難です。
そして、そこに学生の経験は、あるLinkedListのは、達成するために、リンクされたリストであるので、あなたが要素を取得するために、各サイクルで要素を取得するためにforループを使用している場合は、リストを横断する行く、コレクションループのイテレータ（反復子）繰り返しを使用します。これは読書の効率が低下します。
2.デザインを最適化します
私たちは、コードのデザインビジネス層とミドルウェア層の最適化を支援することができ、オブジェクト指向の設計パターンがたくさんあります。最適化の後、コードを合理化するだけでなく、全体的なパフォーマンスが向上するだけでなく。シーン内のオブジェクトを作成するために、たとえば、シングルトンは頻繁に呼び出しで、あなたはこのように頻繁にパフォーマンスの消費をもたらしたオブジェクトを作成し、破壊削減、共有オブジェクトを作成することができます。
3.最適化
良いアルゴリズムは、私たちは大幅にシステムのパフォーマンスを向上させることができます。例えば、さまざまなシナリオでは、複雑さを低減することができる時間を見つけるために適切なアルゴリズムを使用して。
4.スペースのための時間
時には、システムの速度のクエリは非常に高い需要がありませんが、ストレージスペースの厳しい時に、この時間は私たちが宇宙のために検討する時間を使うことができます。
例えば、私はStringオブジェクトの03インターン詳細な方法で話すだろう、あなたは大幅にメモリ・ストレージ・スペース節約することができ、定数プール、同じオブジェクトを繰り返し使用、に格納されたデータセットの比較的高い繰り返し率することができます。しかし、データ構造のHashMapのタイプを使用して定数プールのために、我々はあまりにも多くのデータを保存する場合は、クエリのパフォーマンスが低下します。だから、これより厳しいストレージ容量の要件、およびクエリの速度でシーンを作るために必要とされていない、我々は時間とスペースのために考慮することができます。
時間のためのスペース
このメソッドは、アクセス速度を向上させるためのストレージスペースを使用することです。今では多くのMySQLデータベース・システムが使用されている、より一般的なサブライブラリーサブテーブルは、時間のためのスペースを使用した典型的なケースです。
MySQLの単一のテーブルので読んで、より千万超えるデータを格納し、書き込み性能が大幅に低下する一方で、そうでない場合は、この私たちはハッシュ値によってテーブルデータにフィールドを必要とする時間または分割し、ハッシュ値判定の条件に基づいて、システムのクエリデータ、テーブルは、データの量を減少させるため、対応テーブルを検索、クエリのパフォーマンスも向上します。
6.チューニングパラメータ
これらはほかに、ビジネス層のコード最適化されて、JVM、のWebコンテナ、およびオペレーティング・システムの最適化も非常に重要です。
独自のビジネス・シナリオによると、JVMのメモリとガベージコレクションアルゴリズムの合理的なセットは、システムのパフォーマンスを向上させることができます。あなたが私たちのビジネスに大多数のオブジェクトを作成した場合、我々は古い時代に直接、これらの大きなオブジェクトを設定することができます。これは、システムのパフォーマンスを向上させ、若い世代はCPU使用時間を減らし、頻繁に発生する小さなガベージコレクション（マイナーGC）を低減します。
WebコンテナのスレッドプールおよびLinuxオペレーティングシステムのカーネル・パラメータを設定することも不合理なシステム性能のボトルネックにつながり、これらの2つの部分は、独自のビジネスシナリオに応じて、あなたはシステムのパフォーマンスを向上させることができます最適化することができます。
システムの安定性を確保するためのフォールバック戦略
言及した全てのトップパフォーマンスチューニング戦略は、システムのパフォーマンスを向上させるための手段ですが、インターネットの急速な発展の時代に、ユーザーが急速にかかわらず、当社のシステムの最適化どれだけの、生成物の量を変更している、または許容限界があるだろうそのため、システムの安定性を確保するために、我々はまた、いくつかの代替戦略を使用する必要があります。
キャッチオール戦略は何ですか？
まず、電流制限は、ポータルシステムに最大限界アクセスを設定します。本明細書で性能試験TPS底インタフェースを指します。ヒューズは成功しませんでしたフレンドリー要求に戻すための措置を取っている間。
第二に、インテリジェント横展開。インテリジェントな横方向の拡張は、トラフィックが一定のしきい値を超えた場合、システムが自動的にオンデマンドサービスで横方向に追加できるようになります。
第三に、展開の先駆け。この方法は、通常、高並行システム、例えば、瞬間的な購買業務システムに適用されます。横展開が成功し、買いが終わっても、多数の要求が瞬時に起こる満たすことができないためです。
現在、多くの企業は、アプリケーションをデプロイするためにドッカーコンテナを使用します。ドッカーコンテナは、コンテナ管理システムとしてKubernetesを使用し、そしてKubernetesインテリジェント横方向の拡張と事前拡張ドッカーサービスを実現することができるからです。
概要
この話の完了は、あなたは、パフォーマンステストを認識し、アップチューニングする必要があります。私たちはもう一度おさらい今日の内容に図によります。
我々は、前者は正確にシステムの性能をテストするためのシミュレーション環境を統合オンライン、内部および外部の要因と組み合わせてもよい、好ましくは小企業の機能ユニットを、調整することができ、ミクロ及びマクロベンチマークに性能ベンチマークをテストします。二つの方法の組み合わせは、より三次元試験システムの性能であってもよいです。
テストの結果は、私たちは戦略のチューニングの開発を支援することができ、チューニング方法は多くあり、ここでは繰り返しません。しかし、そこに一つのことは、共通しているチューニング戦略は、刻々と変化するが、核となるアイデアは同じで、プログラムにチューニングビジネス・チューンからあり、その後、システムのチューニングに。
最後に、あなたはので、新しいバグ、リスクや欠点を導入していないようではなく、チューニング、チューニングのために、チューニングシーン明確に既知の問題とパフォーマンスの目標の両方を結合する必要が頭を与えないように。
質問
あなたは新しい行に、すぐに、責任ある電力供給システムがあるが、また、活動を購入すると仮定し、その後、何あなたがマクロベンチマークそれを行う機能マイクロベンチマークを、行いますますか？
私たちは、コメント領域にあなたの答えを楽しみにしています。あなたは議論するために彼を招待し、今日、彼らの友人に共有するコンテンツを「読むために友人を頼む」をクリックして歓迎されています。
