- 综合排序
- 最热优先
- 最新优先
- 来自专栏用户4352451的专栏
压测引发的思考——高并发用同步还是异步好？
高并发用同步好还是异步好？ 背景 最近616大促，公司的服务需要进行压力测试，使用了公司自己的压测平台。对生产机器进行了摘流量压测。由于服务都是查询的接口，也算是很好压测的。 是否当有高并发的时候会有明显的性能bug问题，在促销前进行性能优化，不在物理层面优化 ，在软件（代码）层面优化的空间 如何进行压测 因为是公司内存的压测平台，相对还是比较自动化的 大概描述一下压测的流程 （随机抓取） 选择压力机器，选择目标机器 创建测试任务 摘目标压测机器的线上流量，不能影响线上的用户（很重要 ） 参数设定，根据以往机器是的性能表现，设置开始并发量，以及并发持续的时间，和增长速度。 高并发我们到底用同步还是异步呀。乱了，有点乱了。稳住，我们慢慢思考分析。同步一条路走下去，因为我们大都是内存操作，所以整个流程都很快。 高并发使用异步还是同步，这个真的需要具体问题具体对待了。高并发场景下起线程的异步千万不敢乱用。
1.1K10编辑于 2021-12-07 - 来自专栏站长的编程笔记
利用python对websocket进行并发压测
使用 WebSocketApp 的话，我没办法获取websocket服务器端返回的数据，这个我还在研究，这里使用 create_connection 来进行压测。 # True为连接成功，False为连接失败 发送消息至服务器并接收返回结果： 1 initialize_data = '{"code":2001, "msg": "","data": ""}' 2 为短连接，所以这一系列下来后连接会断开，所以这个时候需要一个东西来维持连接，长连接叫心跳，那短连接这里我愿成为：心脏起搏器(while True) 完整代码： 1 import threading 2 6 def socket(): 7 while True: 8 ws = create_connection("websocket服务器地址") 9 # 2、 ): 19 t = threading.Thread(target=socket, args=()) 20 t.start() 利用python对websocket进行并发压测的相关教程结束
1.3K20编辑于 2022-12-01 - 来自专栏漫谈测试
大型系统高可用压测体系建设
压测体系是测试时发现问题的重要手段。压测除了能帮助发现功能异常外，还能发现一些平时不容易发现的问题，如当系统压力大时系统的表现情况、线上系统的容量配比是否合理、系统的容灾保护是否到位等。 压测一般分为单系统压测和全链路压测，我们所说的压测是线上真实生产环境的压力测试。一、单系统压测比较容易实现，有多种实现手段。 选择合适的线上发压工具或平台时，应考虑以下因素：协议支持：确保所选工具支持你要测试的应用程序使用的协议。并发能力：根据预期的用户量选择能产生足够并发请求的工具。 根据你的具体需求和技术栈，可以选择最适合的工具来进行线上发压测试。四、压测体系实施的步骤有哪些？实施一个高可用压测体系通常可以按照以下步骤进行，这些步骤旨在确保测试的有效性、准确性和可重复性：1. 这可能包括评估系统的最大负载能力、响应时间、并发用户处理能力等。定义成功标准：设定性能指标（如平均响应时间、每秒事务数）和故障容忍度作为成功的衡量标准。2.
50910编辑于 2024-12-18 - 来自专栏ElasticSearch
压测工具 wrk2
10.188.139.234:9200/tms_dispatch_pick_2023q3_new/_search" --script=query02.lua-t 线程-c 连接数-d 启动多长时间-R 启动多少qps压测 --latency 延时压测分布情况--http --script 指定脚本more query.luawrk.method="POST"wrk.body='{"from":0,"size":10,
29710编辑于 2024-09-06 - 来自专栏大数据生态
Elasticsearch压测之Esrally压测标准
压测工具部署：Elasticsearch压测工具esrally部署指南 - 云+社区 本文另有延伸：大数据生态关于压力测试的内容 - 云+社区 背景 在大数据时代的今天，业务量越来越大，每天动辄都会产生上百 track: 即赛道的意思，这里指压测用到的样本数据和压测策略，使用 esrally list tracks 列出。 ，可以通过 esrally list pipeline 查看，其中有一个 benchmark-only 的流程，就是将 es 的管理交给用户来操作，rally 只用来做压测，如果你想针对已有的 es 进行压测 ，则使用该模式； track-params：对默认的压测参数进行覆盖； user-tag：本次压测的 tag 标记； client-options：指定一些客户端连接选项，比如用户名和密码。 压测标准 在压测的过程中，需要了解到各个指标的含义。但是网络上没有完整的文档，所以这里做一个详细的总结。
4.5K2214编辑于 2022-05-16 - 来自专栏建帅技术分享
utest压测和grafana压测效果（腾讯优测）
一、压力测试平台-----优测 优测官网 二、10000vum免费试用 1.单接口压测 创建单接口任务： 执行任务及查看报告： 导出报告： pdf格式报告： 2.全链路压测 创建全链路计划 ： 执行全链路计划：每次会消耗vum 执行进度： 压测报告： 定时任务： 全链路pdf压测报告： 三、资源监控：grafana **免费的测试报告中，缺少了cpu和内存等资源的占用情况。 所以我这里想到的是grafana，利用grafana动态实时的资源可视化，结合优测，应该效果非常棒.** 四、总结 问题： 本来想结合业务登录接口去坐个压测，结果发现，优测不支持application
2.5K20编辑于 2022-08-24 - 来自专栏devops_k8s
使用AB对Nginx压测和并发预估
综合来说，适合单个URL的测试，可以支持更多方式去测试，比如使用cookie模仿用户提交表单来测试数据库，但ab是单线程的，不适合测性能高的服务器; 安装ab 需要安装httpd-tools yum Nginx压测和并发预估 预估算法: { (?G) * 1024 - system} / 请求大小 #（? ,最多可以抗住5-6万 简单使用下ab压测工具 ab -n2000 -c2 http://127.0.0.1/index.html # -n 总的请求次数 # -c 并发请求数 # -k 是否开启长连接 ,下面仅供参考 ab压测信息 [root@node-a ~]# ab -c 20000 -n 100000 http://1.1.1.1/index.html This is ApacheBench, 的 Response Headers 下可以看到 Connection:keep-alive，如果设置为 0，那么为 Connection:close keepalive_timeout 0; 再次压测
2.6K51发布于 2020-09-27 - 来自专栏技术交流专栏
Windows磁盘性能压测（2）-Fio
测试工具相关 2. 4.1测试硬盘的随机读IOPS 4.2测试硬盘的随机写IOPS 4.3测试硬盘的随机混合读写IOPS 说明： 有关Windows磁盘性能压测 ，笔者还是强烈推荐使用微软自己开源的压测工具DiskSpd。 当然，如果要使用其他磁盘性能压测工具也是可以的，比如：IOMeter（老牌经典）、FIO（更适合Linux）等。 group_reporting 多个 job 并发时，打印整个 group 的统计值。 name job 的名称。 size I/O 测试的寻址空间。
12.6K61发布于 2021-06-17 - 来自专栏WeTest质量开放平台团队的专栏
看腾讯专家如何在高并发压测中支持https
WeTest 导读 用epoll编写一个高并发网络程序是很常见的任务，但在epoll中加入ssl层的支持则是一个不常见的场景。 腾讯WeTest服务器压力测产品，在用户反馈中收到了不少支持https协议的请求。基于此，本文介绍了在基于epoll的高并发机器人框架中加入openssl，实现对https支持时的基本实现思路。 而在上线之后，收到了不少需要https测试的用户反馈，由此决定在我们使用的压测框架中加入https支持。 腾讯WeTest服务器性能测试是一个基于epoll的高并发机器人网络行为模拟框架。 要点2：OpenSSL的建链、收包、发包接口，其是否阻塞都随socket本身属性而变，所以OpenSSL可以非阻塞使用 在我们的场景下，用epoll来维护机器人的并发建连接和收发包，当然希望任何一个动作都是非阻塞的 点击左侧“HTTP直压“进入压测 ? 输入合适的测试标题和测试设置 （此图为动图，横屏观看效果更佳） 2）新建一个客户端请求，接口压测包括读写接口，读接口基本是GET请求，写接口基本是POST请求。
1.5K30发布于 2018-10-29 - 来自专栏devops_k8s
Redis压测
-p 指定服务器端口 6379 3 -s 指定服务器 socket 4 -c 指定并发连接数 50 5 -n 指定请求数 10000 6 -d 以字节的形式指定 SET/GET 值的数据大小 案例一 性能信息分析 机器配置 1.png 2.png 3.png # 测试100个并发连接 # 一个并发连接有100000个请求 [root@node-a ~]# redis-benchmark 为了达到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的网卡， 或者多个 1 Gbits/s 网卡。 在高配置下面，客户端的连接数也是一个重要的因素。得益于 epoll/kqueue， Redis 的事件循环具有相当可扩展性。 避免将 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依赖网络的存储设备上面（比如 Amazon EC2 上 的 EBS）。
2K20编辑于 2022-05-09 - 来自专栏悦专栏
MongoDB 压测
在 MongoDB 上线之前，我们可能想知道它的极限是怎样的，这时，我们可以借助工具对 MongoDB 进行压测，这一节内容就来聊聊通过 YCSB 对 MongoDB 进行压测。 readproportion=1 updateproportion=0 scanproportion=0 insertproportion=0 requestdistribution=zipfian 关于 YCSB 的压测文件的每个参数的解释如下 5 运行压测 加载压测数据： ./bin/ycsb load mongodb -P workloads/workloada 进行压测： . 99thPercentileLatency(us), 1317.0 [UPDATE], Return=OK, 24798 通过 “[OVERALL], Throughput(ops/sec)”，可看出我们压测的实例 当然，压测过程也需要关注 CPU、内存等，看是否已经到极限了。
2.3K10编辑于 2022-04-25 - 来自专栏Java项目实战
压测场景设计和压测方案制定
本章内容根据《分布式服务架构》整理 1.业务模型分析 2.压测执行 3.压测工具 4.小结 业务模型分析 对业务模型进行分析，选择日常请求量大且路径覆盖范围广的典型交易，建立测试业务模型，确定各接口请求量的对比 2.容量测试 容量测试指检查系统能处理最大业务量，在测试过程中采用梯度加压的方式不断增加并发用户量，监控响应时间和系统资源的变化情况，响应时间曲线的拐点是业务量就是系统最大业务量//测试人员测试，时间较久 加压方式 1.瞬间加压：通过测试工具模拟大量并发请求 2.逐渐加压：一定周期内为抛物线的趋势 3.梯度加压：逐渐增加用户并发量 4.确定延时方式 压测执行 观察系统的资源占用情况 /系统层面：CPU， 打开的文件句柄，线程切换，和打开的Socket数量 /接口的吞吐量，响应时间，超时情况等 /数据库的慢 SQL，SQL行读，锁等待，死锁，缓冲区命中，索引命中等 /消息队列的吞吐变化，响应时间，超时情况 /压测过程中记录压测记录 /分析是否满足既定压测目标 /指出系统存在的瓶颈点 压测工具：ab,jmeter,mysqlslap.sysbench,dd,LoadRunner，Hprof 我记得我整理了ab,jmeter的文章，
5.4K21发布于 2020-02-19 - 来自专栏高可用
初探单机压测工具wrk2
背景说明 在之前的文章CLB是怎么均衡client流量的-长连接篇中，实验使用的是pts这款压测工具，实际压测前，有调研wrk2这个优秀的单机压测工具，但场景方面不是很匹配，就没有采用。 2. 什么是wrk2 wrk2是一个主要基于wrk的HTTP基准测试工具，与 apache bench（以下简称 ab）类似，都是单机上的压测工具，其使用多线程设计来进行请求的生成。 除此之外，还有两个特点，也是我选择它的原因 高并发能力：wrk2使用多线程设计，能够并发地生成HTTP请求，从而模拟大量的客户端请求。这允许它更快地发送请求并模拟高负载情况。 , 2m, 2h) 压测中常用的几个参数如下： -c 并发连接数 -d 压测时长 -R 模拟的qps -t 启用的线程数，根据设备CPU数量来 wrk2使用 我们用wrk来尝试完成上篇文章的任务，使用命令如下 wrk -t2 -c100 -d30s -R25000 http://10.0.100.38/ 输出结果如下，整体说明比较直观 图片 结论 从试用下来，发下wrk在单机压测时比较好使，但涉及到高并发模拟
2.1K20编辑于 2023-10-15 - 来自专栏IT大咖说
干货 | OneAPM研发总监高海强：百万并发云压测平台的关键技术
OneAPM研发总监高海强，对于我们的业务系统能否经受的住高并发用户访问，有什么测试手段和方法可以做到提前验证，与大家分享了实现压测平台的关键技术与细节。
76880发布于 2018-04-03 - 来自专栏灰子学技术
envoy压测
压测信息： envoy版本: 1.23.2-dev istio版本:1.15.2 envoy只打开了access log，没有配置任何VS和DR，去掉了jeager和stat-filter插件， pod层面做的压测，资源为 1c2g的sidecar配比，业务容器是1c2g，响应比较快，request的大小是多少，response就返回多少。 网络是k8s的内网，延迟很低，不超过1ms。 压测准备： 构建 test1---->test2的链路，在test1的pod里面进行压测，访问的接口是test1的，这里的接口内部实现了调用test2的逻辑，也就是说：流量是下面这个样子 --流量--》 压测工具使用的是hey，压测命令的例子如下： # . Status code distribution: [200] 20000 responses 参考： https://www.cnblogs.com/wintersun/p/12492096.html 压测结果
98110编辑于 2024-04-17 - 来自专栏devops_k8s
Redis压测
-p 指定服务器端口 6379 3 -s 指定服务器 socket 4 -c 指定并发连接数 50 5 -n 指定请求数 10000 6 -d 以字节的形式指定 SET/GET 值的数据大小 2 7 案例一 性能信息分析 机器配置 image.png image.png image.png # 测试100个并发连接 # 一个并发连接有100000个请求 [root@node-a ~] 为了达到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的网卡， 或者多个 1 Gbits/s 网卡。 在高配置下面，客户端的连接数也是一个重要的因素。得益于 epoll/kqueue， Redis 的事件循环具有相当可扩展性。 避免将 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依赖网络的存储设备上面（比如 Amazon EC2 上 的 EBS）。
2.3K70发布于 2021-06-21 - 来自专栏JAVA乐园
怎么做服务压测？压测关注什么？
背景 在业务新上线，或者业务做活动，压测成为必不可少的一步。 但是很多开发对如何做好服务压测并没有特别系统的了解，这篇文章的目的是为了解释清楚单机服务压测的目的、做法、误区，帮助大家更好地达成压测的目的 压测的目的是什么？ 我们并不总是对自己的服务这么自信，压测能够帮我们了解清楚在高压情况下的表现，发现隐藏的问题。 单机处理能力（QPS） 硬件影响了服务性，但处理能力跟硬件的关系有的时候并不是线性的，CPU从2核增加到4核，服务的能力并不一定会提高两倍。 容量规划的需要：什么系统，什么时候，需要多少服务器。 流量预估：通过历史数据（或者结合业务和时间）预估业务流量会有多大的系统调用量 容量评估：根据预估结果，计算服务需要分配多少机器 场景压测：针对重点业务场景，进行全局性的压测，根据压测结果再次调整。
2.1K30编辑于 2022-03-08 - 来自专栏LukaChen Blog
wrk 压测
一、背景 通过压测发现系统瓶颈，评估系统 QPS、吞吐量上限 二、工具选择 ab、wrk、Jmeter ab [root@VM-190-129-centos ~]# ab --help Usage: ab Number of requests to perform（总请求数） -c concurrency Number of multiple requests to make at a time（并发请求数 , 2m, 2h) 通过解读 ab 和 wrk 关键参数可知： 1.ab 不支持从文件或使用编码，动态修改 POST 或 url 信息； 2.通过 google 了解到 ab 不支持多线程。 以上两个特性 wrk 可以支持，而 Jmeter 需安装 GUI，没有 CLI 方便没有详细去了解，选择用 wrk 进行压测。 c1 -d1s -s post.lua --latency http://127.0.0.1:8080/index.php 使用 lua 脚本，实现 POST 请求动态参数组装 post.lua --压测命令
1.1K20编辑于 2023-10-22 - 来自专栏云原生实验室
使用 wrk 压测并精细控制并发请求量
附录 – 我对于 Ingress 的压测过程 近期压测 Ingress 主要是因为有个大应用会接入到我们的系统中, 可能比原有所有应用的流量加起来都要多, 不压测的话, 用户使用的信心没有那么足. 压测脚本就是用的上面 0.1s 的数据, 机器的配置如下: 内核版本：4.9.0-15-amd64 操作系统：Debian 9.13 内存大小：131072 M CPU 核数：24 CPU 个数：2 CPU 另一个程序, 我没有再指定 wait 的等待时间, 希望这个程序可以尽可能快的返回, 让我得到尽可能高的并发. 并发请求时, 新应用的 qps 在 25k 左右 ? 此次压测结论 14kqps(第一个应用) + 25k(第二个应用) 单机的 Ingress 的大概能允许 40K 左右的并发, 达到这个阶段后, 主要瓶颈是在 CPU. 如果 CPU 再好一点的话, 我觉得并发量可以更高. 如果觉得我压测方法不科学或者有其他想讲的, 可以在评论里面说, 我看看是不是过程有问题.
5K40发布于 2021-05-10 - 来自专栏全栈程序员必看
压测工具jmeter怎么使用_并发压力测试工具
一、Jmeter下载 进入官网：http://jmeter.apache.org/ 1.第一步进入官网如下图 2.选择进行下载，下载下来为一个压缩包，解压即可。 2）对应的jdk版本不可太低，一般jmeter3.0的对应jdk1.7，jmeter4.0对应jdk1.8以上，否者启用jmeter也会报错。 电脑桌面—-》“计算机”图标—-》鼠标右键选择“属性”—-》点击高级系统设置—-》高级—》环境变量页面 2） 开始配置环境变量了。 首先进到你的jmeter安装路径，找到bin文件夹，点击进去，找到jmeter.bat，鼠标右键用管理员方式运行，或者直接双击打开，此时会弹出2个界面：1.个是命令窗口，使用jmeter的时候此命令窗口不能关 7.安装结束~ 三、Jmeter测试案例实操 1、添加本次测试计划 （右键–>添加–>Threads（Users）–>线程组） 2、设置线程数 （所谓线程数就是并发用户数） 3、添加协议及相关配置信息
1.6K30编辑于 2022-09-20
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号