Jmeter服务器性能压测-用户登录实例CSV方式

为什么用CSV方式压测,因为用jdbc链接数据库,我发现数据库数据量量大的情况下,Jmeter会内存溢出

第一步:数据准备,根据登录接口需要的参数准备测试数据

例子中,测试的登录接口需要4个参数化数据
Step1:数据库直接准备够需要用到的数据,插入还是update随便喽,sql语句可以参考我的分类“sql语句”
比如我用的sqlyog,准备好数据后,导出数据

根据我图片标注,按照需要进行勾选

导出为xls文件,打开后,另存为csv文件

第二步:Jmeter脚本(已添加用户定义的变量)
1.新建一个线程组

2.设置线程需要并发多少

3.性能测试,需要配置缓存清理,这里需要配置清理下http缓存管理器和Http Cookie 管理器

缓存管理器需要按照如图勾选

HttpCookie管理器需要按照如图勾选

4.创建定时器,也就是我们常说的集合点

同步计时器需要注意,配置的模拟用户组的数量与线程数量保持一致或小于线程数,下面的时间表示等待1秒后,集体访问请求

5.配置CSV文件

文件名:点击浏览选择自己文件位置即可
文件编码:不解释,一般UTF-8
变量名称:自定义变量名称,顺序比较关键,第一个变量名称即对应CSV文件中第一列内容,所以需要核对自定义变量与CSV文件保持一致
忽略首行:一般有列名会选择True
分隔符:,即可,保持与CSV文件一致
剩下的几个如果有特殊需求,可以查下百度改改,默认即可

6.参数调用,下面试Http请求的调用CSV文件参数的方法

原文地址:https://www.cnblogs.com/surenliu/p/12071678.html

时间: 2024-08-11 06:46:40

Jmeter服务器性能压测-用户登录实例CSV方式的相关文章

接口测试及服务器性能压测

目前移动端app大都还是采用的http或者https协议写的restful接口,一般的辅助类http劫持(fiddler,charles)和模拟发送(postman)工具都可以满足单次单个接口的测试需求,但这种依附工具的测试很难满足多接口调用逻辑验证问题,也不太灵活,没办法做到数据化,还有就是对于接口压测和服务器性能压力测试无法满足,又得借助于其他压测工具(Jmeter loadrunner等),设计一套基于http和https灵活定制的接口测试框架还是很有必要的. 一般app接口调用都要都要传

Jmeter之性能压测Stepping Thread Group 逐步增加并发数 阶梯式加压并发 (十五)

前段时间有描述过性能的测试类型 配置负载 Big Bang: 负载同时产生 Ramp up: 开始时候产生一定负载,然后每隔一段时间增加一些负载直到达到目标负载,这是典型模式 Ramp-up (with step): 分段产生负载.比如总共需要1000用户的负载,但是我们需要观察系统在250, 500, 700负载下的表现,到达这些负载后需要跑一段时间再增加新负载 Ramp up (with step), ramp down (with step): 跟上面类似,只是最后负载回归到0 Delay

基于Dubbo的压测调优实例

不久前参与开发了一个基于dubbo分布式框架的底层账单系统,并实现了其中的一部分业务接口,目前需对这些接口进行压测,以评估生产环境所能承受的最大吞吐量.笔者以其中一个查询接口为例来回顾此次压测的整体流程. 压测准备: 1.调用查询接口的测试jar包,作为dubbo-consumer,依赖了查询服务的api,测试module基于maven开发,执行maven clean package即可通过编译得到jar包 2.JMeter:Apache组织开发的基于Java的压力测试工具 方案: 无限次请求查

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题

(转)后端服务性能压测实践

作者:王清培(Plen wang) 传送门:https://www.cnblogs.com/wangiqngpei557/p/7953453.html ---------------------------------------------------------------------分割线------------------------------------------------------ 入职新公司,没人理我,负责的需求开发一直很忙,要么环境有问题,要么Bug卡住我找开发,回了一句

感受真实性能压测的“洪荒之力” 压测宝有奖体验中

作为测试,你有没有遇到这样的问题:1.熬了多少个日夜的系统终于快上线了,不知道上线后系统负载能力怎样?2.促销季到了,应用性能如何?到底能不能支持500w并发用户?3.怎么做压测才能更接近线上真实环境? 系统负载有多强,压测一下就知道.云智慧压测宝3步6分钟 开启真实用户的性能压测 8月16至9月2日申请试用压测宝,感受真实压测的洪荒之力,还有机会获得优酷视频会员卡,速速来领- 参与活动赢优酷会员卡 1.从这里申请试用压测宝:[url=http://yacebao.com/landingPage

swingbench-免费的oracle性能压测工具

SwingBench介绍: SwingBench由负载生成器,协调器和集群概述组成.该软件使得能够生成负载并且将图表的事务/响应时间映射. SwingBench可用于演示和测试诸如实际应用集群,在线表重建,备用数据库,在线备份和恢复等技术 SwingBench附带的代码包括6个基准,OrderEntry,SalesHistory,TPC-DS Like,JSON,CallingCircle和StressTest .. OrderEntry基于Oracle11g / Oracle12c附带的"oe

性能压测诡异的Requests/second 响应刺尖问题

最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码.debug.fixbug都逐渐收尾,进入上线前的性能压测. 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数. 毕竟这次转java的服务都是集团核心公共服务(主要是订单域服务).(等我们顺利上线了,我再来好好总结下其中的坎坷和壮举.) 废话不多说了,直接进入主题. 由于这次压测主要重点是关注正向的两个核心订单服务,下单服务.查单服务.查单服务初步压测下来问题不大,主要是db的索引和cache的问题. 下单

Jmeter(五)性能压测

一.压力测试场景设置--windows环境 压力测试:一般压测时间10-15min,N个并发用户一直在请求.监控服务的cpu.内存等: 稳定性测试:一般压测一周,2天,1天等,看系统会不会崩掉,会不会内存泄露等. 一般我们在做压力测试的时候,分单场景和混合场景,单场景也就是咱们压测单个接口的时候,多场景也就是有业务流程的情况下,比如说一个购物流程,那么这样的场景就是混合场景,就是有多个接口一起来做操作. 1.单场景,一个请求就可以了  2.混合场景,多个请求 3.压测时间,一般场景都是运行10-