- 综合排序
- 最热优先
- 最新优先
- 来自专栏用户4352451的专栏
压测引发的思考——高并发用同步还是异步好？
高并发用同步好还是异步好？ 背景 最近616大促，公司的服务需要进行压力测试，使用了公司自己的压测平台。对生产机器进行了摘流量压测。由于服务都是查询的接口，也算是很好压测的。 是否当有高并发的时候会有明显的性能bug问题，在促销前进行性能优化，不在物理层面优化 ，在软件（代码）层面优化的空间 如何进行压测 因为是公司内存的压测平台，相对还是比较自动化的 大概描述一下压测的流程 （随机抓取） 选择压力机器，选择目标机器 创建测试任务 摘目标压测机器的线上流量，不能影响线上的用户（很重要 ） 参数设定，根据以往机器是的性能表现，设置开始并发量，以及并发持续的时间，和增长速度。 高并发我们到底用同步还是异步呀。乱了，有点乱了。稳住，我们慢慢思考分析。同步一条路走下去，因为我们大都是内存操作，所以整个流程都很快。 高并发使用异步还是同步，这个真的需要具体问题具体对待了。高并发场景下起线程的异步千万不敢乱用。
1.1K10编辑于 2021-12-07 - 来自专栏站长的编程笔记
利用python对websocket进行并发压测
使用 WebSocketApp 的话，我没办法获取websocket服务器端返回的数据，这个我还在研究，这里使用 create_connection 来进行压测。 ): 19 t = threading.Thread(target=socket, args=()) 20 t.start() 利用python对websocket进行并发压测的相关教程结束
1.3K20编辑于 2022-12-01 - 来自专栏漫谈测试
大型系统高可用压测体系建设
压测体系是测试时发现问题的重要手段。压测除了能帮助发现功能异常外，还能发现一些平时不容易发现的问题，如当系统压力大时系统的表现情况、线上系统的容量配比是否合理、系统的容灾保护是否到位等。 压测一般分为单系统压测和全链路压测，我们所说的压测是线上真实生产环境的压力测试。一、单系统压测比较容易实现，有多种实现手段。 全链路压测的技术难度并不大，技术手段主要有流量的制造、流量的标记、测试数据的处理，全链路压测的架构如下图所示。流量的制造制造流量就是制造真实的用户请求。 选择合适的线上发压工具或平台时，应考虑以下因素：协议支持：确保所选工具支持你要测试的应用程序使用的协议。并发能力：根据预期的用户量选择能产生足够并发请求的工具。 根据你的具体需求和技术栈，可以选择最适合的工具来进行线上发压测试。四、压测体系实施的步骤有哪些？实施一个高可用压测体系通常可以按照以下步骤进行，这些步骤旨在确保测试的有效性、准确性和可重复性：1.
47510编辑于 2024-12-18 - 来自专栏大数据生态
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压测和并发预估
keeplive # 3.可以将测试结果导入文件 # 4.设置显示信息的详细程度 综合来说，适合单个URL的测试，可以支持更多方式去测试，比如使用cookie模仿用户提交表单来测试数据库，但ab是单线程的，不适合测性能高的服务器 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 - 来自专栏WeTest质量开放平台团队的专栏
看腾讯专家如何在高并发压测中支持https
WeTest 导读 用epoll编写一个高并发网络程序是很常见的任务，但在epoll中加入ssl层的支持则是一个不常见的场景。 腾讯WeTest服务器压力测产品，在用户反馈中收到了不少支持https协议的请求。基于此，本文介绍了在基于epoll的高并发机器人框架中加入openssl，实现对https支持时的基本实现思路。 而在上线之后，收到了不少需要https测试的用户反馈，由此决定在我们使用的压测框架中加入https支持。 腾讯WeTest服务器性能测试是一个基于epoll的高并发机器人网络行为模拟框架。 要点1：OpenSSL并发读写，是不安全的 其实OpenSSL官方的文档上还没找到直接的话术指明同一个SSL不能两个线程并发读写，但实际上，外网上、km上都有文章说在多线程并发情况下读写会引起程序崩溃。 点击左侧“HTTP直压“进入压测 ? 输入合适的测试标题和测试设置 （此图为动图，横屏观看效果更佳） 2）新建一个客户端请求，接口压测包括读写接口，读接口基本是GET请求，写接口基本是POST请求。
1.5K30发布于 2018-10-29 - 来自专栏devops_k8s
Redis压测
性能测试工具可选参数如下所示： 序号 选项 描述 默认值 1 -h 指定服务器主机名 127.0.0.1 2 -p 指定服务器端口 6379 3 -s 指定服务器 socket 4 -c 指定并发连接数 案例一 性能信息分析 机器配置 1.png 2.png 3.png # 测试100个并发连接 # 一个并发连接有100000个请求 [root@node-a ~]# redis-benchmark 为了达到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的网卡， 或者多个 1 Gbits/s 网卡。 在高配置下面，客户端的连接数也是一个重要的因素。得益于 epoll/kqueue， Redis 的事件循环具有相当可扩展性。 在高配置下面，可以通过调优 NIC 来获得更高性能。最高性能在绑定 Rx/Tx 队列和 CPU 内核下面才能达到，还需要开启 RPS（网卡中断负载均衡）。更多信息可以在thread 。
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.小结 业务模型分析 对业务模型进行分析，选择日常请求量大且路径覆盖范围广的典型交易，建立测试业务模型，确定各接口请求量的对比 3.负载测试 负载测试用于测试单个接口在不产生任何错误的情况下能够提供的最佳的系统性能，从而得出单个接口在相应时间满足用户需求时的最大吞吐量和并发数。 加压方式 1.瞬间加压：通过测试工具模拟大量并发请求 2.逐渐加压：一定周期内为抛物线的趋势 3.梯度加压：逐渐增加用户并发量 4.确定延时方式 压测执行 观察系统的资源占用情况 /系统层面：CPU， 打开的文件句柄，线程切换，和打开的Socket数量 /接口的吞吐量，响应时间，超时情况等 /数据库的慢 SQL，SQL行读，锁等待，死锁，缓冲区命中，索引命中等 /消息队列的吞吐变化，响应时间，超时情况 /压测过程中记录压测记录 /分析是否满足既定压测目标 /指出系统存在的瓶颈点 压测工具：ab,jmeter,mysqlslap.sysbench,dd,LoadRunner，Hprof 我记得我整理了ab,jmeter的文章，
5.4K21发布于 2020-02-19 - 来自专栏IT大咖说
干货 | OneAPM研发总监高海强：百万并发云压测平台的关键技术
OneAPM研发总监高海强，对于我们的业务系统能否经受的住高并发用户访问，有什么测试手段和方法可以做到提前验证，与大家分享了实现压测平台的关键技术与细节。
76580发布于 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的逻辑，也就是说：流量是下面这个样子 --流量--》 , 10 KiB) copied, 9.7164e-05 s, 105 MB/s 参考： https://www.cnblogs.com/machangwei-8/p/10353628.html 2.压测工具使用的是 hey，压测命令的例子如下： # .
92610编辑于 2024-04-17 - 来自专栏devops_k8s
Redis压测
redis 性能测试工具可选参数如下所示： 序号 选项 描述 默认值 1 -h 指定服务器主机名 127.0.0.1 2 -p 指定服务器端口 6379 3 -s 指定服务器 socket 4 -c 指定并发连接数 案例一 性能信息分析 机器配置 image.png image.png image.png # 测试100个并发连接 # 一个并发连接有100000个请求 [root@node-a ~] 为了达到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的网卡， 或者多个 1 Gbits/s 网卡。 在高配置下面，客户端的连接数也是一个重要的因素。得益于 epoll/kqueue， Redis 的事件循环具有相当可扩展性。 在高配置下面，可以通过调优 NIC 来获得更高性能。最高性能在绑定 Rx/Tx 队列和 CPU 内核下面才能达到，还需要开启 RPS（网卡中断负载均衡）。更多信息可以在thread 。
2.3K70发布于 2021-06-21 - 来自专栏JAVA乐园
怎么做服务压测？压测关注什么？
背景 在业务新上线，或者业务做活动，压测成为必不可少的一步。 但是很多开发对如何做好服务压测并没有特别系统的了解，这篇文章的目的是为了解释清楚单机服务压测的目的、做法、误区，帮助大家更好地达成压测的目的 压测的目的是什么？ 我们并不总是对自己的服务这么自信，压测能够帮我们了解清楚在高压情况下的表现，发现隐藏的问题。 后续的内容我们将按照三个目标逐一讲述，压测中可能存在的误区 性能瓶颈分析 在分析服务性能瓶颈的时候，一般使用perf工具来生成服务在压测时的火焰图 y 轴表示调用栈，每一层都是一个函数。 流量预估：通过历史数据（或者结合业务和时间）预估业务流量会有多大的系统调用量 容量评估：根据预估结果，计算服务需要分配多少机器 场景压测：针对重点业务场景，进行全局性的压测，根据压测结果再次调整。
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（并发请求数 Options: -c, --connections <N> Connections to keep open（并发数 以上两个特性 wrk 可以支持，而 Jmeter 需安装 GUI，没有 CLI 方便没有详细去了解，选择用 wrk 进行压测。 c1 -d1s -s post.lua --latency http://127.0.0.1:8080/index.php 使用 lua 脚本，实现 POST 请求动态参数组装 post.lua --压测命令
1K20编辑于 2023-10-22 - 来自专栏云原生实验室
使用 wrk 压测并精细控制并发请求量
附录 – 我对于 Ingress 的压测过程 近期压测 Ingress 主要是因为有个大应用会接入到我们的系统中, 可能比原有所有应用的流量加起来都要多, 不压测的话, 用户使用的信心没有那么足. 这个程序在达到 13~14k 之后已经到了瓶颈, 这个时候, 我只能保留这个程序的请求量, 加入另一个程序用于压测. 另一个程序, 我没有再指定 wait 的等待时间, 希望这个程序可以尽可能快的返回, 让我得到尽可能高的并发. 并发请求时, 新应用的 qps 在 25k 左右 ? 此次压测结论 14kqps(第一个应用) + 25k(第二个应用) 单机的 Ingress 的大概能允许 40K 左右的并发, 达到这个阶段后, 主要瓶颈是在 CPU. 如果 CPU 再好一点的话, 我觉得并发量可以更高. 如果觉得我压测方法不科学或者有其他想讲的, 可以在评论里面说, 我看看是不是过程有问题.
5K40发布于 2021-05-10 - 来自专栏全栈程序员必看
压测工具jmeter怎么使用_并发压力测试工具
7.安装结束~ 三、Jmeter测试案例实操 1、添加本次测试计划 （右键–>添加–>Threads（Users）–>线程组） 2、设置线程数 （所谓线程数就是并发用户数） 3、添加协议及相关配置信息
1.6K30编辑于 2022-09-20 - 来自专栏院长运维开发
ab压测工具
的相应百分比的(以微妙为单位)时间 -h 显示使用方法 -k 发送keep-alive指令到服务器端 命令： ab -n 1000 -c 200 "请求路径" -n 请求次数 -c 并发数
2.1K20发布于 2021-02-19 - 来自专栏johnnyxsu技术交流分享
网站压测工具
在日常售后工作中，常常需要对一些网站进行简单的压测，以判断网站的可用性。 此时通过压测源站就能够发现源站性能异常。 本文提供两种简单的网站压测脚本，能够快速的针对源站进行HTTP或HTTPS请求的压测。 HTTPStressTesting.git 下载后会有两个脚本文件： simple_stresstesting.sh 该脚本为一个简单的脚本测试工具，效率相对来说比较高 stresstesting.sh 该脚本为较为复杂的网站压测工具 simple_stresstesting.sh运行指南 image.png 运行该脚本后面跟多个变量，第一个变量需要输入压测请求的次数，后面的变量需要填写网站的url以及proxy等代理请求。 image.png 压测结束后会展示返回的状态码等统计信息。
7K970发布于 2019-07-08 - 来自专栏windealli
常用压测工具
后台开发经常需要对服务进行压力测试，下面介绍常用的压测工具。 webbench webbench 是常用的网站压力测试工具，webbench用C语言编写，代码仅有区区几百行。 最后两行是压测结构， 有测试的请求速度，成功的请求量、失败的请求量。 实现原理 通过调用fork()创建子进程，模拟多个客户端。
4.4K50发布于 2018-09-27
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号