テストのベテランのまとめ、パフォーマンス テストの一般的なボトルネックの分析と最適化、「私」もテスト サークルから抜け出したい...


序文

パフォーマンス テスト プロセスで最も重要な部分は、パフォーマンスのボトルネックの特定と調整です。パフォーマンスのボトルネックにはさまざまな理由が考えられます。

1. アサーション
ストレス テストでは、送信されたリクエストが成功したかどうかを判断するために、通常、リクエストにアサーションを追加することで実装されます。

アサーションを使用する場合は、以下の仕様に従うことを推奨します:
① アサーションの内容は、可能な限りステータス/コード、メッセージ/メッセージで判断すること (もちろん、Restful 仕様に準拠したインターフェース設計が前提) )

Jmeter の例:

画像の説明を追加してください

Alibaba Cloud PTS:
PTS プレッシャー テストを使用している場合は、アサーション設定で、対応する値に等しいコード/ステータス、メッセージ/メッセージが優先されます。

②. Response Body のすべての内容をアサーション判定の内容として使用しないようにしてください。これにより、多数の「アサーション」失敗が発生する可能性があります。

PS: 残念なことに、私はストレス テストを行う多くの友人を見てきましたが、アサーションの内容は応答パラメーター全体の内容に基づいており、その結果、多数のエラー レポートが生成されます。

2. 成功率
一般的に性能テストでは99.99%の成功率を追求しますが、実際のテスト工程ではコードロジックを可能な限り網羅するために、可能な限り多くのホットデータを用意します。カバーを達成するための準備段階。

この場合に注目する成功率指標は以下の2種類に分類できます。

①、トランザクション成功率
トランザクション成功率は、ある時点におけるリクエストの成功率とも言え、アサーションや判定の際にコード/ステータスなどの内容をもとにリクエストが成功したかどうかを計測します。

②. ビジネスの成功率
実際のビジネスシーンにおいて、いわゆる成功率は返されたコード/ステータスだけでは判断できません。例: クエリ リクエストは、正しいクエリ結果を返すか、対応するデータにより空を返すかに関係なく、リクエストは成功します。

対応する応答パラメータは、{"status": "200", "message": "success"} の場合もありますが、{
"status": "200", "message": "対応する結果がありません"} の場合もあります。

PS: パフォーマンステストの過程では、ビジネスの成功率とリクエストの成功率という異なる指標を考慮し、アサーションの内容と組み合わせて、アサーションの方法を柔軟に設定する必要があります (もちろん、上記の 2 点に従うことをお勧めします)アサーション仕様)!

一般的なパフォーマンスのボトルネックの分析とソリューションの調整

パフォーマンス テストでは、パフォーマンスのボトルネックにはさまざまな理由がありますが、発生頻度に応じて直感的な監視グラフで示される外観は次のとおりです。

パフォーマンスのボトルネックの頻度 コンクリート性能
高い TPSの変動が大きい
高い 同時実行性が高いと大量のエラーが報告される
真ん中 クラスタシステムでは各サービスノードの負荷が偏る
真ん中 同時実行数が増加し続け、TPS が上がらず、CPU 消費量が高くない
低い 圧力テスト中、TPS は低下し続け、CPU 使用率も低下し続けます。

以下は、いくつかの一般的なパフォーマンスのボトルネック原因の分析と、いくつかの一般的なチューニング ソリューションです。

1.
大きな TPS 変動の理由分析: 大きな TPS 変動の理由には、一般に、ネットワークの変動、他のサービス リソースとの競合、およびガベージ コレクションの問題が含まれます。

パフォーマンス テスト環境は通常、イントラネットまたはストレス テスト マシン内にあり、サービスは同じネットワーク セグメント内にあり、ネットワークの送受信トラフィックを監視することでチェックできます。

他のサービスのリソース競合もこの問題を引き起こす可能性があるため、Top コマンドまたはサービス ソート メソッドを使用して、ストレス テスト中に他のサービスが実行されてリソース競合が発生していないかどうかを確認できます。

ガベージ コレクションの問題は、TPS 変動の比較的一般的な原因であり、GC 監視コマンドを通じて確認できます。コマンドは次のとおりです。

# 实时打印到屏幕
jstat -gc PID 300 10
jstat -gcutil PID 300 10
# GC信息输出到文件
jstat -gc PID 1000 120 >>/path/gc.txt
jstat -gcutil PID 1000 120 >>/path/gc.txt

チューニングスキーム:

ネットワークに変動がある場合は、運用および保守の同僚に解決を手伝ってもらうこともできます (ネットワーク セグメントの切り替えやイントラネットの圧力テストの選択など)。または、ネットワークが比較的安定するまで待って圧力テストと検証を実行することもできます。

リソース競合の問題: コマンドの監視とサービスの分類を通じて、圧力テスト中に実行されている他のサービスを見つけ、通信と調整を通じてサービスを停止します (または、リソース競合のないサービス ノードを変更して再テストします)。

ガベージ コレクションの問題: GC ファイル分析を通じて、頻繁な FGC が見つかった場合は、JVM のヒープ メモリ パラメータ Xmx を変更し、圧力テストを再度検証できます (Xmx の最大値はサービス ノード メモリの 50% を超えてはなりません) !)

2. 高い同時実行性で多数のエラーが
報告される 理由分析: このタイプの問題の一般的な原因は、接続が短いためにポートが完全に占有されていること、スレッド プール内のスレッドの最大数が小さく構成されていること、およびタイムアウトが原因であることです。期間が短い。

解決策の調整:
接続が短い問題: サービス ノードの tcp_tw_reuse パラメータを 1 に変更し、新しい接続用に TIME_WAIT ソケットを解放します。

スレッド プールの問題: サービス ノードのコンテナのserver.xml ファイルの構成パラメータを変更します。主に次のパラメータを変更します。

# 最大线程数,即服务端可以同时响应处理的最大请求数
maxThreads="200"                        
# Tomcat的最大连接线程数,即超过设定的阈值,Tomcat会关闭不再需要的socket线程       
maxSpareThreads="200"               
# 所有可用线程耗尽时,可放在请求等待队列中的请求数,超过该阈值的请求将不予处理,返回Connection refused错误
acceptCount="200"                 
# 等待超时的阈值,单位为毫秒,设置为0时表示永不超时
connectionTimeout="20000"

3. クラスタ システムでは、各サービス ノードの負荷がアンバランスです
。 原因分析: この種の問題の原因は、一般に、SLB サービスがセッション永続性を設定しているため、リクエストがいずれかのノードにのみ分散されることです。 。

解決策のチューニング: 上記の理由であることが確認された場合は、SLB サービス (F5/HA/Nginx) のセッション保持パラメーターを None に変更し、圧力テストを再度実行します。

4. 同時実行数が増加し続け、TPS が上がらず、CPU 使用率が低い
原因分析: この種の問題が発生します。一般的な理由は次のとおりです: SQL がインデックスを作成していない/SQL ステートメントのフィルター条件が明確ではない、コードに同期ロックがある場合、同時実行中に高いロック待機が発生します。

チューニングソリューション:
SQL の問題: インデックスがない場合はインデックスを作成し、SQL ステートメントのフィルター条件が明確でない場合は SQL とビジネス ロジックを最適化します。

同期ロックの問題: 同期ロックを解除するかどうかは、技術的な問題だけでなく、ビジネス ロジックのさまざまな判断に関わる場合もあるため、製品を開発している同僚とコミュニケーションをとって確認することをお勧めします。

5. 圧力テスト中、TPS は低下し続け、CPU 使用率は低下し続けます。
原因分析: 一般に、この種の問題の原因はスレッド ブロックです。もちろん、他の可能性も排除できません。

解決策の調整: スレッドのブロックの問題である場合は、スレッド戦略を変更してから再検証します。

6. その他
上記の 5 つの一般的なパフォーマンスのボトルネックに加えて、接続のリセット、サービスの再起動、タイムアウトなどの他のボトルネックもあります。もちろん、分析して特定した後、一般的なパフォーマンスのボトルネックが次のとおりであることがわかります。

理由のほとんどは、パラメータ設定、サービス戦略、ブロッキング、およびさまざまなロックによるものです。

パフォーマンスのボトルネック分析の参照基準: 上から下、部分から全体。

以下は、私がまとめた 2023 年の最も完全なソフトウェア テスト エンジニア学習知識アーキテクチャ システム図です。

1. Pythonプログラミングの入門から習得まで

画像の説明を追加してください

2.インターフェース自動化プロジェクトの実戦

画像の説明を追加してください

3. Web自動化プロジェクトの実戦

画像の説明を追加してください

4. アプリ自動化プロジェクトの実戦

画像の説明を追加してください

5. 一流メーカーの再開

画像の説明を追加してください

6. DevOps システムのテストと開発

画像の説明を追加してください

7. 一般的に使用される自動テストツール

画像の説明を追加してください

8、JMeterのパフォーマンステスト

画像の説明を追加してください

9. まとめ(最後にちょっとしたサプライズ)

休むことのない心があってこそ進取の精神を保つことができ、不屈の信念があってこそ自らの輝きを生み出すことができるのです。成功への道では、粘り強さと勤勉のみが近道です。

時間はあっという間に過ぎ、チャンスはあっという間に過ぎてしまいます。今をしっかりと捉えて、若いうちに戦いに出かけましょう。困難に怯えることなく、自分の夢と信念を貫けば、思いがけない成功が得られるでしょう。

誰もが自分の輝くポイントを持っています。探求して一生懸命努力する限り、あなたはそれらを輝かせることができます。軽い気持ちで諦めないで、熱意と忍耐力を持ち続け、自分を信じてください。未来は必ず良くなります。

おすすめ

転載: blog.csdn.net/shuang_waiwai/article/details/130602259