如何带妹进行1000000PV的jmeter场景压测

1.需求
在这里插入图片描述
2.计算并发量
1000000PV/day,根据八二原则,计算QPS/TPS,相信80%的流量会集中到20%时间内。24小时流量集中到白天8小时内,同时在午高峰达到高峰。

  • QPS : (1000000 * 80%) / (8 * 3600 *20%) = 138.9QPS

根据响应耗时公式预估所需并发,一次请求RT=100ms

  • 则根据QPS = 并发数 / 平均响应时间,所以需要四舍五入需要14并发用户,一般用20线程

QPS:每秒钟处理完请求的次数;注意这⾥是处理完。具体是指发出请求到服务器处理完成功返回结果
TPS:每秒钟处理完的事务次数,⼀般TPS是对整个系统来讲的。⼀个应⽤系统1s能完成多少事务处理,⼀个事务在分布式处理中,可能会对应多个请求。

3.读取城市场景设计
使用固定吞吐量控制器constant Throughput Timer进行限制,当线程数足够多的时候,此限制器才会起到作用
想要设置成140的QPS,线程组设置为100,constant Throughput Timer设置为140除以100乘以60为84,具体设置如下:
在这里插入图片描述
在这里插入图片描述
4.其他场景按比例进行设计

5.这里就大致根据理论最大QPS,给网站做几个分类

50QPS以下——小网站

没什么好说的,简单的小网站而已,就如同本站这样,你可以用最简单的方法快速搭建,短期没有太多的技术瓶颈,只要服务器不要太烂就好。

50~100QPS——DB极限型

大部分的关系型数据库的每次请求大多都能控制在0.01秒左右,即便你的网站每页面只有一次DB请求,那么页面请求无法保证在1秒钟内完成100个请求,这个阶段要考虑做Cache或者多DB负载。无论那种方案,网站重构是不可避免的。

300~800QPS——带宽极限型

目前服务器大多用了IDC提供的“百兆带宽”,这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte,在这个并发条件下,百兆带宽已经吃完。首要考虑是CDN加速/异地缓存,多机负载等技术。

500~1000QPS——内网带宽极限+Memcache极限型

由于Key/value的特性,每个页面对memcache的请求远大于直接对DB的请求,Memcache的悲观并发数在2w左右,看似很高,但事实上大多数情况下,首先是有可能在次之前内网的带宽就已经吃光,接着是在8K QPS左右的情况下,Memcache已经表现出了不稳定,如果代码上没有足够的优化,可能直接将压力转嫁到了DB层上,这就最终导致整个系统在达到某个阀值之上,性能迅速下滑。

1000~2000QPS——FORK/SELECT,锁模式极限型

好吧,一句话:线程模型决定吞吐量。不管你系统中最常见的锁是什么锁,这个级别下,文件系统访问锁都成为了灾难。这就要求系统中不能存在中央节点,所有的数据都必须分布存储,数据需要分布处理。总之,关键词:分布

2000QPS以上——C10K极限

尽管现在很多应用已经实现了C25K,但短板理论告诉我们,决定网站整体并发的永远是最低效的那个环节。我承认我生涯中从未遇到过2000QPS以上,甚至1.5K以上的网站

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值