一、前言

接着上篇文章：电商系统设计到开发（第一版）-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

四、压测脚本

4.1 参数准备

随机1w个用户（编号在20000~30000）

抢购商品编号为10000，每次交易数量随机1~3

3.2 第一次压测-10个线程

压测5分钟，观察服务器的CPU和内存，最后看压测报告

走你：

数据库、goods-center、user-center服务，总体运行平稳，吞吐量44/s，99时延 358 ms

结论：顶得住！！！

3.3 第二次压测-30个线程

压测5分钟，观察服务器的CPU和内存，最后看压测报告

数据库、goods-center、user-center服务，总体运行平稳，吞吐量110/s，99时延 498 ms

结论：还能顶！！！

3.4 第三次压测-100个线程

压测5分钟，观察服务器的CPU和内存，最后看压测报告

数据库、goods-center、user-center服务，总体运行平稳，吞吐量115/s，99时延 1285ms

结论：增加了70个线程，吞吐量基本没有增加了，时延倒是增加了不少，所以基本上可以断定这个接口的并发量为110左右

五、原因分析

5.1 下单流程分析

一个请求需要，查询数据库4次，更新4次 ，插入2次

总共访问数据库10次，2个事务，其中3次查询是加锁查询，

还有 1 次 rpc 请求

那么如何提高并发量呢？

欢迎继续看后续的优化方案