首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏用户4352451的专栏

    引发的思考——并发用同步还是异步好?

    并发用同步好还是异步好? 背景 最近616大促,公司的服务需要进行压力测试,使用了公司自己的平台。对生产机器进行了摘流量。由于服务都是查询的接口,也算是很好的。 是否当有并发的时候会有明显的性能bug问题,在促销前进行性能优化,不在物理层面优化 ,在软件(代码)层面优化的空间 如何进行 因为是公司内存的平台,相对还是比较自动化的 大概描述一下的流程 (随机抓取) 选择压力机器,选择目标机器 创建测试任务 摘目标机器的线上流量,不能影响线上的用户(很重要 ) 参数设定,根据以往机器是的性能表现,设置开始并发量,以及并发持续的时间,和增长速度。 结果(这里的QPS数值是非真实的数值) 单台机器峰值QPS在3W左右,cpu使用率是75左右。出现大量的超时(其实QP1000,10%的逐渐增加) 二次结果:初始值给3000QPS直接给爆掉了。 并发使用异步还是同步,这个真的需要具体问题具体对待了。并发场景下起线程的异步千万不敢乱用。

    1.1K10编辑于 2021-12-07
  • 来自专栏站长的编程笔记

    利用python对websocket进行并发

    使用 WebSocketApp 的话,我没办法获取websocket服务器端返回的数据,这个我还在研究,这里使用 create_connection 来进行。 发送消息至服务器并接收返回结果: 1 initialize_data = '{"code":2001, "msg": "","data": ""}' 2 ws.send(initialize_data) 3  ,那短连接这里我愿成为:心脏起搏器(while True) 完整代码:  1 import threading  2 from websocket import create_connection  3  ): 19         t = threading.Thread(target=socket, args=()) 20         t.start() 利用python对websocket进行并发的相关教程结束

    1.3K20编辑于 2022-12-01
  • 来自专栏漫谈测试

    大型系统可用体系建设

    体系是测试时发现问题的重要手段。除了能帮助发现功能异常外,还能发现一些平时不容易发现的问题,如当系统压力大时系统的表现情况、线上系统的容量配比是否合理、系统的容灾保护是否到位等。 一般分为单系统和全链路,我们所说的是线上真实生产环境的压力测试。一、单系统比较容易实现,有多种实现手段。 选择合适的线上发工具或平台时,应考虑以下因素:协议支持:确保所选工具支持你要测试的应用程序使用的协议。并发能力:根据预期的用户量选择能产生足够并发请求的工具。 根据你的具体需求和技术栈,可以选择最适合的工具来进行线上发测试。四、体系实施的步骤有哪些?实施一个可用体系通常可以按照以下步骤进行,这些步骤旨在确保测试的有效性、准确性和可重复性:1. 3. 测试方案设计选择测试类型:根据需求选择适当的测试类型,比如负载测试、峰值测试、持久性测试、故障恢复测试等。设计测试用例:编写具体的测试场景,包含预期的操作流程、输入数据、期望的结果等。

    51010编辑于 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并发预估

    综合来说,适合单个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
  • 来自专栏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

    -s 指定服务器 socket 4 -c 指定并发连接数 50 5 -n 指定请求数 10000 6 -d 以字节的形式指定 SET/GET 值的数据大小 2 7 -k 1=keep 案例一 性能信息分析 机器配置 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研发总监海强,对于我们的业务系统能否经受的住并发用户访问,有什么测试手段和方法可以做到提前验证,与大家分享了实现平台的关键技术与细节。

    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

    -s 指定服务器 socket 4 -c 指定并发连接数 50 5 -n 指定请求数 10000 6 -d 以字节的形式指定 SET/GET 值的数据大小 2 7 -k 1=keep alive 0= 案例一 性能信息分析 机器配置 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(并发请求数 cipher suite (See openssl ciphers) -f protocol Specify SSL/TLS protocol (SSL3, 以上两个特性 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怎么使用_并发压力测试工具

    3.我下载的是jmeter4.0版本,对应jdk1.8。然后就进行解压。 个人认为要注意3点: 1)解压之后压缩包叫apache-jmeter-4.0.zip,如是src.zip后缀的都不对,打开之后会报错不可用,因为里面缺少我们下一步将要配置的环境变量.jar文件。 3)一定要确保环境变量配置正确(包括jdk的与jmeter的环境变量配置)。 好了,接下来进行环境变量配置吧,因为是新手所以参照了大佬们的教程,我就根据自己的实际遇到的情况,总结一下来做备忘。 然后点击确定保存即可 3)配置classpath变量,没有的话也要按照上面步骤进行新建,有的话直接进行选中,点击编辑即可。 7.安装结束~ 三、Jmeter测试案例实操 1、添加本次测试计划 (右键–>添加–>Threads(Users)–>线程组) 2、设置线程数 (所谓线程数就是并发用户数) 3、添加协议及相关配置信息

    1.6K30编辑于 2022-09-20
  • 来自专栏windealli

    常用工具

    后台开发经常需要对服务进行压力测试,下面介绍常用的工具。 webbench webbench 是常用的网站压力测试工具,webbench用C语言编写,代码仅有区区几百行。 最后两行是结构, 有测试的请求速度,成功的请求量、失败的请求量。 实现原理 通过调用fork()创建子进程,模拟多个客户端。

    4.4K50发布于 2018-09-27
  • 来自专栏云原生技术呱呱

    性能总结

    执行效率通过并发数、响应时间、吞吐量、成功率、资源消耗综合3 并发与并行,平时说的并发是广义并发,不是服务100个用户,而是单位时间处理100任务请求4 吞吐量=并发数/平均响应时间=请求总数/总时长, 实际并发往往不是工具预设的并发;二 UTgolang-sdk、java-sdk都提供了很好的工具三 组件1 工具http: abgrpc: ghz go get github.com/bojand /ghz2 环境对象=x核xG,外部依赖带宽,网卡...3 设计casescases并发数DurationReqRPS平均耗时P99吞吐实际并发CPU(4u)xxx100605816809694.5910.0338.069694.5997.237506760% ,系统可观测性,监控打点)1 链路确定,指定输入+输出2 系统环境准备链路上组件资源+依赖3 设计用例复杂度+压力大小(请求数、请求大小)4 记录数据5 分析结论比如关注就是系统的qps 、带宽用例组件1组件2组件3QPS入带宽xxx4C16G*24C8G*24C8G*22.5k/s160MB/s6 总结性能基线7 根据性能基线估算成本五 持续化测流程工具化,测报告自动化,用例集成到

    1.6K70编辑于 2022-07-14
  • 来自专栏johnnyxsu技术交流分享

    网站工具

    在日常售后工作中,常常需要对一些网站进行简单的,以判断网站的可用性。 此时通过源站就能够发现源站性能异常。 本文提供两种简单的网站脚本,能够快速的针对源站进行HTTP或HTTPS请求的。 HTTPStressTesting.git 下载后会有两个脚本文件: simple_stresstesting.sh 该脚本为一个简单的脚本测试工具,效率相对来说比较高 stresstesting.sh 该脚本为较为复杂的网站工具 simple_stresstesting.sh运行指南 image.png 运行该脚本后面跟多个变量,第一个变量需要输入请求的次数,后面的变量需要填写网站的url以及proxy等代理请求。 image.png 结束后会展示返回的状态码等统计信息。

    7K970发布于 2019-07-08
领券