性能项目中,性能数据是重要的输入资源。但有人用极少的数据,来做较大压力,显然不符合真实场景,虽然拿到的结果好看,但无价值。
性能场景中的数据到底应该做成啥样?RESAR性能工程中,场景里使用的数据要满足:
- 符合真实环境中的数据分布
才能模拟出相应的IO操作 - 符合真实用户输入的数据
以真正模拟真实环境中的用户操作
分别对应:铺底数据和参数化数据。
1 铺底数据
线上系统架构中,系统常用到的数据分为:
- 静态数据(红点)
- 动态数据(绿点)
这也是性能场景中要存入的铺底数据:
若无铺底数据,相当于一个空系统。但生产环境中,这系统肯定不会空,所以要有足够数据。若数据不真实,就无法模拟生产上有真实数据的场景,如应用的内存占用、数据库IO能力、网络吞吐能力。
静态数据,易出现的问题是:
- 一想到占网络带宽大,就觉得要用CDN
- 或觉得不模拟静态数据,就不符合真实场景,不支持我们的优化结果
其实数据放在哪,怎么做合理,怎么做成本低,都要综合考虑,不是随大流:
- 有的官方门户网站没啥流量,技术规划时非把几个图片放CDN,以显示架构多先进
- 一些企业认为网站上的图片很重要,不懂技术又寻找安全感,非把图片都放到自己的服务器。本来图片就很大,一张有3~4M,用户一访问,自然就慢
这两种极端都不可取。外行指使内行干活,基本没好结果,因为有些外行觉得只要压力发起就可,细节上根本不在乎结果。处理这样问题的最合理方式:
- 先分析业务逻辑
- 再判断技术架构实现
1.1 静态数据
通常有两个可存放地方:
- 服务端的Web层
- CDN
大系统的流量大,网络带宽就得多。这种情况下,数据必然要放CDN。如果不使用 CDN 技术,数据需要从一个中心服务器传输到用户的设备上,会导致:
- 延迟高:由于数据需要从远程服务器传输,因此会增加访问的延迟,降低用户体验。
- 网络拥塞:如果所有用户都从同一个服务器上请求数据,会导致网络拥塞,降低整个系统的响应能力。
- 安全性问题:如果所有用户都从同一个服务器上请求数据,这也意味着所有用户的数据都存储在同一个地方,一旦服务器遭受attack或数据泄漏,用户的数据就会受到威胁。
因此,使用 CDN 技术可以将数据存储在距离用户更近的服务器上,可以提高访问速度和响应能力,减少延迟和网络拥塞的问题,并且可以提高系统的安全性。
对一些小的业务系统,由于用户不多,整体网络流量要求也少,可将静态数据直接放到负载均衡服务器(如Nginx)或应用服务器。用户访问一次之后,后续访问直接走本地缓存,对系统压力也不会产生多大影响。
1.2 动态数据
需分析,因为有些动态数据可放CDN。
- 不用任何预热加载时,这些动态数据都存DB
- 使用预热加载时,这些数据就会转到缓存(也取决于架构设计和代码实现),变成:
按这样逻辑,真实场景中业务操作的数据量实际有多少,我们就要模拟多少,不然会出现一些问题。当模拟数据量与实际数据量差别较大,会对DB、Cache等造成不同
1.3 影响
① 对DB压力的区别
设线上系统中100万用户,压测时,由于无生产数据,造数据又麻烦,就直接使用1000条甚至更低用户量做性能场景。
一个表里有100万条数据和1000条数据的差别是啥?前提条件:同样硬件环境、数据库、表结构、索引,只是两张表的数据不同。两条SQL:
select * from ob_tuning.temp1_1000 where id = '3959805';
select * from ob_tuning.temp2_100w where id = '3959805';
因为表数据量不同:
表操作细节。第一个表(用户量1000):
第二个表(用户量100w):
只需对比“executing”行就能看到明显差距,它告诉我们当执行语句时,需要的CPU时间明显因为数据量增加而增加。所以,若无足够铺底数据放在性能场景,一开始便注定悲剧。
② 缓存的区别
数据量的多少在缓存中有明显区别:
场景中用的数据量越多,缓存必然要求越大。
③ 压力工具使用的区别
压力工具中使用的数据多少,不仅影响着压力工具本身需要的内存,同时也影响着性能场景的执行结果。
④ 网络的区别
不同的数据量,不管是走缓存,还是数据库,对客户端和服务器之间的网络消耗都是差不多的。只要不是缓存在客户那边,都是要走到服务器里转一圈的。
所以我们认为,数据量是多还是少,对客户端和服务器之间的网络的压力没有什么区别。如果你用的是CDN,那可以做另外的考虑。
⑤ 应用的区别
如果不是在应用中直接缓存数据,我们也认为对应用没什么区别,反正不管是什么样的请求过来,都是要到缓存或数据库中去取数据的,应用的Self Time不会有什么差别,方法依旧要执行。但是,如果你的应用是直接在应用的缓存中存数据的,那就有区别了,同样也是数据量越大,对内存的要求就越大。
基于这几点,可以看到有两个较重要环节:数据库和缓存,这是直接影响。
间接影响,比如数据在数据库中执行得慢了,在同步调用的应用中必然需要更多的应用线程来处理。
假设有一个100 TPS的系统,先忽略其他时间,只看数据库时间。如果数据库执行需要10ms,那应用只需要一个线程就能处理完了。如果数据库需要100ms,而我们仍想达100TPS,应用就得有10个线程同时处理。
整个链路上的所有线程、队列、超时等都会因为受到数据量的影响而产生大的变化。
要想模拟出生产时候的样子,铺底数据不能含糊。
2 参数化数据
场景中该用多少量数据,是性能场景中最容易出问题的环节。
参数化数据量应该多少,取决于场景运行多长时间。而在场景运行中,通常用到两类数据:
- 唯一性数据
- 可重复使用的数据
2.1 计算方式
① 唯一性数据(如用户数据)
要使用多少参数化数据很容易计算。比如一个运行半小时的场景,TPS如果是100的话,就要18万数据量:
$数据量 = 30min \times 60s \times 100TPS = 18w$
② 可重复使用的数据量
要分析真实业务场景中如何重复,如电商系统中商品的数据量,参数化时就能重复,毕竟多个人是可同时购买同一商品。我们假设平均有1000个用户在10个商品中,那当我们有18万个用户时,就需要1800个商品:
$商品数量 = 18w用户 \div 1000用户 \times 10 商品 = 1800 商品$
若参数化数据量太大,在压力工具中处理不了咋办?如JMeter处理文件参数化数据时,参数化文件太长,会导致JMeter消耗更多时间。这种参数化数据量要求多的情况,可采用连接远程缓存(如Redis)或数据库(如MySQL)的方式做参数化。
2.2 连接Redis做参数化
方法一:直接在JMeter写Beanshell连接Redis取数据
import redis.clients.jedis.Jedis;
//连接本地的 Redis 服务
Jedis jedis = new Jedis("172.16.106.130",30379);
log.info("服务正在运行: "+jedis.ping());
String key = vars.get("username");
String value = vars.get("token");
vars.put("tokenredis",jedis.get(key));
方法二:使用Redis Data Set组件
这俩都能用Redis做参数化的数据源。
2.3 连接MySQL做参数化
① 创建一个JDBC Connection Configuration。
配置好连接信息,如用户名密码:
② 创建一个JDBC Request
用JDBC Request把数据取回来:
③ 用${user_name}引用参数
完成上述三步,就实现了用DB的方式做参数化。
3 怎么造数据
- 用户数据
- 地址数据
- 商品数据
- 订单数据
数据量如何设置?
根据第4讲的性能方案,登录TPS如果是每秒150,并且如果按容量场景的需求,在场景连续递增时,大概在20分钟内(这是一个经验值,在具体的场景执行中也会有变化)会递增到最大值,然后再执行10分钟,也就是说总时间大概为30分钟。
但是因为场景是递增的,一开始我们并没有要求达到150TPS,同时登录场景TPS最大值能达到多少,我们现在也没法预知。根据经验来看的话,登录的TPS在当前的硬件环境中,就算是不走缓存,达到三、四百应该是没有多大问题的。
如果按最大400TPS来算,跑半个小时,需要的数据量就是54万,而我们造出来的用户量要远远大于这个量级。这里我们就先造200万的用户量,因为地址的数据量肯定大于用户的数据量,所以会多于200万。
先查当前DB中的数据量,再确定要造多少。
这数据量级明显不够。
怎么造出那么多数据量?造的数据主要分为:用户数据和订单数据。
- 登录用户
先了解表结构,造出数据只有符合业务逻辑才能使用。看用户表结构和数据:
地址表:
造数据时,不要往DB直接写存储过程插数据,除非你清楚表之间关系,且存储过程写得6。否则你会把DB弄得一团乱,最后不得不在数据库的表里改数据。推荐使用接口直接调用来造数据,操作简单,较安全。
代码造数据,就要做下面的分析。
用户表和地址表有对应关系,可通过下面代码查,地址表中的MemberID就是用户ID
@Override
public int add(UmsMemberReceiveAddress address) {
UmsMember currentMember = memberService.getCurrentMember();
address.setMemberId(currentMember.getId());
return addressMapper.insert(address);
}
造用户数据,就是实现注册流程。
先分析用户注册的代码,直接把其中的注册代码部分拿过来用。具体调用代码:
造数据需要关心注册流程?若我们是调接口造数据,就不需要;但若写代码开启多线程造数据,就得了解接口之间的调用关系。
截出中间一部分,分析它们的调用关系:
注册用户表中的密码都是加密的,可通过注册用户实现类代码:
@Override
public void register(String username, String password, String telephone, String authCode) {
...............................
//获取默认会员等级并设置
UmsMemberLevelExample levelExample = new UmsMemberLevelExample();
levelExample.createCriteria().andDefaultStatusEqualTo(1) ;
List<UmsMemberLevel> memberLevelList = memberLevelMapper.selectByExample(levelExample);
if (!CollectionUtils.isEmpty(memberLevelList)) {
umsMember.setMemberLevelId(memberLevelList.get(0).getId());
}
//插入用户
memberMapper.insert(umsMember);
umsMember.setPassword(null);
}
就可直接写一段代码来造用户数据:《造用户代码.java》
有用户数据,还要下单用户的地址等详细信息,才能完成下单。
- 用户地址
根据用户地址资源路径找到Controller层,查看用户地址的代码调用关系,如下:
然后找到用户地址的关键代码:
@Override
public int add(UmsMemberReceiveAddress address) {
UmsMember currentMember = memberService.getCurrentMember();
address.setMemberId(currentMember.getId());
//插入地址
return addressMapper.insert(address);
}
从这段代码中,我们可以观察到这几个信息:
- 调用地址接口需要用户登陆态,通过登陆态来解析用户ID号;
- 用户ID号是地址代码中的MemberID号;
- 用户ID号是自增加。
具体参考请见《造用户地址代码.java》。
通过上面代码,再开启Java线程池,就可把基础数据快速造完。造用户地址数据的时间记录:
最后造出:
表中的订单数据会在做基准场景时补充上去。等这些数据量都有了,我们在容量场景中就有了足够的铺底数据。
4 总结
性能场景中的数据到底应该做成什么样子。
造数据方法很多,不用拘泥于某种造数据手段,只要能快速造足够数据量就好。
RESAR性能工程中,性能场景需要两类数据:铺底数据和参数化数据。铺底数据需满足:
- 一定要造出符合生产量级的数据量;
- 数据量要真实模拟出生产的数据分布;
- 数据要真实可用。
参数化数据需要满足这两个条件:
- 参数化数据量要足够;
- 要符合真实用户的输入数据。
有这些知识,就不会造数据时混乱。
5 FAQ
- 为何要造符合生产量级的数据量?
- 为什么参数化时要用符合真实用户的输入数据?
通常我们执行性能脚本时不会执行一次,若按上面30min 100TPS的场景,对不可重复使用的数据,若我们每次执行前做一次数据,太不易用啦,但不造数据还不行,如何解决这样的数据问题?做数据库备份回滚。
静态铺地数据指图片、视频这些吗?是的。
参数化数据是否影响压测机的性能,看压测机压力就可以了吧?是的。不过要分析了参数化数据量的具体影响才能判断。
若压测环境跟生产环境硬件配置不对等,那数据量是否也等比缩放?也要缩放,不过不一定等比。要做基准测试才知道。
参数化直接从DB取,连接DB,查询数据需消耗时间,且占用数据库资源,这种参数化方式很明显对压测的性能有影响,为何推荐这种方式?
在参数化数据多的时候,建议用缓存或数据库中直接取数据的方式。但是你可以不用被测系统的缓存或数据库,独立搭建一个专门存参数化数据的缓存或数据库即可。
jemeter参数化文件一般超过多少条数据量会使jmeter成为瓶颈?没有定论。还是得看一下参数化的是什么。
造出生产量级数,确保应用,数据库,缓存在生产压力下运行;参数化用户输入数据,保障了数据多样性,造数很容易造成数据同化严重,热点集中,不能再现真实,400TPS跑半个小时,是否应该是72万数据量?
若数据在每个用户使用时是唯一的,那就应该是72万的数据量。
“对于唯一性数据(比如用户数据)来说,我们需要使用多少参数化数据是非常容易计算的。比如一个运行半小时的场景,TPS 如果是 100 的话,那就需要 18 万的数据量”要模拟每一个压测请求都是不同的用户发起的,这里需要构造18万个不同用户。
铺底数据就是已存在的数据,参数化数据就是压力测试发起请求时产生的新数据?
参数化数据有两种。一种是用户输入的但数据在铺底数据中没有;还有一种是铺底数据中必须有的数据,比如说用户名之类的。
真实环境下单都是要真正的支付钱的,这个怎么解决
如果对方提供测试系统就可以连。如果不提供,那只能mock了
尽量模拟真实用户效果,但像我们测试web一般都是忽略了css,js等直接测试主接口,这是否合理?
对后端的压力来说,是合理的。若从用户角度,显然不合理。 所以要做相应换算。
标签:场景,性能,用户,缓存,参数,篇文章,数据量,数据 From: https://blog.51cto.com/u_11440114/6222011