パフォーマンステストのレポートテンプレート

パフォーマンステストレポート

 

パフォーマンステストレポート

 

 

 

プロジェクト

XXXプロジェクト2

V1.00

著者

太夫

日付

2019年9月31日

 

 

 

1.  テストの概要

1.1  テストターゲット

このテストの説明意味と目的

この試験の目的は、プローブすることです XXXプロジェクトの高負荷条件の下に2つの再構成可能なシステム業務処理性能、環境、およびシステムパフォーマンスを。

1.2  指標と用語

テストに関与した性能を表す用語

用語

定義

同時

同時スレッドの数は、システムに接続するためのユーザーをシミュレートするためにしながら、同時にトランザクション要求の数は、テスト中にシステムによって発行されました。

TPS (秒あたりのトランザクション)

システムの時秒あたりのトランザクション数を処理することができます。TPS かなりの程度までは、システムパフォーマンスの機能を反映しています。

エラーレート

トランザクション処理システムによるエラーの確率、システムの機能障害を使用する実際のユーザに対応します。エラー率は、理想的な状況下では、非常に低いレベルに維持する必要があります。

リソースの活用

サーバーの重要なリソースの比率を使用して、システムハードウェアの能力を測定するために使用されます

 

 

2.  環境、ツール

問題のテストでは、サーバー、クライアント、およびテストツールをリストされています

2.1  テスト環境

サーバー:

アプリケーション

機械

CPU、メモリ構成

API

IPアドレス

16 コアCPU 、メモリ16G

MYSQL

IPアドレス

16 コアCPU 、メモリ16G

 

 

クライアント:

オペレーティングシステム

CPU

メモリ

Windows10のプロ

I3- 4170 3.70GHZ

8G

 

2.2  テストツール

コアツール

リマーク

JMeterの

3.3

同時要求を提供する能力

パフォーマンスモニタメトリックコレクター

2.1

JMeterのプラグインのサーバリソースの使用状況に関する情報を収集するために、

ServerAgent

2.2.1

サーバのリソース使用状況の情報は、サーボフォームに送信されます

NMON

16時間v2の

リアルタイム収集サーバリソース情報

 

3.  テストプログラム

3.1  テストの種類

さまざまなパフォーマンステストシナリオがテストの異なる種類を使用することが、明確にする必要があります

パフォーマンステストは、テストの次のタイプを採用します。

リットルの  ベンチマーク:

小同時条件で、その後の比較のための基礎として、各性能指標の検出システムの性能、。

 

リットルの  ストレステスト:

正確にユーザー・アクセスの量を推定することができませんので、ストレステストの方法を使用することを検討してください。システムは、パフォーマンスのボトルネックに達するまで同時に処理するトランザクションの数によって、システムを増加させることを目的とストレス・テストは、システムの負荷を増やします。これに基づきシステムは、トランザクションおよびユーザーの要求を実行することができます。

 

安定性試験:

より長いシステムは、欠陥検出性があるかどうか、高負荷シナリオの下に置かれます。

3.2  ビジネスモデル

システム・インタフェースについては、正確に何が測定された圧力の範囲に含まれる必要がありますか?別のトランザクションがどのような割合で呼び出されなければなりません、それはまた、パフォーマンスのテスト設計をモデル化することが困難の一つです。

:設計およびテストプロジェクトのためのアーキテクチャによると、ビジネスシーン解析をシミュレートするために、次のビジネスモデル

 

シナリオ1:単純なビジネスシーン

会社名

インターフェイスアドレス

要求タイプ

同時割合

ログイン

/ログインする

役職

1

クエリユーザー情報

/ queryMemberInfo

取得する

1

 

 

 

シナリオ2:混合ビジネスシーン

会社名

インターフェイスアドレス

要求タイプ

同時割合

ログイン

/ログインする

役職

1

クエリユーザー情報

/ queryMemberInfo

取得する

1

取引のお問い合わせ

/リストの注文SIDA

取得する

1

オーダー作成

/ createOrder

役職

1

 

3.3  暗号処理検査符号

すべてのトランザクション要求のためのシステムは、符号検査工程を暗号化されているので、この性能試験では、一貫性の要求パケットの必要性は、暗号化と署名したので。次のように処理ロジックは、次のとおりです。

使用 APP 同じ暗号署名コードが導出されたjar 暗号化ツールとしてのパッケージを

使用のJMeter プリプロセッサ-beanshell プロセッサは、前記呼び出しジャーパケット暗号化された要求パラメータに実装される方法を

L要求パラメータは暗号化された署名変数を格納され、後の使用のインターフェースコール

 

3.4  圧力勾配

3.2 シーンから各圧力勾配、100 同時インクリメント100 システムがボトルネックに到達するまで、同時の数。

 

4.  テスト結果

4.1  集計レポート

タグ

サンプル数

平均(応答時間ミリ秒)

最低

最大

エラーレート

スループット(/秒)

ログイン

50

28

20

38

0.00パーセント

4.5977

クエリのメンバー情報

50

1602

1292

2042

0.00パーセント

4.07133

ビュートランザクション

50

705

512

920

0.00パーセント

4.37828

注文を作成します。

50

86

60

119

0.00パーセント

4.55083

全体的な

200

605

20

2042

0.00パーセント

15.11716

シーン 1-10 同時実行- サイクル5

 

タグ

サンプル数

平均(応答時間ミリ秒)

最低

最低

エラーレート

スループット(/秒)

ログイン

500

7612

40

26725

0.00パーセント

15.84987

クエリユーザー情報

500

30871

2369

49719

0.00パーセント

6.96233

全体的な

1000年

19241

40

49719

0.00パーセント

13.91517

シーン 1-500 同時- サイクル1

 

タグ

サンプル数

平均(応答時間ミリ秒)

最低

最大

エラーレート

スループット(/秒)

ログイン

550

8326

33

22360

0.00パーセント

20.34851

クエリユーザー情報

550

36071

4362

58485

0.36パーセント

6.7585

全体的な

1100

22199

33

58485

0.18%

13.51069

场景1-550并发-循环1

 

标签

样本数

平均(响应时间ms)

最小

最大

错误率

吞吐量(/s)

登录

4500

12408

87

46269

0.00%

4.68807

查询用户信息

4500

35383

3792

65036

0.00%

4.63027

查看交易

4500

22832

711

46812

0.02%

4.64518

创建订单

4500

24973

81

58698

0.13%

4.67591

总体

18000

23899

81

65036

0.04%

18.50308

场景2-450并发-循环10

 

4.2 系统吞吐量

 

 

 

 场景1-550并发-循环1

 

 

 

 

 场景2-450并发-循环10

 

4.3 资源占用率

最优负载条件下:

CPU使用率

 

 

 

  

内存占用率

 

 

 

 

磁盘使用率

 

 

 

 

5. 分析和建议

结合收集到的数据,给出对于系统性能关键点的分析

5.1 测试结论分析

经过多次测试和数据报表分析,可以得出如下结论:

1) 当总体并发用户数为450-500时,系统具有最优性能表现;当事务并发数超过500时,事务失败率整体上升,系统到达性能拐点。

2) 多事务混合条件下,系统巅峰TPS在90左右,平均吞吐量在13-18/s。

3) 在小压力条件下(10并发),最大事务响应时间为查询用户信息事务的2042毫秒,平均在600毫秒左右系统。整体事务微观响应速度较优。

4) 满负载条件下,登录具有最佳的性能表现,平均响应时间为7000-12000毫秒;查询用户信息事务性能较差,平均响应时间在30000-40000区间。满负载条件下系统整体微观响应时间较差。查询用户接口由于其使用极为频繁,建议进行SQL效率调优

5) 系统资源方面,内存占用率始终处于高位水平(90%以上),磁盘空间由于日志写入而不断被占用。

         

5.2 问题

测试过程中发现了如下显著问题:

1) 加密验签功能并未生效-现阶段任何签名均可通过验签。属于功能性问题,不影响性能表现。

2) 日志文件由于不断写入导致磁盘占满,建议调低系统日志级别,并做好定期日志备份。

3) 内存占用处于高位水平,需要进一步探查原因。

 

おすすめ

転載: www.cnblogs.com/dayu2019/p/11636279.html