ソフトウェアパフォーマンステスト、分析、チューニングへの道practice_reading notes（2）

第1章パフォーマンステスト、分析、およびチューニングの基礎

1.5パフォーマンス分析とチューニングモデル

パフォーマンステストは、パフォーマンスインジケーターの取得に加えて、パフォーマンスのボトルネックとパフォーマンスの問題を見つけて、パフォーマンスの問題とパフォーマンスのボトルネックを分析および最適化することを目的としています。従来のソフトウェアモデルとインターネットの特性を組み合わせて、パフォーマンスチューニングモデルを次の図に示すように要約します。

ネットワーク配信

ネットワーク配信は急速に発展しているインターネット時代であり、ネットワークの混雑を緩和し、ユーザーの要求に迅速に対応するために一般的に使用されています。一般的に使用されるテクノロジーは、ネットワーク配信CDN、コンテンツネットワーク配信、世界中に展開されているエッジサーバーへの依存、および負荷分散です。中央プラットフォームを介して、オリジンサーバーのコンテンツ配信、スケジューリング、およびその他の機能モジュール。これにより、ユーザーがオリジンサーバーにアクセスするたびに応答を受け取るのではなく、世界中のユーザーが必要なサービスを近くで受けることができます。オリジンサーバーのコンテンツ更新は、ネットワーク全体のすべてのネットワークノードに同期されます。同じリソースにアクセスする人はキャッシュされ、最も近いエッジノードに同期されます。リージョン内の他の人がリソースにアクセスすると、それが取得されます。 CDNキャッシュサーバーから、オリジンサーバーへの負荷を軽減します。Webサイトのパフォーマンスを向上させます。

ウェブサービス

Webサーバーは、Webサービスをデプロイするために使用され、要求の応答と配布、および静的リソースの処理を担当します。

Webキャッシュ

Html、Css、画像などの静的リソースファイルを一時的にキャッシュするために使用されるWebサーバーキャッシュ

アプリケーションサービス

アプリケーションプログラムは、外部サービスのコアプログラムまたはサービスを提供するためにアプリケーションサーバーにデプロイされます。アプリケーションサーバーはTomcat、WildFly、通常のJavaアプリケーションなどであり、アプリケーションサービスはユーザーがアクセスできるサービスを提供します。

キャッシュ 

アプリケーションキャッシング、アプリケーションレベルのキャッシングサービスには、通常、Redis、MemCachedなどが含まれます。キャッシングは、高い同時実行性のパフォーマンスを大幅に向上させることができ、分散アプリケーションアーキテクチャでよく使用されるテクノロジです。

外部システム

ほとんどのシステムは、外部システムまたは内部マルチモジュールの相互作用またはデータ情報を要求する必要があります。これには、Http接続の作成が必要であり、サーバーリソースを消費し、パフォーマンス分析の焦点でもあります。

データベース

データベースは、システムパフォーマンスのボトルネック、クエリの遅延、またはロックスレッド操作データベースのデッドロックなどである可能性があります。

1.6パフォーマンス分析とチューニングのアイデア

1.6.1層化分析

 階層的分析とは、システムモデル、システムアーキテクチャ、およびコールリンク層に応じた監視、分析、およびトラブルシューティングを指します。階層的分析には、システムアーキテクチャと要求処理のプロセスに精通している必要があります。各層でChekListを確立する必要があります。 、1つずつ。レイヤー分析は非効率的ですが、ボトムアップまたはトップダウンのパフォーマンスの問題がさらに見つかる可能性があります。

テストされたシステムについて考慮すべき質問：

1. CPU消費量はどれくらいですか？頻繁に変動しますか？コンテキストの切り替えは頻繁ですか？ハード割り込みが多すぎませんか？
2. メモリ消費量はどれくらいですか？ゆっくりとした上昇はありますか？リリースされますか？どのくらいの仮想メモリが消費されますか？
3. I / O消費量は多いですか？I / O待機はありますか？
4. ネットワーク帯域幅はどれくらいですか？ネットワークスループットとは何ですか？
5. キャッシュ：キャッシュヒット率？キャッシュのエージングタイム？十分なメモリがありますか？接続は十分ですか？接続がリークしていませんか？完全なログ？redisの遅いログ
6. データベース：クエリが遅い？データベースオフィスは待っていますか？データベースキャッシュヒット？データベース接続はいくつですか？接続がリークしていませんか？接続プールに十分な接続がありますか？データベーステーブルの監視、クエリは全表スキャンですか？またはインデックスクエリ？データベースはスレッド競合を実行しますか？
7. アプリケーションサービス：スレッドセーフですか？スレッドのステータスは常に実行されていますか？スレッドはブロックされていますか？デッドロックはありますか？gcは正常ですか？フルgcが頻繁に発生しますか？接続はいくつあり、接続はどのくらいの期間解放されますか？漏れますか？
8. サービスの負荷分散は均等に分散されていますか？TCP接続はいくつありますか？接続はどのくらいの期間解放されますか？
9. 外部サービスの応答は非同期ですか、それとも同期ですか？シミュレーション機器を使用しますか？

1.6.2科学的議論

問題を見つける-問題の仮説-予測-検証と議論-分析-問題を見つける

これは、パフォーマンスの問題を分析し、推測し、検証し、

1.6.3問題の追跡と要約

問題の追跡：このテストのパフォーマンスに以前よりも大幅な変化がある場合は、システムまたは環境の最近の変化を追跡する必要があります。通常、オンラインの製品バージョンまたは環境の変化によって引き起こされるパフォーマンスの問題に使用されます。 。ダウンストリームトラッキングは通常、問題を見つけることができます。

導入と要約：特定のパフォーマンスのボトルネックまたはパフォーマンスの問題が発生した場合は、過去に要約された知識と経験に基づいて1つずつ確認してください。

1.7パフォーマンスチューニングテクノロジー

1.7.1キャッシュチューニング

急速なインターネット開発の時代において、ユーザーアクセス要求の応答時間を改善するために、キャッシングの使用は多くの大規模システムまたはeコマースWebサイトで使用される重要なテクノロジーになりました。キャッシングの合理的な設計は、同時実行に直接関係しています。システムまたはWebサイトのアクセス機能とユーザーエクスペリエンス。キャッシュは、ストレージの場所に応じて、クライアント側のキャッシュとサーバー側のキャッシュに分けられます。

キャッシュは通常、メモリ内のデータを読み取ります。これは、mysqlやoracleよりもはるかに高速です。キャッシュはクエリを実行する前にデータベースにアクセスしません。

キャッシュチューニングの要点：

1. キャッシュヒット率を高くするにはどうすればよいですか？
2. キャッシュの侵入を防ぐ方法は？
3. キャッシュのエージングタイムを制御する方法は？
4. 低速ログ分析、接続番号監視、メモリ使用量監視など、キャッシュを監視および分析する方法。
5. キャッシュのなだれを防ぐ方法は？キャッシュアバランシェとは、キャッシュサーバーのダウンタイムを指し、キャッシュ内のすべてのデータが失われるため、データベースから直接データを取得する必要のある多数のリクエストが発生します。これにより、過度のプレッシャーによりデータベースがクラッシュします。データベース。
6. キャッシュの内訳？

1.7.2同期から非同期への応答

同期リクエストとは、リクエストを受信した後、リクエストが処理されない場合、結果は返されず、処理が完了するまで応答結果は返されません。プロセッサは要求を受信すると、ビジネス1とビジネス2の完了を待ってから、結果を返します。

 

非同期要求とは、システムが要求を受信した後、要求が処理された直後に要求を呼び出し元に正常に返し、要求が処理された後に非同期で呼び出し元にプッシュするか、呼び出し元に要求結果を再度取得するように要求することを意味します。一定の時間が経過した後。

同期から非同期は、主に同期要求のブロックと待機の問題を解決するためのものです。ブロックされて待機しているリクエストは、リクエスト接続をすぐに解放できず、同時実行性の高い処理中に接続が不十分になることがよくあります。リクエストプロセッサは、キューを介して非同期でリクエストを受信した後、分散並列処理を実行して処理を実行します。容量の拡張。また、ネットワーク接続も迅速に解放できます。現在の一般的な処理方法は、受信したメッセージを最初にKafkaメッセージミドルウェアに送信し、次にクライアントメッセージに非同期で応答し、次に非同期でKafkaメッセージを使用してビジネスを処理することです。

1.7.3分割

分割とは、システム内の複雑なビジネスコールを複数の単純なアプリケーションに分割することです。一般に、次の原則に従います。

1. 同時実行性の高いビジネスリクエストとコールの場合、単一のサブシステムアプリケーションに個別に分割されます
2. 同時訪問数が類似しているビジネスの場合、製品ビジネスに応じて分割でき、同じタイプのビジネスはバックエンドサービスです。

注意点：マイクロサービスの分割には慎重な検討が必要です。分割に関連するサービスには、データ交換、内部通信、相互依存などが含まれるため、運用と保守のコストと開発と保守のコストが大幅に増加します。分割もすべきではありません。詳細ですが、チームは組織構造、管理モードなども考慮してください。

上の図に示すように、同時実行性の高いビジネスがサブシステムによって個別に処理される場合、類似のビジネスをマージしてシステムの同時実行性を向上させることができます。この分割の利点は、同時実行性の高いビジネスがパフォーマンスに影響を与えないことです。システムをハードウェアで拡張する場合、リソースの浪費を回避するために、ターゲットを絞った方法でシステムを拡張できます。同時に、システムにはルーティングサービスも必要です。ルーティングサービスは、さまざまなサービスを区別し、さまざまなサブシステムにサービス要求を配信するための統合された入り口として機能します。ルーティングサービスは、統合されたビジネス認証サービスと統合された要求、応答処理、またはビジネス統計やその他の機能を実装することもでき、サブシステムによるパブリック処理を回避し、サブシステムがビジネス関連の問題に集中できるようにし、サブシステムの処理能力を向上させます。

1.7.4タスクの分解と並列計算

タスク分解と並列計算とは、タスクを複数のサブタスクに分割し、複数のサブタスクに対して並列に計算処理を実行し、最後に並列計算結果をマージして返すだけでよいため、処理の目的は並列処理による計算方法です。処理パフォーマンスを向上させます。マルチスレッドは、並列計算を実現し、並行処理機能を向上させるために使用されますが、データを共有するスレッドのスレッドセーフに注意を払う必要があります。

タスク分解方法1：

タスクの内訳2：

 

1.7.5インデックスとサブデータベースのサブテーブル

インデックスはアプリケーションプログラムを指します。クエリを実行するときは、データベースインデックスクエリを使用してください。データベーステーブルを作成するときは、クエリ条件フィールドに適切なインデックスを設定してください。ここでは、適切なインデックスを強調する必要があります。インデックスが設定されていない場合適切に、それはクエリ効率に影響を与えないだけでなく、逆に、ヘルプはインデックスが確立されているため、データを挿入するときにデータベースを遅くし、データベースはデータを挿入するときにインデックスを自動的に更新します。データベースを挿入するときのリソース消費。たとえば、データベースのフィールドはstatusであり、statusの値は0,1,2のみです。statusにインデックスを作成する場合、この値には0の3つの値しかないため、クエリの効率は向上しません。 、1、2、および値の範囲が小さすぎる、インデックス作成後のステータスに従って検索する場合、スキャンする必要のあるデータの量は依然として非常に多いです。

正しいインデックスを使用するとクエリの効率を大幅に向上させることができますが、テーブルのデータが非常に大きく、数億のレベルに達すると、この時点でインデックスクエリも非常に遅くなり、データの挿入も非常に遅くなります。このとき、データをテーブルまたはサブデータベースに分割する必要があります。サブデータベースとは、通常、データベースのストレージ容量がすでに非常に大きく、クエリおよび挿入時のI / O消費量が非常に大きいことを意味します。時間の経過とともに、データベースを2つのライブラリに分割して、読み取りおよび書き込み中のI / Oを削減する必要があります。

サブデータベースサブテーブルの一般的な方法は次のとおりです。

• ホットデータとコールドデータの分離方法では、使用頻度の高いデータをホットデータ、クエリ頻度の低いデータをコールドデータと呼び、コールドデータとホットデータを分離した後、ホットデータを別々に保存するため、データ量が減り、データが照会されるため、パフォーマンスが自然に向上し、ホットデータに対して個別にI / Oパフォーマンスチューニングを実行する方が便利です。
• 時間ディメンションに応じて：リアルタイムデータと履歴データはデータベースとテーブルに分割され、年/月の時間間隔に応じてデータベースとテーブルに分割できるため、各データベーステーブルのデータ量は次のように削減されます。可能な限り
• データベースの操作方法によると：データベースの読み取りと書き込みの分離、クエリ操作と書き込みの分離操作、読み取りと書き込みの分離はマスターサーバーで変更され、データはスレーブサーバーに同期され、スレーブサーバーは読み取りデータのみを提供できます、データの書き込みではなく、バックアップを実現すると同時に、データベースパフォーマンスの最適化とサーバーセキュリティの向上も実現しました。

データベースサブデータベースサブテーブルの後のもう1つの利点：単一のクエリで複数のサブテーブルをクエリする必要がある場合は、マルチスレッドの並列方法で複数のサブテーブルをクエリし、最後に各サブテーブルのクエリ結果をマージできます。 tableつまり、これによりクエリがより効率的になります。