-
压测
2019-03-22 20:36:01http压测: ab测试:https://blog.csdn.net/u011277123/article/details/78913649 locusthttp压测:
ab测试:https://blog.csdn.net/u011277123/article/details/78913649
locust
-
fio压测报告与fio压测方法
2019-11-20 16:37:27fio安装,通过本文档,在生产环境中,磁盘I/O如何进行压测,掌握fio压测方法与如何书写fio压测报告 -
ab压测与siege压测
2019-06-30 11:02:01本文的核心内容:Web压力测试指标,ab压测与Siege压测工具的使用。本文的核心内容:ab压测与Siege压测工具的使用。
为了测试接口的性能、我们需要对接口进行压力测试,看看接口能承受多大访问量、在大访问量情况下性能怎样,这些数据指标好坏将会直接影响接口调用方的前端展示效果。
Web压力测试指标
1.TPS(transaction per second)
每秒钟完成的web请求响应数量
TPS=并发数/响应时间
TPS是衡量系统性能的重要指标
2.并发数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。
3.响应时间
响应时间是指系统对请求作出响应的时间。
4.吞吐量
吞吐量指的是单位时间系统传输数据总量。
可知吞吐量和TPS,并发数这两个因素是正比关系。
但是当TPS,并发数达到极限值时,吞吐量不升反降,这是因为系统资源产生了大的消耗。
ab 测试
ab是apachebench命令的缩写。
ab的原理:ab命令会创建多个并发访问线程,模拟多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的,因此,它既可以用来测试apache的负载压力,也可以测试nginx、tomcat等其它Web服务器的压力。
1)ab安装
yum -y install httpd-tools [root@vic html]# ab -V This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
2)ab 常用参数
常用请求参数:-n请求次数,-c并发数 -X 代理ip:代理端口 -n requests 请求次数 -c concurrency 并发数 -t timelimit 持续测试时间 单位[s] -X proxy:port 代理ip:代理端口
ab -n 100 -c 10 https://www.baidu.com/
3)测试报告说明:
一般我们需要关心 Requests per second和 Transfer rate。 一般接口rps需要满足>=300,并且 99.9的响应请求保证在300ms内 Connection Times (ms)和请求响应时间分布(Percentage of the requests served within a certain time (ms)) 几部分进行分析 This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.baidu.com (be patient).....done Server Software: BWS/1.1 Server Hostname: www.baidu.com Server Port: 443 SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128 Document Path: / Document Length: 227 bytes Concurrency Level: 10 Time taken for tests: 0.497 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 108197 bytes HTML transferred: 22700 bytes Requests per second: 201.39 [#/sec] (mean) Time per request: 49.655 [ms] (mean) Time per request: 4.966 [ms] (mean, across all concurrent requests) Transfer rate: 212.79 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 26 33 3.7 33 49 Processing: 9 11 1.0 11 16 Waiting: 9 11 1.0 11 16 Total: 35 44 4.2 43 66 Percentage of the requests served within a certain time (ms) 50% 43 66% 45 75% 46 80% 46 90% 48 95% 50 98% 56 99% 66 100% 66 (longest request) 这个表第一行表示有50%的请求都是在43ms内完成的, 以此类推,99%的请求是小于等于9ms的。
siege 测试
安装siege
为了支持https,需要先下载安装openssl
openssl地址:https://github.com/openssl/opensslgit clone https://github.com/openssl/openssl cd openssl ./config --prefix=/usr/local/openssl make make install openssl version
openssl安装完毕后,开始安装siege
siege地址:http://download.joedog.org/siege/siege-4.0.4.tar.gztar zxvf siege-4.0.4.tar.gz cd siege-4.0.4 make clean ./configure --prefix=/usr/local/siege --with-ssl=/usr/local/openssl make make install
注意:siege默认只支持255个并发数,可以自己自定义,修改/root/.siege/siege.conf下的limit数值。
1)使用说明
使用方式: siege [options] URL 示例: siege -c 10 -t 1m $url 模拟10个用户并发请求$url,持续1分钟
2)多url测试
1. 登录测试服务器准备需要模拟的请求列表文件,文件内容每行一个url url格式 http://host[:port]/request_uri 2. 请求示例: siege -c 200 -t 10s -f url.txt 并发100个用户持续10s, 随机从文件url.txt读取url Options: -g, --get Get请求 -c, --concurrent=NUM 并发请求数,默认 10 -r, --reps=NUM 循环测试次数 -t, --time=NUMm 测试时长: m[分],s[秒],H[小时] -t 1H 标识测试1小时 -d, --delay=NUM 两次读取url延迟请求间隔时间 -b, --benchmark 两次读取url间隔时间0,没有延迟 -i, --internet 随机读取url -f, --file=FILE FILE, select a specific URLS FILE. -l, --log[=FILE] LOG to FILE. If FILE is not specified, the default is used: PREFIX/var/siege.log -H, --header="text" Add a header to request (can be many) -A, --user-agent="text" Sets User-Agent in request -T, --content-type="text" Sets Content-Type in request --no-parser NO PARSER, turn off the HTML page parser --no-follow NO FOLLOW, do not follow HTTP redirects
3)测试报告说明
siege -c 100 -t 10s http://www.baidu.com
Lifting the server siege... Transactions: 33554 hits 总请求次数 Availability: 100.00 % 成功率 Elapsed time: 59.67 secs 执行时间 Data transferred: 74.03 MB 总数据传输大小 Response time: 0.18 secs 响应时间,显示网络连接的速度 Transaction rate: 562.33 trans/sec 平均每秒完成次处理请求数 Throughput: 1.24 MB/sec 平均每秒传输数据 Concurrency: 99.70 最大连接数 Successful transactions: 33554 成功请求次数 Failed transactions: 0 失败请求次数 Longest transaction: 1.17 最长请求时间 Shortest transaction: 0.00 最短请求时间
-
Jmeter压测
2021-01-14 18:23:15 -
基于Jmeter的性能压测平台实现
2018-10-25 17:33:25很早就想要一套属于自己的性能压测平台,原因是使用了阿里云的性能测试PTS,就挺羡慕能有一个这样的性能测试平台,但毕竟人家的东西我们高攀不起(要钱的),而且阿里云的性能测试平台是不支持多种协议的(比如我有...告知:目前已做了兼容性的改造,支持适配Jmeter5.4.1的编译和运行!
很早就想要一套属于自己的性能压测平台,原因是使用了阿里云的性能测试PTS,就挺羡慕能有一个这样的性能测试平台,但毕竟人家的东西我们高攀不起(要钱的),而且阿里云的性能测试平台是不支持多种协议的(比如我有一个项目要用websocket测试,结果人家就支持http压测)。
说到开发自己的性能测试平台,肯定想到的是Jmeter,因为开源的性能测试工具没有比它更强大的了,所以第一个想到的是怎么把它变成性能测试平台,很多人首先想到的是通过jenkins结合jmeter,我想那也只能叫调度平台,不能叫性能测试平台。通过对Jmeter和Java快速开发框架的深入了解,我发现做一个自己的性能压测平台是可行的,而且网上也有人正在做。开发的过程肯定是无限的踩坑(开源的东西就这样),相对收获来说应该值的。以下是我针对开源的Java快速开发框架和别人实现的部分成品,再结合JMeterEngine的深入学习,梳理的平台架构:
该平台已经开源(无Java经验的测试人员慎入,以免烦扰): https://gitee.com/smooth00/stressTestSystem
针对小白,提供了一键部署包:https://gitee.com/smooth00/stressTestSystem/releases,只要安装了JDK1.8,下载安装包stressTestSystem-min-5.1.1.rar 解压后,通过批处理脚本就能运行压测平台。一键部署包所对应的Docker镜像文件可以直接pull到:docker pull smooth00/stresstest-system
Docker部署方案参考:https://gitee.com/smooth00/stressTestSystemDocker
以下是主要的技术选型及说明:
- 核心框架:Spring Boot 1.5
- 安全框架:Apache Shiro 1.3
- 视图框架:Spring MVC 4.3
- 持久层框架:MyBatis 3.3
- 定时器:Quartz 2.3
- 数据库连接池:Druid 1.0 (阿里开源)
- 日志管理:SLF4J 1.7、Log4j
- 页面交互:Vue2.x(前后端未分离)
- 前端监控:ECharts 3.8
- 压测内核(即JMeterEngine):Apache JMeter 4.0(现已支持5.1.1、5.4.1版本)
- 脚本调用内核:Apache Commons Exec 1.3(弃用)
- 远程执行命令:Ganymed build210
- 批量上传组件:bootstrap-fileinput v4.5.2
- JVM内部缓存:Guava 18.0
选用的快速框架是经量级的,而且是方便快速部署的:
【renren-fast开发框架】,具体可以上网获取:https://www.renren.io/guide/
性能测试平台的项目结构:
stress-test ├─doc 项目SQL语句 │ │─lib 项目引用外部jar包(默认没有) │ ├─common 公共模块 │ ├─aspect 系统日志 │ ├─exception 异常处理 │ ├─validator 后台校验 │ └─xss XSS过滤 │ ├─config 配置信息 │ ├─modules 功能模块 │ ├─api API接口模块(APP调用) │ ├─job 定时任务模块 │ ├─oss 文件服务模块 │ ├─sys 权限模块 │ └─test 压测模块 │ ├─RenrenApplication 项目启动类 │ ├──resources │ ├─mapper SQL对应的XML文件 │ ├─static 第三方库、插件等静态资源 │ ├─views 项目静态页面 │ └─application.yml 环境配置
平台已实现的部分功能:
(1)用例管理:
用例管理支持jmx脚本的上传和参数化文件及测试附件的上传,一个用例创建一个目录(脚本、参数文件、附件、测试报告都在同一用例下保存)。删除用例时会自动删除用例下所关联的脚本,并一并删除已同步到各个节点的文件。
(2)脚本文件管理
每个脚本具有启动和停止压测线程的功能(具有状态标识),每个参数化文件或附件具有同步到各个节点的功能(同步完成后标识为同步成功)。
支持脚本文件在线修改(基于jmx文件的模板化编辑):
启动脚本可以选择指定节点压测,只要空闲状态的节点都可以选择,真正实现并行任务执行:
脚本文件除了启动和停止功能,还能配置是否开启报告生成和是否开启前端监控,监控是echarts图形监控,如下:
调用脚本进行压测的方法分为两种:
压测模式 调用模块 特点 优缺点 脚本调用模式 Apache Commons Exec 相当于通过远程执行jmeter命令调用脚本,完全依赖于jmeter bin目录 优点:实现简单,无需过多编程;
缺点:无法多线程控制,无法开启echarts监控,完全依赖本地Jmeter终端引擎调用模式 JMeterEngine 用的是Jmeter压测内核,通过runTest方法开启压测线程,通过stopTest方法结束压测线程 优点:更加轻量级,多线程控制,支持单独停止某个脚本的测试,支持echarts监控,支持个性化扩展开发;
缺点:需要依赖更多编程实现另外支持将脚本添加到任务,用的是框架本身的任务管理,加上cron表达式生成器插件的应用,可以方便的实现脚本的定时任务创建,这样就能定时执行脚本(这个是LR所不具备的功能,一般可以用于接口的自动化测试):
(3)测试报告管理
报告生成模式 调用模块 特点 优缺点 Jmeter Home命令模式 GenerateReport ByScript 相当于通过执行jmeter命令调用报告,完全依赖于jmeter home目录 优点:实现简单,无需特别编程,直接调用;
缺点:无法多线程控制,无法多用户并发生成报告,完全依赖本地Jmeter_Home目录的配置Web进程多线程模式 GenerateReportLocal 采用本地web进程来实现CSV报告文件转化成html模板报告 优点:更加轻量级,多线程控制,使用更加轻便,配置简单(不依赖于Jmeter Home的配置);
缺点:需要依赖更多编程实现默认执行脚本过程中,生成了CSV报告,通过【生成报告】按钮,触发将csv报告转换成html DashBoard(这一步也是通过Commons Exec调度jmeter命令完成),展示效果如下:
除了测试报告,还支持调试报告(显示接口请求信息,类似于Jmeter的查看结果树) ,原理是调用xls模板将JTL结果转为html报告(区别于测试报告是将CSV结果转为html报告),展示效果如下:
(4)分布式节点管理
分布式节点管理通过Ganymed远程执行linux命令,来启动或是停止各节点的Jmeter-server,启动命令格式如下:
//启动节点 String enableResult = ssh2Util.runCommand( "cd " + slave.getHomeDir() + "/bin/testCases/" + "\n" + "sh " + "../jmeter-server -Djava.rmi.server.hostname="+slave.getIp());
如果是禁用节点,就是通过远程执行杀进程的命令:
ssh2Util.runCommand("ps -efww|grep -w 'jmeter-server'|grep -v grep|cut -c 9-15|xargs kill -9");
这种方式挺方便,省了在多台linux节点机上,手动去连接和启动jmeter(分布节点越多越显得方便快捷)。而且节点管理支持节点权重控制(原理是基于进程修改线程组的线程数属性来实现)。
另外跟原来相比,分布式节点管理增加了校准功能,就是为了解决节点因为人为因素停了,而管理端不能及时的作出判断,现在通过校准可以将后台节点的进程状态跟前台同步一次(避免进程异常关闭或错误启动),目前不是自动校准。因为无论是实时监听端口还是定时校准,效率都不是最好的。以后可以尝试在压测过程中添加监听机制,来实时监测节点状态,而非压测时段就通过手动点击校准即可,这样会相对经济一些。
(5)监控扩展(Grafana+InfluxDB)
由于我在以前的一篇文章中写过有关Grafana+InfluxDB与Jmeter的监控(关于Jmeter长时间压测的可视化监控报告),可以直接拿过来集成使用。集成的方式是开启Grafana的匿名登录(在defaults.ini中配置),到官网下一个Jmeter的监控视图JSON模板导入,同时以跳转的方式将Grafana嵌入到平台的iframe中。var URL_IP = parent.location.host; var URL_PORT = parent.location.port; window.location = "http://"+URL_IP.replace(":"+URL_PORT,"")+":3000/d/joulMbxmz/apache-jmeter-dashboard?orgId=1";
另外可以将Grafana和InfluxDB及一键启动脚本与性能压测平台一起部署,实现在部署层面上进行集成和无缝对接使用。
写到这我们的性能压测平台前期部分基本介绍完了,还有些功能未开始开发,比如像阿里云PTS的压测场景配置,这比较复杂,相当于是把脚本的场景设置移到WEB界面上,另外还要结合定时器进行脚本的灵活调度(发起压测、结束压测、持续时间、测试周期等),目前来看还没想好怎么实现。但是可以先实现线程组的在线管理:
(6)线程组管理
线程组管理的原理也不复杂,就是上传脚本时,通过dom4j递归扫描Jmx脚本(本质上是xml)的节点,获取线程组的配置节点参数,保存入库,然后在界面上修改和管理,改完还可以同步回Jmx脚本(也是通过dom4j对xml进行set配置)。目前实现的管理的线程组类别包括默认的ThreadGroup、jp@gc - Stepping Thread Group、jp@gc - Ultimate Thread Group,这三种已经算最常用的了。线程组管理的目的就是免去简单的线程配置(如并发数配置、线程组禁用)还要线下设置,设置完又要上传,另外脚本的线程组配置在平台界面上也能一目了然,避免又要临时打开Jmeter工具进行查看。
(7)压测节点监控【该功能未开源】
既然有了分布式节点管理,那边我们也可以做到对节点的分布式监控,在Influxdb-Grafana的基础上,引入telegraf来实现;我们通过界面上,加入监控开启和停止的按钮,再结合节点上部署的一些批处理命令,来实现一键启动监控代理。
启动和关闭的核心代码如下:
/** * 批量切换节点的监控状态 */ @Override public void updateMonitorBatchStatus(List<Long> slaveIds, Integer monitorStatus) { String execStr=""; for (Long slaveId : slaveIds) { StressTestSlaveEntity slave = queryObject(slaveId); // 本机节点无需远程操作 if ("127.0.0.1".equals(slave.getIp().trim())) { Runtime r = Runtime.getRuntime(); //执行本地操作系统命令,不关心返回结果, Process p = null; try { if(OS_NAME_LC.startsWith("windows")){ if (StressTestUtils.ENABLE.equals(monitorStatus)) execStr = "cmd.exe /c \""+StressTestUtils.getJmeterHome()+"\\telegraf\\start.cmd\" -a"; else execStr = "cmd.exe /c taskkill /im telegraf.exe /f"; }else{ if (StressTestUtils.ENABLE.equals(monitorStatus)) execStr = "sh "+StressTestUtils.getJmeterHome()+"/telegraf/startUp.sh "+slave.getSlaveName(); else execStr = "sh "+StressTestUtils.getJmeterHome()+"/telegraf/stop.sh "+slave.getSlaveName(); } p = r.exec(execStr); p.waitFor(); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } finally { if(null!=p){ p.destroy(); p=null; } } //更新数据库 slave.setMonitorStatus(monitorStatus); update(slave); continue; } //其他节点需要SSH远程连接 SSH2Utils ssh2Util = new SSH2Utils(slave.getIp(), slave.getUserName(), slave.getPasswd(), Integer.parseInt(slave.getSshPort())); // 避免跨系统的问题,远端由于都时linux服务器,则文件分隔符统一为/,不然同步文件会报错。 String telegrafServer = slave.getHomeDir() + "/telegraf/telegraf"; String md5Str = ssh2Util.runCommand("md5sum " + telegrafServer + " | cut -d ' ' -f1"); if (!checkMD5(md5Str)) { throw new RRException(slave.getSlaveName() + " 监控模块出错!找不到telegraf启动文件!"); } //如果是开启监控 if (StressTestUtils.ENABLE.equals(monitorStatus)) { //启动监控 execStr = "sh " + slave.getHomeDir() + "/telegraf/startUp.sh " + slave.getSlaveName()+" "+stressTestUtils.getLocalIp(); }else{ //禁用监控 execStr = "sh " + slave.getHomeDir() + "/telegraf/stop.sh"; } String enableResult = ssh2Util.runCommand(execStr); logger.error(enableResult); if (!enableResult.contains("telegraf")) { throw new RRException(slave.getSlaveName() + " telegraf执行失败!请先尝试在节点机命令执行"); } //更新数据库 slave.setMonitorStatus(monitorStatus); update(slave); } }
从代码我们也可以看出,我们将telegraf启动和配置文件都放置在jmeter节点的根目录下,这样能方便远程SSH调用,同时我们将监控平台的IP和节点名称也发送过去,并更新到telegraf.conf文件中,这样启动的telegraf进程就会将监控数据发回到我们的influxdb,并通过grafana监控到。以下是监控的效果:
这样我们就实现了对压测机的监控(在测试过程中不对压测机监控是不合理的,特别是CPU、内存、网络IO等,万一出现测试机的性能瓶颈由于不能及时发现就会导致无用功),除了压测机的监控,我们可以由点及面,做出一个压测平台的监控服务平台,对被测服务端也进行监控。
(8)平台日志监控【该功能未开源】
说是日志监控,目前只是实现了日志的前台展现功能,将info、debug、warn、error不同的日志级别用颜色标识。获取日志的方式是开通websocket通道,用spring-boot推送实时日志到前端页面显示,这种方式其实也没什么特别的,在网上能找到大把的实现方式,但其作用还是挺大的,平台运行或是压测过程中如果出现异常,直接在前台跟踪日志即可,没必要再跑到后台服务器上用tail命令跟踪了,易用性变强了。
(9)支持redis缓存测试数据并生成报告【该功能未开源】
通过redis缓存压测的监听数据,并自动生成报告(并套用自定义的报告模板),在速度上要远快于csv生成html报告,主要是为了解决测试报告文件太大生成报告太慢的问题(利用redis集群可以加大测试数据缓存的并发性),另一个好处是将自己需要的测试结果缓存到redis中,可以方便自定义更多元化的报告展现形式,提升了平台的扩展性(该功能不对外开源)。
更正说明:写这篇文章的时候,阿里云的PTS刚刚能支持原生jmeter(但前提是有项目支持你花这钱,按压测流量收费,并只支持外网压测),也就是能支持websocket的压测,具体使用说明他们也提供了教程:https://help.aliyun.com/document_detail/93627.html?spm=5176.7946858.1219570.3.4ced572dQgCraE
版权声明:本文为博主原创文章,转载请附上博文链接!https://blog.csdn.net/smooth00/article/details/83380879
性能测试光靠工具还不行,还需要有理论和实战技能的武装,请关注我的在线录播课《性能测试核心知识解惑》
-
压测和防止压测方案
2017-12-15 09:42:21压测、防止压测方案 1. 压测 (1) 压测工具:ab (2) 压测请求方式:get (3) 压测域名:url (4) 压测方案:10万请求,500并发 (5) 压测脚本 ab -n 100000 -c 500 url (6) 展示压测结果 从上面分析... -
性能压测
2019-12-30 13:45:35性能压测注意事项 ...注意点:Jmeter压测会产生一系列的问题,影响因素很多,比如带宽影响,宿主机的性能等都会影响压测结果,一般推荐千兆带宽,内网压测,宿主机配置过低可以采用集群压测,内外网压测差距极大 ... -
压测流程
2020-04-07 10:55:12一般压测的时候,我会先本地压测,然后在没有环境污染的环境进行压测,主要原因是本地压测的时候,可以进行代码调整,这个时候压测的结果会不准,但是压测时间长的时候,基本可以看出一些系统问题,会报一些系统错误... -
压测工具
2020-12-23 16:34:54jmeter 支持 http tcp等多种协议的压测工具 https://github.com/apache/jmeter fortio 自带web控制台的http压测工具 ... ...wrk http压测工具 ...ghz grpc压测工具 https://github.com/bojand/ghz ... -
ClickHouse压测
2020-10-08 13:16:05文章目录一、压测工具1.1 下载路径1.2 生产DML语句1.3 创建测试表1.4 导入测试数据1.5 生成测试数据:将“星型模式”转换为非规范化的“平面模式”二、压测指标 本文选用CK官方提供的一个测试方案:SSBM (Star ... -
压测——普通接口压测
2019-09-03 11:56:58普通接口压测就是对接口的高频率访问 验证条件主要看两点,一是请求的成功率 二是请求的响应时间 辅助验证条件:可以看服务器的CPU以及内存的运行情况 实际操作 确定压测接口,设计好脚本,通知有关部门压测时间 ... -
ab压测_上传图片进行压测
2020-11-06 22:00:02上传图片进行ab压测 背景 今天在做图片分类任务的压力测试,我使用ab(Apache Benchmark)这个压测工具进行压测,这里完整记录下如何上传图片进行ab压测。 流程 整个压测流程大致有以下三个步骤: 构造压测文件; ... -
分布式压测
2019-12-27 11:04:21什么是分布式压测 普通压测:单台机可以对目标机器产生的压力比较小,受限因素包括CPU,网络,IO等 分布式压测:利用多台机器向目标机器产生压力,模拟几万用户并发访问 Jmeter分布式压测原理 总控... -
Linux压测接口脚本
2021-03-17 17:36:08Linux压测接口脚本 -
Kafka压测
2021-01-26 22:08:481)Kafka压测 用Kafka官方自带的脚本,对Kafka进行压测。Kafka压测时,可以查看到哪个地方出现了瓶颈(CPU,内存,网络IO)。一般都是网络IO达到瓶颈。 kafka-consumer-perf-test.sh kafka-producer-perf-test.... -
redis压测
2020-01-09 14:17:44前言:这里对压测进行一些简介,本篇介绍redis压测场景,使用redis官方自带的工具进行压测。 压测相关的一些指标: QPS(Queries Per Second):每秒能够响应的查询次数,也即是最大吞吐能力(吞吐量)。 TPS... -
压测接口线程数设置_Jmeter并发压测和持续性压测
2021-01-09 17:18:25前言在进行接口性能自动化测试过程中,压测的方式有2种:同时并发设置线程组、执行时间、循环次数,这种方式可以控制接口请求的次数持续压测设置线程组、循环次数=勾选“永远”,调度器(持续时间),这种方式可以控制... -
【kafka压测】关于kafka性能压测(kafka内置压测工具)
2020-08-10 13:56:15使用Jmeter压测Kafka:https://www.blazemeter.com/blog/apache-kafka-how-to-load-test-with-jmeter/ ...kafka内置压测: //生产压测 bin/kafka-producer-perf-test.sh --topic test_perf... -
jmeter压测
2019-07-05 11:29:52阿里巴巴在开源压测工具 JMeter 上的实践和优化 原创:韩勇阿里巴巴中间件 原文链接:https://mp.weixin.qq.com/s/pb3jwOiRS7uszmMHK7QFIA 本文是《如何做好性能压测》系列专题分享的第三期,该专题将从性能... -
压测测试
2020-10-28 09:19:26压测 wrk -t1 -c10 -d2s http://127.0.0.1:8080/access 使⽤⽅法: wrk <选项> <被测HTTP服务的URL> Options: -c, --connections <N> 跟服务器建⽴并保持的TCP连接数量 -d, --duration <T... -
压测准备
2020-04-29 16:20:371.脚本是否正确 2.redis情况(使用redis情况看压测的数量) 3.数据库数据量 4.主机cpu和内存情况 5.压测时调用方法的耗时情况 6.错误日志 -
静默压测
2020-06-10 11:15:36静默压测 脱离UI进行JMeter压测 命令格式: jmeter -n -t jmeter_filename -l jtl_filename -n :非 GUI 模式 -> 在非 GUI 模式下运行 JMeter -t :测试文件 -> 要运行的 JMeter 测试脚本文件 -l :日志文件... -
wrk压测工具简易使用之压测命令与lua压测脚本
2021-02-24 15:13:53在安装好wrk工具后,进入到wrk目录,执行压测命令,向地址为http://127.0.0.1:18880/testapi发送post请求,每次的请求内容由test.lua脚本的request方法生成 压测命令:./wrk -t1-c1 -d1s --latency -s test.lua ...