パフォーマンステストの分析と調整

パフォーマンス分析

1. 前提

   パフォーマンス分析の前提には、豊富なパフォーマンステストモニタリング（PTS独自のクライアント側モニタリング、基本モニタリング-Alibaba Cloudモニタリング、アプリケーションモニタリング-ARMSモニタリングなど）だけでなく、関連する技術的知識（以下を含むがこれらに限定されない）も必要です。オペレーティングシステム、ミドルウェア、データベース、開発など）。

2. プロセス
   • 多くの場合、圧力測定トラフィックはバックエンド（サーバーエンド）に完全には入りません。ネットワークアクセスレイヤー（クラウドアーキテクチャ、SLB / WAF /高防御IP、またはCDN /フルステーションアクセラレーションなど）でさまざまな仕様（帯域幅、最大接続数、新しい接続数など）、または圧力テストの特定の特性がCCおよびDDoSの動作に準拠し、保護戦略がトリガーされ、圧力テストの結果が期待どおりにならないため、制限が発生します。
   • 次に、主要なインジケーターが要件を満たしているかどうかを確認します。満たされていない場合は、問題のある場所を特定する必要があります。一般に、サーバー側の問題はクライアント側の問題である可能性が高くなります（この状況は非常に小さいです）。
   • サーバー側の問題については、CPU、メモリ、ディスクI / O、ネットワークI / Oなどのハードウェア関連のインジケーターを見つける必要があります。ハードウェアインジケーターに問題がある場合は、詳細な分析が必要です。
   • ハードウェアインジケーターに問題がない場合は、スレッドプール、接続プール、GCなどのミドルウェア関連のインジケーターを確認する必要があります。これらのインジケーターに問題がある場合は、詳細な分析が必要です。
   • ミドルウェア関連のインジケーターに問題がない場合は、SQLのスローチェック、ヒット率、ロック、パラメーター設定など、データベース関連のインジケーターを確認する必要があります。
   • 上記のインジケーターが正常な場合、アプリケーションのアルゴリズム、バッファリング、キャッシング、同期または非同期に問題がある可能性があり、特定の詳細な分析が必要です。

   詳細を以下に示します。

   
3. 考えられるボトルネック
   1. ハードウェア/仕様のボトルネック

      一般に、CPU、メモリ、ディスクI / Oの問題を指します。サーバーのハードウェアのボトルネックとネットワークのボトルネックに分けられます（LANでは考慮できません）。

   2. ミドルウェアのパフォーマンスのボトルネック

      一般に、アプリケーションサーバーやWebサーバーなどのアプリケーションソフトウェアを指し、データベースシステムも含まれます。たとえば、ミドルウェアのweblogicプラットフォームでコンフィグレーションされているJDBC接続プールのパラメータ設定が不適切であり、ボトルネックが発生しています。

   3. アプリケーションのパフォーマンスのボトルネック

      一般に、開発者が開発したアプリケーションを指します。たとえば、JVMパラメーターが不合理であり、コンテナー構成が不合理で低速のSQL（ARMSなどのAlibaba Cloud APM製品を使用して位置決めを支援できる）、データベース設計が不合理、プログラムアーキテクチャの計画が不合理、プログラム自体に問題（シリアル処理、要求）不十分な処理スレッド、バッファーなし、バッファーなし、調整されていないプロデューサーとコンシューマーなど）。その結果、多数のユーザーの方向でのシステムのパフォーマンスの低下によってボトルネックが発生します。

   4. オペレーティングシステムのパフォーマンスのボトルネック

      一般に、Windows、UNIX、Linux、およびその他のオペレーティングシステムを指します。たとえば、パフォーマンステスト中に物理メモリが不足している場合、仮想メモリの設定は適切ではなく、仮想メモリの交換効率が大幅に低下するため、動作の応答時間が大幅に増加します。このとき、オペレーティングシステムでパフォーマンスのボトルネックが発生すると考えられます。

   5. ネットワークデバイスのパフォーマンスボトルネック

      一般に、ファイアウォール、動的ロードバランサー、スイッチ、その他の機器を指します。現在、クラウドサービスアーキテクチャで使用されているより多くのネットワークアクセス製品：SLB / WAF /高防御IP / CDN /フルステーションアクセラレーションなどが含まれますが、これらに限定されません。たとえば、動的ロードバランシングメカニズムが動的ロードバランサーに設定されている場合、アプリケーションサーバーのハードウェアリソースが制限に達したことが検出されると、動的ロードバランサーは後続のトランザクション要求を他の負荷の軽いアプリケーションサーバーに送信します。 。テスト中に、動的ロードバランサーが対応する役割を果たしていないことが判明しましたが、現時点では、ネットワークのボトルネックを検討できます。

4. 方法
   1. CPU

      CPUリソース使用率が高い場合は、CPU消費の状態を確認する必要があります。ユーザー、システム、待機。

      • CPUユーザーが非常に高い場合、どのプロセスが消費されているかを確認する必要があります。top（linux）コマンドを使用して確認し、次にtop –H –p <pid>を使用して、どのリソースが高いリソースを消費しているかを確認できます。Javaアプリケーションの場合は、jstackを使用して確認できます。このスレッドが実行しているスタックを取得し、リソースで使用されているメソッドを確認し、ソースコードをチェックして問題を確認します。C++アプリケーションの場合は、gprofパフォーマンスツールを使用して分析できます。
      • CPU Sysが非常に高い場合、strace（linux）を使用して、システムコールのリソース消費と時間を確認できます。
      • CPU待機が非常に高い場合は、ディスクの読み取りと書き込みを検討してください。非同期でログ出力を削減したり、高速でハードディスクを変更したりできます。
   2. 記憶

      メモリの使用率を最大化するために、オペレーティングシステムは通常、大量のキャッシュをセットアップします。したがって、メモリ使用率が99％と高いことは問題ではありません。メモリの問題は、主にプロセスが占有するメモリが非常に大きいかどうか、および大量のスワップがあるかどうかに依存します交換）。

   3. ディスクI / O

      ディスクI / Oの最も重要な指標の1つはビジーレートです。これは、ログ出力を非同期に削減するか、ハードディスクを高速で変更することによって達成できます。

   4. ネットワークI / O

      ネットワークI / Oは、主に送信されるコンテンツのサイズを考慮します。これは、ハードウェアネットワーク送信の最大値の70％を超えることはできません。圧縮を使用して、コンテンツサイズを削減し、キャッシュをローカルに設定して、複数回送信できます。

   5. カーネルパラメーター

      カーネルパラメータには通常、デフォルト値があります。これらのカーネルパラメータのデフォルト値は、一般的なシステムでは問題ありませんが、ストレステストでは、実行される可能性のあるパラメータがカーネルパラメータを超え、システムに問題が発生するため、sysctlを使用して表示および変更できます。

   6. JVM

      jvmは主にGC / FULL GCが頻繁に行われるかどうか、およびガベージコレクションの時間を分析します。jstatコマンドを使用して、各世代のサイズとGCが頻繁に確認され、jmapを介してメモリをダンプし、HeapAnalyzerツールを使用してメモリが占​​有されている場所を分析できます。高い、およびメモリリークの可能性があるかどうか。簡単にするために、以下と同じAlibaba Cloud ARMSなどのAPMツールを使用できます。

   7. スレッドプール

      スレッドが十分でない場合は、パラメーターの調整によりスレッドを増やすことができます。スレッドプールのスレッド設定が比較的大きい場合は、それでも十分ではありません。考えられる理由は、スレッドがブロックされて解放できず、ロックとメソッドを待機するのにさらに時間がかかる場合があります。長い、長いデータベース待機時間およびその他の理由により、特定するにはさらに分析が必要です。

   8. JDBC接続プール

      接続プールが十分でない場合は、パラメータを使用して調整および増加できますが、データベース自体の処理が遅い場合、調整はあまり効果がありません。データベースと、コードが原因で接続が解放されない理由を確認する必要があります。

   9. SQL

      SQLの非効率性は、パフォーマンスの低下の非常に重要な理由でもあります。実行プランを調べると、SQLが遅い場所を確認できます。一般に、SQLの非効率性の主な理由は次のとおりです。

      1. 1.  

            カテゴリー	サブクラス	式または説明	理由
            索引	インデックスなし	-	全表スキャンを生成する
            	未使用のインデックス	substring（card_no、1,4）= ′5378′	全表スキャンを生成する
            		金額/ 30 <1000	全表スキャンを生成する
            		convert（char（10）、date、112）= '19991201'	全表スキャンを生成する
            		給与<> 3000	全表スキャンを生成する
            		'％张'のような名前	全表スキャンを生成する
            		first_name + last_name = 'beill cliton'	全表スキャンを生成する
            		id_no in（ ′0′、 ′1′）	全表スキャンを生成する
            		tからIDを選択します。ここでnum = @ num	パラメータは、全表スキャンも生成します
            	非効率なインデックスを使用する	非クラスター化インデックス別	低いインデックスパフォーマンス
            		ユーザー名= '张三'および年齢> 20	文字列インデックスが整数インデックスより低い
            		テーブルの列と空のNULL値	低いインデックスパフォーマンス
            		IS NULLまたはIS NOT NULLを使用しないようにしてください	低いインデックスパフォーマンス
            データ量	すべてのデータ	選択する *	多くの列は大量のデータを生成します
            		ID、名前を選択	テーブルには数百万の行があり、大量のデータを生成します
            	ネストされたクエリ	最初にデータをフィルターし、次にデータをフィルターします	多くの無駄なデータを生成する
            	関連クエリ	マルチテーブルアソシエーションクエリ。最初にデータの小さな部分を除外し、ほとんどのデータを除外します	多数の関連操作
            	大量のデータ挿入	何度も挿入	大量のログを生成してリソースを消費する
            ロックする	ロック待機	アカウントセットbanlance = 100、id = 10の更新	テーブル全体をロックするテーブルレベルのロックを生成する
            	デッドロック	A：更新a;更新b; B：更新b;更新a;	デッドロック
            	カーソル	カーソルカーソルを開く、フェッチ;カーソルを閉じる	非常に低いパフォーマンス
            	一時テーブル	一時テーブルを作成する	大量のログを生成する
            	ドロップテーブル	一時テーブルを削除	システムテーブルの長期ロックを回避するには、削除を表示する必要があります
            その他の	INの代わりに存在する	aからnumを選択します（numからbを選択）	一つずつ判断され、既存のものの終わりは終わります
            	代替選択カウントが存在します（*）	レコードが存在するかどうかを確認します	カウント（*）は計算を累積し、出口は終了します
            	INの代わりに	ID in（1,2,3）	INは一つずつ判断され、その間がスコープ判断
            	左外部結合代替Not IN	IDが存在しない場所からIDを選択（bからb.Mainidを選択）	IN INは1つずつ判断し、効率は非常に低い
            	union all 代替union	select ID from a union select id from b union	删除重复的行，可能会在磁盘进行排序而union all只是简单的将结果并在一起
            	常用SQL尽量用绑定变量方法	insert into A(ID) values(1)	直接写SQL每次都要编译，用绑定变量的方法只编译一次，下次就可以用了

             

      调优

      1. 调优步骤
         1. 确定问题

            应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。 数据库配置：经常引起整个系统运行缓慢，一些诸如大型数据库都是需要DBA进行正确的参数调整才能投产的。 操作系统配置：不合理就可能引起系统瓶颈。 硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。 网络：网络负载过重导致网络冲突和网络延迟。

         2. 分析问题

            当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O 情况如何？问题是否集中在某一类模块中？ 是客户端还是服务器出现问题？ 系统硬件配置是否够用？实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？ 通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。

         3. 确定调整目标和解决方案

            高系统吞吐量，缩短响应时间，更好地支持并发。

         4. 测试解决方案

            对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）。

         5. 分析调优结果

            系统调优是否达到或者超出了预定目标？系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了。 最后，如果达到了预期目标，调优工作可以先告一段落。

      2. 调优注意事项
         • アプリケーションシステムの設計と開発のプロセスでは、パフォーマンスを常に考慮し、パフォーマンステストを正規化する必要があります。PTSは、毎日のイントラネットパフォーマンステスト+通常の実際のビジネスパフォーマンステストをサポートできます。
         • 明確で明確なパフォーマンスターゲットを特定することが重要です。次に、ターゲットをPTSの圧力テストシナリオに変換し、必要なターゲットの大きさを設定し、必要に応じてコンカレント/ TPSモードを選択し、フロー制御の速度を自動的に増加/手動で調整します。
         • 調整されたプログラムが正しく実行されることを確認する必要があります。
         • システムのパフォーマンスは、優れた設計に大きく依存し、チューニングテクニックは単なる補助です。
         • チューニングプロセスは反復的で段階的なプロセスであり、各チューニングの結果を後続のコード開発にフィードバックする必要があります。
         • パフォーマンスの調整は、コードの可読性と保守性を犠牲にすることはできません