- 综合排序
- 最热优先
- 最新优先
- 来自专栏用户4352451的专栏
压测引发的思考——高并发用同步还是异步好？
高并发用同步好还是异步好？ 背景 最近616大促，公司的服务需要进行压力测试，使用了公司自己的压测平台。对生产机器进行了摘流量压测。由于服务都是查询的接口，也算是很好压测的。 是否当有高并发的时候会有明显的性能bug问题，在促销前进行性能优化，不在物理层面优化 ，在软件（代码）层面优化的空间 如何进行压测 因为是公司内存的压测平台，相对还是比较自动化的 大概描述一下压测的流程 （随机抓取） 选择压力机器，选择目标机器 创建测试任务 摘目标压测机器的线上流量，不能影响线上的用户（很重要 ） 参数设定，根据以往机器是的性能表现，设置开始并发量，以及并发持续的时间，和增长速度。 高并发我们到底用同步还是异步呀。乱了，有点乱了。稳住，我们慢慢思考分析。同步一条路走下去，因为我们大都是内存操作，所以整个流程都很快。 高并发使用异步还是同步，这个真的需要具体问题具体对待了。高并发场景下起线程的异步千万不敢乱用。
1.1K10编辑于 2021-12-07 - 来自专栏站长的编程笔记
利用python对websocket进行并发压测
使用 WebSocketApp 的话，我没办法获取websocket服务器端返回的数据，这个我还在研究，这里使用 create_connection 来进行压测。 while True) 完整代码： 1 import threading 2 from websocket import create_connection 3 import time 4 5 ): 19 t = threading.Thread(target=socket, args=()) 20 t.start() 利用python对websocket进行并发压测的相关教程结束
1.3K20编辑于 2022-12-01 - 来自专栏漫谈测试
大型系统高可用压测体系建设
压测体系是测试时发现问题的重要手段。压测除了能帮助发现功能异常外，还能发现一些平时不容易发现的问题，如当系统压力大时系统的表现情况、线上系统的容量配比是否合理、系统的容灾保护是否到位等。 压测一般分为单系统压测和全链路压测，我们所说的压测是线上真实生产环境的压力测试。一、单系统压测比较容易实现，有多种实现手段。 选择合适的线上发压工具或平台时，应考虑以下因素：协议支持：确保所选工具支持你要测试的应用程序使用的协议。并发能力：根据预期的用户量选择能产生足够并发请求的工具。 根据你的具体需求和技术栈，可以选择最适合的工具来进行线上发压测试。四、压测体系实施的步骤有哪些？实施一个高可用压测体系通常可以按照以下步骤进行，这些步骤旨在确保测试的有效性、准确性和可重复性：1. 5. 初步测试与调优小规模试运行：先在一个较小规模上运行测试，检查测试设置是否正确，同时调整任何发现的问题。优化测试脚本：基于初步测试的结果，对测试脚本进行必要的优化，以提高效率和准确性。6.
51010编辑于 2024-12-18 - 来自专栏老张的求知思考世界
全链路压测(5)：生产全链路压测实施全流程
前言 前面的几篇文章从生产全链路压测的定义，内部立项和技术调研，聊到了测试验证以及全链路压测的对企业业务和技术团队的价值，算是整体上的构建一个认知的概念。 从这篇文章开始，会进入具体的落地实践环节。 这篇文章中，我会介绍生产全链路压测的落地实施全流程，即每个环节要做什么事情。 四大阶段 如果将生产全链路压测作为一个阶段性的技术项目来看，全链路压测从开始到项目结束，需要经过四个阶段。 筹备阶段 确定业务范围 一般来说线上实施线上全链路压测之前，要明确本次压测需要验证的业务范围。 大型业务活动有关的项目，如电商双11大促； 影响业务目标达成的项目，如电商每年的各种购物节； 风险相对可控的核心项目，一般核心业务稳定性要求更高； 注意事项 按照5W+1H原则进行梳理，交付的checklist ，对线上需要扩容的机器、所需的数据进行提前预热，可通过小流量试跑来验证线上预热准备是否充足； 实施线上压测 线上压测的过程，实际上和日常压测没太多区别，下面这张图足以说明一切： 预案演练验证 预案演练环节
2K40编辑于 2022-04-01 - 来自专栏大数据生态
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的高并发机器人网络行为模拟框架。 5 HTTPS测试功能的使用 下面，我们来看一下如何在简单模式中进行https页面的服务器性能测试。 点击左侧“HTTP直压“进入压测 ? 输入合适的测试标题和测试设置 （此图为动图，横屏观看效果更佳） 2）新建一个客户端请求，接口压测包括读写接口，读接口基本是GET请求，写接口基本是POST请求。
1.5K30发布于 2018-10-29 - 来自专栏devops_k8s
Redis压测
50 5 -n 指定请求数 10000 6 -d 以字节的形式指定 SET/GET 值的数据大小 2 7 -k 1=keep alive 0=reconnect 1 8 -r SET/ 案例一 性能信息分析 机器配置 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 进行压测。 1 安装 MongoDB MongoDB的安装，可参考：5.x 副本集部署。 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.小结 业务模型分析 对业务模型进行分析，选择日常请求量大且路径覆盖范围广的典型交易，建立测试业务模型，确定各接口请求量的对比 //负载测试在几十分钟内完成 4.混合业务测试 混合业务测试是按照业务流程要求对接口调用按照比例进行编排，并采用一定的测试加压方式进行加压，获取系统对业务流程的最大处理能力//几十分钟内完成 5.稳定性测试 加压方式 1.瞬间加压：通过测试工具模拟大量并发请求 2.逐渐加压：一定周期内为抛物线的趋势 3.梯度加压：逐渐增加用户并发量 4.确定延时方式 压测执行 观察系统的资源占用情况 /系统层面：CPU， 打开的文件句柄，线程切换，和打开的Socket数量 /接口的吞吐量，响应时间，超时情况等 /数据库的慢 SQL，SQL行读，锁等待，死锁，缓冲区命中，索引命中等 /消息队列的吞吐变化，响应时间，超时情况 /压测过程中记录压测记录 /分析是否满足既定压测目标 /指出系统存在的瓶颈点 压测工具：ab,jmeter,mysqlslap.sysbench,dd,LoadRunner，Hprof 我记得我整理了ab,jmeter的文章，
5.4K21发布于 2020-02-19 - 来自专栏IT大咖说
干货 | OneAPM研发总监高海强：百万并发云压测平台的关键技术
Guest Video 温馨提示 本视频时长55分46秒，建议在wifi下观看 5月13日，七牛云携手 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的逻辑，也就是说：流量是下面这个样子 --流量--》 , 10 KiB) copied, 9.7164e-05 s, 105 MB/s 参考： https://www.cnblogs.com/machangwei-8/p/10353628.html 2.压测工具使用的是 hey，压测命令的例子如下： # .
98210编辑于 2024-04-17 - 来自专栏devops_k8s
Redis压测
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 8 -r SET/GET/INCR 案例一 性能信息分析 机器配置 image.png image.png image.png # 测试100个并发连接 # 一个并发连接有100000个请求 [root@node-a ~] 为了达到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的网卡， 或者多个 1 Gbits/s 网卡。 在高配置下面，客户端的连接数也是一个重要的因素。得益于 epoll/kqueue， Redis 的事件循环具有相当可扩展性。
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 --压测命令
1.1K20编辑于 2023-10-22 - 来自专栏云原生实验室
使用 wrk 压测并精细控制并发请求量
附录 – 我对于 Ingress 的压测过程 近期压测 Ingress 主要是因为有个大应用会接入到我们的系统中, 可能比原有所有应用的流量加起来都要多, 不压测的话, 用户使用的信心没有那么足. 这个程序在达到 13~14k 之后已经到了瓶颈, 这个时候, 我只能保留这个程序的请求量, 加入另一个程序用于压测. 另一个程序, 我没有再指定 wait 的等待时间, 希望这个程序可以尽可能快的返回, 让我得到尽可能高的并发. 并发请求时, 新应用的 qps 在 25k 左右 ? 此次压测结论 14kqps(第一个应用) + 25k(第二个应用) 单机的 Ingress 的大概能允许 40K 左右的并发, 达到这个阶段后, 主要瓶颈是在 CPU. 如果 CPU 再好一点的话, 我觉得并发量可以更高. 如果觉得我压测方法不科学或者有其他想讲的, 可以在评论里面说, 我看看是不是过程有问题.
5K40发布于 2021-05-10 - 来自专栏全栈程序员必看
压测工具jmeter怎么使用_并发压力测试工具
2.还有一个界面是jmeter工作页面，你可以在里面进行相关的操作.具体如图 5）确认安装是否成功，双击jmeter.bat或者以管理员方式运行，页面如下： 6）jmeter的工作区域如下：，我们每次使用 7.安装结束~ 三、Jmeter测试案例实操 1、添加本次测试计划 （右键–>添加–>Threads（Users）–>线程组） 2、设置线程数 （所谓线程数就是并发用户数） 3、添加协议及相关配置信息 4、为线程添加监听器 5、启动测试 6、查看报告 查看结果树 聚合报告 图形结果 至此，本次测试教程基本完成！！
1.6K30编辑于 2022-09-20 - 来自专栏从零开始学自动化测试
jmeter压测学习5-XPath提取器
有些web项目是前后端不分离的，返回的内容不是那种纯进口返回json格式，返回的是一个HTML页面。 并且有些参数是隐藏在html里面的，需要先从html页面中取出隐藏参数，如：csrfmiddlewaretoken
1.2K10发布于 2019-12-05 - 来自专栏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号