测试命令 ​ 这条命令redis自带 redis-benchmark [option] [option value] redis 性能测试工具可选参数如下所示: 序号 选项 描述 默认值 1 -h 指定服务器主机名 127.0.0.1 2 -p 指定服务器端口 6379 3 -s 指定服务器 socket 4 -c 指定并发连接数 50 5 -n 指定请求数 10000 6 -d 以字节的形式指定 SET/GET 值的数据大小 2 7 -k 1=keep alive 0=reconnect 1…

1.redis-benchmark 100个并发连接,100000个请求: redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000 存取为100个字节的数据包: redis-benchmark -h 127.0.0.1 -p 6379 -q -d 100 只测试某些操作的性能: redis-benchmark -t set,lpush -q -n 100000 只测试某些数值存取的性能 redis-benchmark -n 100000 -q…

单线程没有出现并发问题. 链接太多爆炸了 把连接改到50,没有问题 改回1000: emmm159,看来相当一部分拒绝了 并且8180-10000到头了 cpu爆炸了 观察下这种程度的并发用乐观锁 一个线程平均等待时间: 最惨的倒霉蛋花了203ms才完成,emmm不是很令人满意呀…

转自:https://blog.csdn.net/qq_41305266/article/details/81071278. 一.JMeter入门 下载链接 http://jmeter.apache.org/download_jmeter.cgi 添加线程组 设置http请求默认值 添加待压测的http请求 添加聚合报告监听器 启动测试 1000个线程,循环10次,即10000个请求 二.redis 压测 1. redis-benchmark -h 127.0.0.1 -p 6379  -c 1…

一.JMeter入门压测 1.打开JMeter工具,选中测试计划->右键添加->线程(用户)->线程组,页面中的线程数就是并发数,页面中的Ramp-Up时间(秒)表示通过多长时间启动起来这些线程,如果值为0,表示这些线程一起启动起来. 2.选中线程组->右键添加->配置元件->HTTP请求默认值,来配置一个默认请求.页面中的协议填http,服务器名称或IP填localhost,端口号填8080. 3.选中线程组->右键添加->Sampler(取样器)->…

说明:图片截得比较大,浏览器放大倍数看即可(涉及到隐私,打了码,请见谅,如果有疑问,欢迎骚扰). 最近在压测过程中,出现获取不到redis连接池的问题 xshell连接redis服务器,查看连接数,发现比redis.properties文件中配置的连接数要大 redis-cli -p port -a name@password info | grep -e "connected_clients" 停止压测后,连接数依旧差不多,难道是连接池没有释放? 于是查了下tcp连接到底是不是都是我…

使用命令 ab -c 20000 -n 100000 'http://127.0.0.1:9050/v1/api.store.xxx'进行压测,并同时进行了交叉测试,结果如下: 高并发情况下数据目前没有出错. Redis性能和框架封装的Cache性能差的不多. 1. Redis 1.1. Redis自增 ab -c 20000 -n 100000 'http://127.0.0.1:9050/v1/api.store.redis.add' This is ApacheBench, Version…

使用celery的backend异步获取结果,本文使用rabbitmq 和 redis分别作为backend,代码对比如下 from celery import Celery, platforms import time import os from datetime import datetime app = Celery('proj', broker='amqp://admin:admin@ip:5672', //rabbitmq backend='amqp://admin:admin@ip…

redis做压测: 可以用自带的redis-benchmark工具,使用简单 压测命令:redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 压测需要一段时间,因为它需要依次压测多个命令的结果,如:get.set.incr.lpush等等,所以我们需要耐心等待, 如果只需要压测某个命令,如:get,那么可以在以上的命令后加一个参数-t(绿色部分): 1.redis-benchmark -h 127.0.0.1 -p 6086 -c 50 -n 1…

郑昀 基于刘勤红和石雍志的实践报告 创建于2015/8/13 最后更新于2015/8/19 关键词:压测.TCPCopy.仿真测试.实时拷贝流量 本文档适用人员:技术人员 提纲: 为什么要做仿真测试 TCPCopy是如何工作的 实作:仿真测试的拓扑 实作:操作步骤 可能会遇到的问题 ip_conntrack 少量丢包 离线重放 不提取7层信息 观测的性能指标 0x00,为什么要做仿真测试 线下的传统压力测试,难以模拟真实流量,尤其难以模拟正常流量混杂着各色异常流量.所以,线下压得好好的系统,上线…

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

这几天在搭Cassandra集群以及对Cassandra的性能测试,步骤还挺多,记录一下. 关于Caaandra在服务器上配置多节点集群,可以参考一下文章: http://blog.csdn.net/cloud_xy/article/details/48091003 http://blog.csdn.net/cloud_xy/article/details/48107251 以及Cassandra官方文档:http://cassandra.apache.org/doc/latest/gettin…

压测机器: 100台docker redis集群:16个分片 在开始压测的半个小时中,一直很稳定,ops稳定在20w左右.但是接下来突然ops断崖式下跌,ops降到了3w以下.然后持续一段时间,直至变为0. 问题排查: 1. 检查docker docker都很健康,cpu占用率,内存占用率都正常,不到30%.网络状况也很好. 2. 检查mq mq也正常,响应时间没有被可以拉长 3. 检查redis集群 redis集群中,发现所有分片内存基本上被打满 由于内存被打满,导致redis会强制进行键驱逐…

都说hello world 很简单,应该能承受很大的请求压力,那么到底有多大?你知道吗?如果知道,那咱们就不继续了.如果不知道,我们来看一下! 1. 准备工作,快速建立一个基于springmvc的helloworld 1.1. 在pom.xml引入spring必须的包级日志组件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/PO…

介绍分为四部分 1.wrk简述 2.wrk安装 3.wrk运行参数 4.wrk高级用法 1.wrk简述 当使用ab做压测的时候发现,ab的客户端消耗很大,而且测试时性能较差,测试redis,spring boot时性能都与官方介绍相差太多,由此引入wrk. wrk是一款简单的HTTP压测工具,托管在Github上, https://github.com/wg/wrk. wrk 的一个很好的特性就是能用很少的线程压出很大的并发量. 原因是它使用了一些操作系统特定的高性能 io 机制, 比如 sel…

这里,我们利用 LoadRunner 来制定场景,且以测试 tps 值为导向,主要介绍手工场景 单服务器的业务请求处理能力 tps 值在 10~200 是合理的:如果是访问单接口不走关系型数据库的,访问的是 redis (内存里面读)那么 tps 在 1000~2000 左右是合理的 单负载机的最大并发多少?不管是 LR 和 JMeter,10~4000 是合理的 如果要测试响应时间或者是说并发,是要有前提条件的:比如说并发为 100 的响应时间为 XX,响应时间为 1 s 支持的最大并发量为…

背景 在美团的价值观中,以“客户为中心”被放在一个非常重要的位置,所以我们对服务出现故障越来越不能容忍.特别是目前公司业务正在高速增长阶段,每一次故障对公司来说都是一笔非常不小的损失.而整个IT基础设施非常复杂,包括网络.服务器.操作系统以及应用层面都可能出现问题.在这种背景下,我们必须对服务进行一次全方位的“体检”,从而来保障美团多个业务服务的稳定性,提供优质的用户服务体验.真正通过以下技术手段,来帮助大家吃的更好,生活更好: 验证峰值流量下服务的稳定性和伸缩性. 验证新上线功能的稳定性. 进…

1.登录linux机器 a.打开mac的钥匙串 b.ssl root@ip c.输入密码 常用命令: cat /proc/version  查看系统版本 cat /etc/issue control +z 取消wget下载 2.安装nginx php7.0 mysql5.6 redis 等 安装mysql5.6 安装php7.0 安装nginx 安装redis 3.安装压测工具 siege 安装siege 设置环境: 因为默认是255个并发,如果你想突破这个限制,需要自己配置config.首先你…

1.本次对比基础环境信息如下: springboot版本1.5.10 centos虚机4c6G,版本7.4 centos实机2u16c40G,版本7.4,虚机运行在实机上 ab版本2.3 jprofiler版本9.1.1 2.压测接口说明 天花板:指的是一个空接口,没有任何实现,直接返回,如 @RequestMapping(value = "/test", method = RequestMethod.GET) public void test() { } 服务接口:指的是具有一定业务…

在公司做压力测试也挺长时间了,每次测试前环境数据准备都需要话费较长时间,所以一直在考虑能不能将整个过程实现自动化进行,于是就抽空写了一个自动化脚本,当然这个脚本目前功能十分简陋,代码也不完善,很有很多需要改的地方,后续再优化.文中如有错误或者不妥之处,还望指教. 一.设计思路 1.初始化数据库(导入用户,清除数据等) 2.初始化缓存(使用了redis缓存优化系统) 3.执行压力测试 二.目录结构…

Coolhash 当前性能指标:读写吞吐量超过百万,千万级别查询1秒完成,连续48小时打满CPU强压力运行稳定.redis官方公布读写性能在10万 tps,leveldb官方公布写性能在40万tps,读在6万tps,redis和leveldb都是倾向k/v高速读写,但不具备高效检索功能,没有 join关联设计.coolhash可以拿去pk世界上任何的数据库引擎产品. 下面以redis为例进行了详细测试和技术分析,leveldb 的性能可详见其官方资料,在写性能上优于redis,但是读性能和多数据…

本文记录在jimdb压测过程中遇到的各种小坑,望能够抛砖引玉. 1.压测流量起来后,过了5分钟左右,发现ops突降,大概降了三分之一,然后稳定了下来 大概原因:此种情况,jimdb极有可能某个分片的连接数打满,从而导致分片的cpu达到100%. 调优方案:首先,默认分片连接数为1w,此时可以根据自己的需求,如果自己的docker数量很少,可以调整成2w,反之则3w. 然后,看程序中的操作,是不是有pipeline或者mget等操作,如果有,且程序日志中输出了大量的can't get jedis…

概述 这是关于 Swoole 入门学习的第十篇文章:压测 swoole_websocket_server 性能. 第九篇:Swoole Redis 连接池的实现 第八篇:Swoole MySQL 连接池的实现 第七篇:Swoole RPC 的实现 第六篇:Swoole 整合成一个小框架 第五篇:Swoole 多协议 多端口 的应用 第四篇:Swoole HTTP 的应用 第三篇:Swoole WebSocket 的应用 第二篇:Swoole Task 的应用 第一篇:Swoole Timer 的…

最近闲着没事做,就重新研究了一下基于python语言的Locust性能测试框架 发现在压测的过程中,虽然设置了100并发,但是通过实际监控,完全看不到100并发压测的效果 通过代码AOP日志监控接口的耗时情况如下:基本在0-2ms,采用读取redis缓存数据 但是通过Locust的统计的结果是平均耗时: 测试出来的结果完全和实际情况不一样…

1. 背景 最近QA对线上单模块进行压测(非全链路压测),http客户端 与 thrift服务端的tcp链接总在一段时间被close. 查看服务端日志显示 i/o timeout. 最后的结果是: qps太小, 长时间不发送请求, server主动关闭socket 2. 查看thrift框架原代码 thrift框架处理请求伪代码如下: //服务端listen for { // 服务端接收一个tcp连接请求 client := server.accept() // 独立启动一个goroutine处…

线程组里面有三个接口请求,依次为:显示商品列表.登录秒杀平台账户.进行秒杀 对线程组用5000个线程循环10次 设置一下默认配置,之后就不用反复填写了 设置配置文件这个具体功能就是读text文件并且设置变量的作用. 设置HTTP 请求我们这次直接对秒杀功能进行压测,填写的路径如图所示,这个要参见之前的代码.访问这个路径时需要两个变量,其中token是从之前的文本文件中读取的(也可以从登录接口正则获取到),注意Value的语法(如何写的). 结果展示 第一次运行的结果: TPS:630.9/sec…

对系统的某个接口进行极限压测,随着并发量上升,nginx开始出现502 no live upstreams while connecting to upstream的报错,维持最大并发量一段时间,发现调用接口一直返回502,即nginx已经发现不了存活的后端了. 通过跟踪端口,发现nginx 跟后端创建了大量的连接.这很明显是没有使用http1.1长连接导致的.因此在upstream中添加keepalive配置. upstream yyy.xxx.web{ server 36.10.xx.107…

本文是<Performance Test Together>(简称PTT)系列专题分享的第6期,该专题将从性能压测的设计.实现.执行.监控.问题定位和分析.应用场景等多个纬度对性能压测的全过程进行拆解,以帮助大家构建完整的性能压测的理论体系,并提供有例可依的实战. 该系列专题分享由阿里巴巴 PTS 团队出品,欢迎在文末处加入性能压测交流群,参与该系列的线上分享. 本文主要介绍如何正确的使用SLA来确定备容的目标,同时提高压测效率.主要分为理论和实践两个部分. SLA无处不在 在云计算时代,越来…

JMeter自身带有Master-Slave压测框架,对于并发量不是很高的压力情况下(比如tps低于5000),该方案是可行的,并且使用起来非常方便,只要在配置文件或者命令行工具的参数做一些补充,即可以实现分布式压测,具体请参见JMeter官网操作步骤或者UncleYong的文章 但JMeter的Master-Slave有诸多的缺陷: 1．Master机器的瓶颈,JMeter通过RMI的方式来实现Master-Slave的通信,所有的信息最终都会汇总到主机上,一旦slave机器数量增多,并且sl…

jmeter接口压测的反思 1.keepalive的坑:连接数满了,导致发起的请求失败. 2.token关联?是数据库取做参数化,还是随机数生成(需要改代码) 3.签名问题如何处理? 4.压测负载机端口连接数限制,改成最大65534. 5.加密问题如何处理? 6.redis如何监控,不能修改配置文件重启,不能远程连接?? 7.消息队列如何监控? 8.数据库如何监控? 9.…