接着上篇文章:电商系统设计到开发(第一版)-CSDN博客
已经开发的代码,今天我们对上面开发的代码进行压力测试,看看单机部署的情况下,性能表现如何。代码地址:风萧萧兮/concurrency-entry-task
有兴趣的可以看看
(保证测试用例都正常通过)
用户数:100w,用户ID 1~100_0000,每个用户余额 10w
商品数:100w,商品ID? 1~100_0000, 单价都为1元,数量均为1亿件,商家ID均为 100
模拟:1w个用户同时抢购同一件商品
我的本地window电脑作为测试机器(i7 13代处理器,32G内存+1T固态硬盘)
使用Wmware 虚拟了4台Centos机器分别是
Centos00 ,1CPU + 2G内存+? 20G固态硬盘? ?|? 部署 Consul server
Centos01 ,1CPU + 1G内存+? 20G固态硬盘? ?|? 部署 MySQL5.7.44
Centos02 ,1CPU + 1G内存+? 20G固态硬盘? ?|? 部署 user-center
Centos03 ,1CPU + 1G内存+? 20G固态硬盘? ?|? 部署 goods-center
随机1w个用户(编号在20000~30000)
抢购商品编号为10000,每次交易数量随机1~3
压测5分钟,观察服务器的CPU和内存,最后看压测报告
走你:
数据库、goods-center、user-center服务,总体运行平稳,吞吐量44/s,99时延 358 ms
结论:顶得住!!!
压测5分钟,观察服务器的CPU和内存,最后看压测报告
数据库、goods-center、user-center服务,总体运行平稳,吞吐量110/s,99时延 498 ms
结论:还能顶!!!
压测5分钟,观察服务器的CPU和内存,最后看压测报告
数据库、goods-center、user-center服务,总体运行平稳,吞吐量115/s,99时延 1285ms
结论:增加了70个线程,吞吐量基本没有增加了,时延倒是增加了不少,所以基本上可以断定这个接口的并发量为110左右
一个请求需要,查询数据库4次,更新4次 ,插入2次
总共访问数据库10次,2个事务,其中3次查询是加锁查询,
还有 1 次 rpc 请求
那么如何提高并发量呢?
欢迎继续看后续的优化方案