一场为企业服务开发的性能测试报告

1,882 阅读8分钟

引言

编写目的

本测试报告,在性能测试结束阶段,对测试结果进行分析,并给出结论。

术语定义

1、事务平均响应时间 (Average Transaciton Response Time)

“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间,通过它可以分析测试场景运行期间应用系统的性能走向。

2、每秒通过事务数/TPS (Transactions per Second)

“每秒通过事务数/TPS”显示在场景运行的每一秒钟,每个事务通过、失败以及停止的数量,使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向,将它与平均事务响应时间进行对比,可以分析事务数目对执行时间的影响。

3、并发用户数 (Vuser)

“并发用户数量”,在同一时刻与服务器进行交互的在线用户数量。这些用户的最大特征是和服务器发生了交互。

预期读者

本文档阅读对象一般为项目经理、测试经理、研发经理,技术老鸟等。

测试目的

本报告是为了反映中间件各个场景下在多用户并发访问的情况下系统的表现情况.

本次测试从事务响应时间、并发用户数、系统资源使用等多个方面,以专业的性能测试工具,分析出当前系统的性能表现,以实际测试数据与预期的性能要求比较,检查系统是否达到既定的性能目标。

环境配置

服务器:

描述

OS

台数

CPU

Mem

IP

应用服务器

Linux

2

4核

4G

10.126.3.59

10.126.3.61

Nginx

Linux

1

12核

6G

10.126.3.63

Node服务器

Linux

1

4核

4G

10.126.3.59:1337

压力机

windows

2

8核

4G

10.126.3.58

10.126.3.62

应用配置:

配置对象

参数

配置

说明

Tomcat

/context.xml

sticky

true

粘性Session机制

lockingMode

auto

非粘性Session的锁定策略

sessionBackupAsync

false

是否应该被异步保存到Memcached

operationTimeout

5000毫秒

sessionBackupTimeout

5000毫秒

备份Session超时时间

Tomcat

/ server.xml

maxThreads

500

线程池最大线程数

minSpareThreads

5

acceptCount

1000

排队长度

keepAliveTimeout

20000

web.xml

session-timeout

30分

日志级别

level value

error

判断日志记录与否

JVM

最小堆内存

2000M

最大堆内存

2000M

最大永久代MaxPermSize

256m

GC策略

默认

其他

-XX:-HeapDumpOnOutOfMemoryError

LR配置(true表示选中,false表示不选中):

配置对象

参数

配置

说明

ignore think time

true

忽略思考时间

download non-HTML resources

true

下载图片

continue on error

true

错误时仍然继续

run user as thread

true

运行使用线程方式

simulate a new user on each iteration

true

每次迭代清除http上下文

Tomcat

结果数据

单个节点

HTML

并发用户数

10

20

50

100

每秒通过事务数TPS

19305

32584

44195

40566

平均响应时间

0

0.001

0.001

0.002

JSP

并发用户数

10

20

50

100

每秒通过事务数TPS

19745

27982

33233

32576

平均响应时间

0

0.001

0.001

0.002

Serverlet

并发用户数

10

20

50

100

每秒通过事务数TPS

19305

28591

32460

34249

平均响应时间

0

0.001

0.001

0.002


问题及结果分析

随着并发用户数的增加,TPS值在随之呈增长趋势。

此应用没有使用数据库,应用和压力机内存使用正常,资源使用正常,均不构成系统的瓶颈。

Nginx+Tomcat

结果数据

单个节点

HTML

并发用户数

10

20

50

100

每秒通过事务数TPS

13252

21481

31044

34275

平均响应时间

0.001

0.002

0.004

0.008

JSP

并发用户数

10

20

50

100

每秒通过事务数TPS

12267

19230

25603

30903

平均响应时间

0.001

0.002

0.004

0.008

Serverlet

并发用户数

10

20

50

100

每秒通过事务数TPS

12007

19610

25135

29242

平均响应时间

0.001

0.002

0.004

0.008



两个节点

HTML

并发用户数

10*2

20*2

50*2

100*2

每秒通过事务数TPS

22160

33492

45619

41595

平均响应时间

0.001

0.002

0.004

0.008

JSP

并发用户数

10*2

20*2

50*2

100*2

每秒通过事务数TPS

20071

31514

39274

36363

平均响应时间

0.001

0.002

0.004

0.008

Serverlet

并发用户数

10*2

20*2

50*2

100*2

每秒通过事务数TPS

20050

32584

39195

40566

平均响应时间

0.001

0.002

0.004

0.008



问题及结果分析

从单节点来看,HTML,JSP, Serverlet结果走势相近,增加Nginx后会存在一定的性能损耗,负载均衡增加一个Tomcat节点,与单节点进行比较,TPS结果Serverlet约为1.7倍的增长,HTML约为1.6倍的增长,JSP约为1.6倍的增长。导致相同场景Nginx+2个Tomcat的TPS比单个节点的Tomcat的TPS没有2倍左右的增长的原因,系统的瓶颈是压力机的磁盘IO过大,提升系统性能的方式,可以增加不在同一块硬盘上的压力机,减少在单个压力机上的磁盘IO写入情况而提高性能。应用程序没有用到数据库,应用服务器的资源使用正常,均不构成系统的瓶颈。

Node

结果数据

单个节点

Node 直接启动 node server1.js +文本页面

并发用户数

10

20

50

100

每秒通过事务数TPS

13010

15317

14123

15373

平均响应时间

0

0.001

0.001

0.002

Node pm2启动 1个节点

并发用户数

10

20

50

100

每秒通过事务数TPS

13660

15097

15133

15540

平均响应时间

0

0.001

0.001

0.002

Node pm2启动 4个节点

并发用户数

10

20

50

100

每秒通过事务数TPS

17597

28405

38392

41549

平均响应时间

0

0.001

0.001

0.002


问题及结果分析

Node 直接启动与pm2启动差异不大,Node启动4个节点TPS高于单个节点2.7倍。

此应用没有使用数据库,应用和压力机内存使用正常,资源使用正常,均不构成系统的瓶颈。

Node+Tomcat

结果数据

单个节点

HTML

并发用户数

10

20

50

100

每秒通过事务数TPS

8480

11856

11437

11339

平均响应时间

0.001

0.002

0.004

0.008

JSP

并发用户数

10

20

50

100

每秒通过事务数TPS

8214

11264

11514

11269

平均响应时间

0.001

0.002

0.004

0.008

Serverlet

并发用户数

10

20

50

100

每秒通过事务数TPS

5422

7878

8926

9013

平均响应时间

0.001

0.002

0.004

0.008


问题及结果分析

从单节点来看,HTML,JSP, Serverlet结果走势相近,

此应用没有使用数据库,应用和压力机内存使用正常,资源使用正常,均不构成系统的瓶颈

Node+Nginx+ Tomcat

结果数据

单个节点

HTML

并发用户数

10

20

50

100

每秒通过事务数TPS

7235

9563

9969

10254

平均响应时间

0.001

0.002

0.004

0.008

JSP

并发用户数

10

20

50

100

每秒通过事务数TPS

5736

8030

8384

9050

平均响应时间

0.001

0.002

0.004

0.008

Serverlet

并发用户数

10

20

50

100

每秒通过事务数TPS

6028

8570

9141

8763

平均响应时间

0.001

0.002

0.004

0.008


2个Tomcat节点

HTML

并发用户数

10*2

20*2

50*2

100*2

每秒通过事务数TPS

9494

10988

11679

11280

平均响应时间

0.002

0.003

0.008

0.015

JSP

并发用户数

10*2

20*2

50*2

100*2

每秒通过事务数TPS

8995

9251

10134

10551

平均响应时间

0.002

0.003

0.008

0.015

Serverlet

并发用户数

10*2

20*2

50*2

100*2

每秒通过事务数TPS

9080

9741

10186

10208

平均响应时间

0.002

0.003

0.007

0.015



问题及结果分析

从单节点来看,HTML,JSP, Serverlet结果走势相近,增加Nginx,Node后会存在一定的性能损耗,负载均衡增加一个Tomcat节点,TPS没有呈2倍增长。系统的瓶颈是压力机的磁盘IO过大,提升系统性能的方式,可以增加压力机的方式,增加不在同一块硬盘上的压力机,减少在单个压力机上的磁盘IO写入情况而提高性能。

纵向比较数据




测试结论

随着系统架构的变化TPS逐层下降,每增加一层Nginx或者Node都存在一定的性能损耗, 系统的瓶颈是压力机的磁盘IO过大,提升系统性能的方式,可以增加不在同一块硬盘上的压力机,减少在单个压力机上的磁盘IO写入情况而提高性能。

此次中间件架构测试为今后其他项目测试提供参考数据比对

TIPS

文章开源我的博客:地址(转载请说明出去)

个人最新全栈架构体系:Creek-dam-nova (欢迎大家star)