大并发的压测使用阿里的TPS(工具推荐篇)

前言:

先说下写这篇博客的由来,因双十一来临,作为电商,日活百万的产品是需要做双十一的压测的。根据当前线上qps为3600来计算,双十一的目标翻十倍,qps达到36000,当前的压测结果:1万的并发qps为2万,所以推测出大概并发在1w5左右(推测的东西会随便具体情况变化而变化),对于这种万级的并发,我觉得有条件可以搭建集群jmeter压测,那么就要考虑资源例如1万5的并发,一台支持500的并发就得30台机器,这个单机支持多少并发可以用压测的某个接口尝试下压测,根据当前机配置扩展,如果机器能到1000的并发对于中小型公司提供的资源已经很不错了,10000的并发也得15台机器。关键这样的集群压测只是为了双十一,那么双十一过后,机器其实处于闲置的状态,那么就是一个很大的资源浪费,但是对于日活百万正常qps是几千来说,并发也不过不到3千,那么搭建一个性能框架来做日常压测也是不错的。因为此篇针对大并发不浪费资源,还有团队能力不是很强情况下,选择阿里的TPS我觉得更合适一些

针对测试来说不需要搭建集群的jmeter确实很方便,不管从参数化还是传参断言都和jmeter很像,所以不太想写操作篇,下面给出了链接。用了一段时间感觉花钱的服务真好但是本是一个成长学习的机会,还是种种原因用了阿里的收费工具,确实对于个人还是团队都是一种遗憾。tps虽然支持了报告生成和采样的日志,不过我觉得这个工具的亮点是在阿里雄厚的秒级并发,测试报告等东西和jmeter没有很大的差距,如果是jmeter分布压 nmon分布采集我觉得会更细一点,只是多个数据整理的过程,但是详细的程度是超过tps的。

现在很多的公司也是在用阿里的机器,因为tps支持监控阿里机也是比较合适的,当然这款工具是收费的,只要花了钱,作为阿里的上帝,在瓶颈期实在解决不了问题的时候(遇到问题就问会形成依赖降低解决问题的能力)可以向阿里咨询也不失一个调优的办法。

操作文档:

https://help.aliyun.com/product/29260.html?spm=a2c4g.11186623.6.540.7aee1adeJcDdyr 关于操作阿里已经写的比较全了。

下一篇会写一篇jmeter分布式压测和nmon分布式采集的博客~

原文地址:https://www.cnblogs.com/Jack-cx/p/9908381.html

时间: 2024-11-06 15:14:57

大并发的压测使用阿里的TPS(工具推荐篇)的相关文章

基于Locust、Tsung的百万并发秒杀压测案例[转发]

原博客地址http://f.dataguru.cn/article-9116-1.html 不久前,数人云联合清华大学交叉信息研究院 OCP 实验室通过 10 台 OCP 服务器成功承载了百万并发 HTTP 请求. 此次实验设立的目标是在物理资源最小值的情况下完成 100 万并发处理,通过此次实验,最大化验证了基于 Mesos 和 Docker 技术的数人云 DCOS (数据中心操作系统)承载高压的能力. 百万压测工具与硬件 压测工具 本次选择的加压工具是分布式压测工具 Locust + Tsu

基于Locust、Tsung的百万并发秒杀压测案例[转]

编者按:高可用架构分享及传播在架构领域具有典型意义的文章,本文是 3 月 27 日数人云运维负责人庞铮在北京“百万并发”线下活动中的分享记录.   不久前,数人云联合清华大学交叉信息研究院 OCP 实验室通过 10 台 OCP 服务器成功承载了百万并发 HTTP 请求. 此次实验设立的目标是在物理资源最小值的情况下完成 100 万并发处理,通过此次实验,最大化验证了基于 Mesos 和 Docker 技术的数人云 DCOS (数据中心操作系统)承载高压的能力. 百万压测工具与硬件 压测工具 本次

记5.28大促压测的性能优化—线程池相关问题

目录: 1.环境介绍 2.症状 3.诊断 4.结论 5.解决 6.对比java实现 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下. 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C.UGC.直播等).平台中核心之一的就是订单域相关服务,下单服务.查单服务.支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单.结算.跳支付中心.每次业务方进行大促期间平台都要进行一次常规压测,做到心里

记5.28大促压测的性能优化—线程池相关问题

目录: 1.环境介绍 2.症状 3.诊断 4.结论 5.解决 6.对比java实现 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下. 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C.UGC.直播等).平台中核心之一的就是订单域相关服务,下单服务.查单服务.支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单.结算.跳支付中心.每次业务方进行大促期间平台都要进行一次常规压测,做到心里

全链路压测资料汇总——业内大厂解决方案

最近忙于公司的全链路压测平台调研和技术规划文档输出工作,参考了全网能搜到的业内大厂的全链路压测方案,这里做个汇总,以及将个人认为可以落地的方案做一个关键点整理. 技术链接 滴滴全链路压测解决之道 阿里巴巴的全链路压测 阿里怎么做双11全链路压测? 美团全链路压测自动化实践 全链路压测平台在美团中的实践 饿了么全链路压测的探索与实践 饿了么全链路压测平台的实现与原理 有赞全链路压测方案设计与实施详解 京东全链路压测系统(ForceBot)架构解密 罗辑思维在全链路压测方面的实践和工作笔记 大厂方案

基于Dubbo的压测调优实例

不久前参与开发了一个基于dubbo分布式框架的底层账单系统,并实现了其中的一部分业务接口,目前需对这些接口进行压测,以评估生产环境所能承受的最大吞吐量.笔者以其中一个查询接口为例来回顾此次压测的整体流程. 压测准备: 1.调用查询接口的测试jar包,作为dubbo-consumer,依赖了查询服务的api,测试module基于maven开发,执行maven clean package即可通过编译得到jar包 2.JMeter:Apache组织开发的基于Java的压力测试工具 方案: 无限次请求查

JMeter压测分布式部署

监控JMeter压力机的性能 netstat -an | find "TCP" /C 处理过程: 一:调度机master启动以后,会拷贝本地的jmx文件分发到远程的slave机器上: 二:slave机器拿到脚本以后启动命令行模式去执行脚本,对于每台slave机器拿到的脚本都是一样的,所以如果jmx脚本为50个线程跑3分钟,那么实际并发就是50*3=150个线程并发跑3分钟: 三:执行时,slave会把执行获得的数据结果传给master机器,master机器会收集所有slave机器的信息

一次tomcat压测调优记录

1. 前言 该tomcat web应用承担集团登录注册页面功能,对性能有一定要求,由于先前没有太多相关经验(只压测过一个dubbo服务),这次调得比较艰辛,便做个记录. 2. 调优过程 起初没有给运维任何tomcat配置要求,同时也没留意去确认tomcat配置,这个导致了后续压测过程各种诡异的问题. a.在压测初期,持续请求10分钟左右出现无请求进来,netstat查看的tomcat所在服务器存在大量CLOSE_WAIT的连接. CLOSE_WAIT的连接一般是自己程序中缺少关闭连接等引起,但是

【接口】接口压测性能分析及调优建议

常见的互联网架构中,一般都能看到spring+mybatis+mysql+redis搭配的身影,在我所服务的公司亦是如此.一般来说,应用内部的接口都是直接调用的,所谓的面向接口编程,应用间的调用直接调或者通过类似dubbo之类的服务框架来执行,数据格式往往采用json,即统一也方便各数据间做转换和取值,缓存一般使用redis或memcached,存储一些对象或json格式的字符串.对外提供的接口,一般都需要进行压力测试,以便估算其性能,并为后续的调优提供指导方向,以下接口便是在压测过程中出现的各