秒杀系统性能测试和优化

对于大并发量的系统，有几个可能需要优化的点，下面我们要一步步测试来优化这个系统。

测试目标

对于一个系统，几个常用的评价指标是：平均响应时间、吞吐率、qps等。我的测试主要测试3个接口

1. 主页（访问根路径，没有数据库交互）
2. 秒杀接口暴露（暴露秒杀接口，有后台数据交互）
3. 执行秒杀操作（插入秒杀成功记录和减库存一个完整的事务操作）

对于这三个接口，我们主要的测试目标和优化目标是平均响应时间，当然这是建立在数据正确返回的基础上的，失败率太高那这个平均响应时间是没有意义的。
这里的优化侧重于后端数据库和内存方面的优化。

测试环境

我是在Windows10下用jmeter来进行负载测试和压力测试，其他环境如下，涉及具体配置再提。

• Tomcat8.0.38
• Jdk1.8 hotspot vm
• Mysql 5.7
• Redis 2.7.3

测试过程

首先进行主页测试，我们访问tomcat的主页，使用jmeter的线程组中的线程数模拟用户数，不断增加线程数对主页进行性能测试。
我们将结果数据写到一个xml文件中。首先我们模拟5000个用户同时请求主页。

5000个用户同时请求主页

设置循环次数为2，即一共有10000个请求将被发送。

从响应的结果可以看到，没有错误数，这10000个请求全部返回成功了，只是有的请求慢有的请求快。平均的响应时间在300ms,50%的请求的响应时间平均为87ms。到后面越来越多的请求开始等待，这里可以想到的优化的点在于tomcat的线程池中线程的数量，越来越多的请求在等待队列中。查看tomcat的配置后发现最大线程数为maxThreads=”150”，好那我们用150个线程，循环10次，也就是一共1500个请求，那结果会是什么样呢？

平均相应时间为5ms，前50%的请求的平均响应时间为1ms。
但是这里并不能直接修改tomcat的最大线程数来优化。复杂点说就是这是一个复杂的东西，线程数越大，你也要有相应的cpu来执行啊。直接点说就是，我不懂。。。
我把tomcat的线程数设置为500，然后起5000个线程发送10000个请求，然后得到了：

比之前的更差了。无论是平均相应时间还是错误率。简单粗暴的去改线程数是不可行的。这里我们不去管tomcat的线程数或者是其他层面的优化，我们只专注于后端数据库层面的优化。

500个用户同时请求暴露秒杀接口

为什么用500个，是为了减少因为tomcat请求等待带来的数据误差。
直接向MySQL请求数据
先模拟500个用户，每个用户发送10次请求。该请求相应的操作为根据id向数据库查询一条记录。得到了这样的数据。

期间打开windows的性能监控器，发现磁盘IO有变化，IO百分比最高的时候也不超过15%。
这样的操作，错误率为0，相当稳定，平均响应时间为1406ms。
模拟5000个用户，每个用户发送一次请求。、

磁盘的IO百分比一度达到了100%。从数据的绝对值来看，这样的测试没有意义了，因为瓶颈不在MySQL，而在我们前面分析过的tomcat。但是数据的相对值是有意义的。

使用redis缓存数据
还是模拟500个用户，每个用户发送10次请求。

响应速度显著提高，注意一个值，Min=1,有些请求几乎不足1ms，因为redis直接从内存读取数值，非常快。如果不是tomcat的请求在排队，我想平均响应时间是个位数。
Redis下模拟5000个用户，每个用户发送一次请求。会是什么结果呢？

使用150个线程，循环100次，即发送15000次请求，得到：

可以看到，150个用户的话这种响应速度是可以接受的，响应的瓶颈在于tomcat的请求排队等待。

———–我是分割线—————-

这个优化的过程我想到了很多东西，感觉就是，优化是无止尽的。
比如，我想到了内存回收那一块。选用合适的垃圾收集器，尽可能地减少GC时stop the world的时间和次数显然对于一个秒杀系统来说是非常对的优化方向。这里我尝试用过几款垃圾收集器比如parNew，G1来对比他们的平均响应时间，但是多次测试后没有明显的差距。有两个原因，一是这个接口没有产生太多的大对象，二是这个优化并不太明显。后面有机会的话还是希望继续在内存方面进行优化，感觉内存回收方面有点神秘，很想试一试。

————我是分割线————-

可以看到redis的使用很大程度上提高了响应的时间。上面那个接口只是暴露一个地址，这些地址每个产品都只有一个，那这样的场景是可以用redis的。但是有些操作并没有办法使用缓存。比如执行秒杀这个操作。
这个操作是个事务型操作。如果其中一个操作失败了，我就让他rollback，这样的话，应该会有更多的并发问题。
见下篇。