使用Jemter进行简单压测

针对培训系统更新视频学习时长的接口进行压测

一、背景

本项目为新研发的线上视频培训系统，系统为全集团人员使用，因视频点播使用频率过高，且观看视频中会每隔20秒上报视频学习进度至服务器，为防止同时观看用户过多时系统出现卡慢甚至崩溃，故需对更新视频学习进度接口进行性能测试。

二、接口说明

1. 更新视频学习接口

更新视频学习接口为用户观察视频学习时、用于上报视频学习进度的接口，在用户观看视频过程中每隔20秒进行一次更新，更新视频学习进度接口说明如下：

字段名称	类型	字段说明
learnerCourseId	string	学员课程关联主键id
courseId	string	课程id
mediaId	string	媒体id
increaseTime	number	增加学习时间,单位秒
progressTime	number	当前进度时间
duration	number	媒体总时长，单位秒
completeFlag	boolean	是否完成标识 true 是  false 否

其中

learnerCourseId通过CVS文件获取

courseId、mediaId、progressTime从用户预置字段中获取

increaseTime固定为2

completeFlag固定为false

progressTime通过接口学习课程目录来获取

2. 学习课程目录接口

学习课程目录接口为压测辅助接口，学习课程目录接口说明如下：

字段名称	类型	字段说明
id	string	学员课程关联主键id

其中id通过CVS文件获取,即为learnerCourseId

3. 获取课程媒体播放信息接口

获取课程媒体播放信息为压测辅助接口，获取课程媒体播放信息接口说明如下：

字段名称	类型	字段说明
videoId	string	媒体在阿里云的id
courseId	string	课程id
mediaId	string	媒体id

其中videoId、courseId、mediaId从用户预置字段中获取

4.登录接口

登录接口为压测辅助接口，登录接口说明如下：

字段名称	类型	字段说明
phone	string	手机号码
password	string	密码
login_type	string	登录类型 0 学员 1 管理员；Head字段

其中

phone从CVS文件获取

password，测试用户密码默认为同一值

login_type为固定值 0

三、数据准备

1. 新增性能测试专用课程，选择时长不少于1个小时的视频，选择测试用户（60及以上个用户）。
2. 数据库获取测试用户的phone、learnerId、learnerCaurseId，存放在CVS文件中。
3. 数据库获取课程的courseId、mediaId、videoId、duration数据放入用户预置字段中。

四、场景设计

因此次压测仅需要压测一个接口，故只考虑单接口多用户压测。

1. 使用phone调用登录接口登录学习端获取token供后续接口使用。
2. 使用开始学习接口用户开始课程学习
3. 使用获取课程的媒体信息接口获取课程的媒体信息（数据库创建视频学习记录）
4. 使用学习课程目录接口获取课程当前进度，即progressTime，供更新视频学习时长接口调用
5. 更新视频学习接口压测：以15虚拟用户进行并发测，测试场景运行500秒（8分钟），获得响应时间、TPS以及对系统资源的消耗。测试完一个场景后增加5虚拟用户数再进行测试，依此类推直到测试出服务器瓶颈为止。
6. 其中第1、2、3步骤的接口在每次压测时每个线程仅执行一次即可。

 

五、性能测试

不同性能指标各有侧重。后台服务接口的调用者一般只关心吞吐量、响应时间等外部指标。后台服务的所有者不仅仅关注外部指标，还会关注CPU、内存、负载等内部指标。

1.外部指标

从外部看，直接通过Jemter自带组件Aggregate Graph即可获得，性能测试主要关注如下三个指标

• 吞吐量：每秒钟系统能够处理的请求数、任务数。
• 响应时间：服务处理一个请求或一个任务的耗时。
• 错误率：一批请求中结果出错的请求所占比例。

 

2.内部指标

从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等，因为项目特殊性，该项目通过rancher上对应服务的工作负载监控数据，即可获取相应的值。我们主要关心CPU利用率。

• CPU：服务对CPU的利用率对服务的性能起着决定性的作用。

 

按照场景设计中压测多轮，并记录每一轮的测试数据值：平均响应时长（毫秒）、90%响应时长（毫秒）、TPS（每秒）、CPU利用率。

虚拟用户	时长（秒）	平均响应时长（毫秒）	90%响应时长（毫秒）	TPS（每秒）	CPU使用率（web-bff）
15	500	178	259	47.2	86.08398438
20	500	224	362	44.6	86.37695313
25	500	257	380	51.7	90.47851563
30	500	297	434	51.8	87.01171875
35	500	326	491	53.4	89.40429688
40	500	387	593	51.4	90.72265625
45	500	421	634	51.6	88.81835938
50	500	458	706	52.5	91.69921875
55	500	489	773	52.2	89.94140625
60	500	508	804	53.8	98.2421875
65	500	636	1075	50.5	217.96875

更新视频学习功能性载测试共测试了11轮，经对测试结果分析TPS、响应时间及服务器使用率随着并发用户数增加呈上升趋势；当并发数为35U时，平均响应时间在0.326秒，服务器资源使用率89.4%；当前测试环境最优并发数为35U，TPS为53.4笔/秒。

六、问题解决记录

1. 获取CVS文件数据

  

a.创建.csv文件，phone、learnerCourseId、learnerId使用分隔符“,”分隔。

b.添加并配置CSV Data Set Config，其中

• Filename: 指保存信息的文件目录，可以相对或者绝对路径。否则会在jmeter日志文件（jmeter.log目录位置D:\Program Files\apache-jmeter-2.13\bin）中提示：系统找不到指定文件，运行脚本后，登录失败。
• File encoding: 保持默认。默认为ANSI
• Variable Names: 给csv文件中各列起个名字（有多列时，用英文逗号隔开列名）便于后面引用
• Delimiter:与 .csv文件的分隔符保持一致。如文件中使用的是逗号分隔，则填写逗号；如使用的是TAB，则填写\t；
• Allow quoted data? :是否允许引用数据，---这个目前还未弄明白，设置成True或者False都能正常引用数据。
• Recycle on EOF?:到了文件尾是否循环，True—继续从文件第一行开始读取，False—不再循环
• Stop thread on EOF? :到了文件尾是否停止线程，True—停止，False—不停止，注：当Recycle on EOF设置为True时，此项设置无效。
• Sharing mode:共享模式，All threads –所有线程，Current thread group—当前线程组，Current thread—当前线程。

2.获取token

1. 使用phone调用登录接口登录学习端
2. 使用JSON Extractor获取token
3. Header中携带token，因token通过Authorization传值故未使用cookie Manager

 

3.获取progressTime

因需要获取响应中的mediaList列表第二个studyDuration字段，故通过JSON Extractor获取。

  

字段配置说明如下：

1. names of created Variable ：保存的变量名，后面使用${变量名}引用，如：${progressTime}
2. JSON Path  expressions：上一步中调试通过的json path表达式,如果：$.data[0].mediaList[1].studyDuration
3. Match No.(0 for Random)：匹配数字（0代表随机，1代表第一个，-1代表所有）
4. Default Values：找不到时默认值，一般设置为NOT FOUND
5. Compute concatenation var(suffix_ALL)：是否统计所有，即将匹配到的所有值保存，名为“变量名_ALL”，使用场景需要获取的值有多个，后面需要对这一组数据进行操作。

4.响应校验

为防止接口调用成功，但内容提示失败，故对响应需要做校验

 

七、总结

1.场景设计很重要

使用的辅助接口尽量真实且正确，如：progressTime字段可通过多个接口获取，但是因为之前选择的接口非实际使用的接口，且该接口需去阿里云服务器获取信息，故导致压测时性能一直很低。

2.虚拟用户从少到多，别偷懒

本想着虚拟用户使用一个中间值测试大致情况再压测，发生测试数据波动大，后发现是当前虚拟用户已经超过最优用户故波动大。

3. 压测时间不能太少，别偷懒

压测时间也弄的很少 100s，发现时间太少时数据未稳定，测试时间就结束了看不到真实情况，后压测时间弄成1000s,发现最后面的时候浪费，数据一致很稳定。故需选择了一个中间数字500s

4.真实数据不一定是书本上写的特别符合逻辑，学会找到最优用户

最优并发数是TPS最高，资源使用最少的，且响应时间不高。

5.计算业务估算TPS

业务估算TPS的公式如下：

业务估算TPS=业务用户数*每日交易笔数*高峰期交易量/高峰期时段

其中

1. 业务用户数为系统预期用户数*1000，如：系统用户10000人，每天10%人需要进行学习视频
2. 每日交易笔数为该接口的每日调用笔数，如：若视频长度为1个半小时，最多调用更新视频学习进度270次
3. 高峰期交易量一般默认遵循二八原则，即80%的业务量在20%的时间内完成
4. 高峰期时段为系统每天运行8小时的20%，即：8*3600*20%

业务估算TPS= 10000*10%*270*0.8/(8*0.2*3600)≈37.5笔/秒