秒杀系统性能测试和优化

Posted 111testing

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了秒杀系统性能测试和优化相关的知识,希望对你有一定的参考价值。

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

测试目标

对于一个系统,几个常用的评价指标是:平均响应时间、吞吐率、qps等。我的测试主要测试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的连接池最大线程数为maxThreads=”150” 越来越多的请求在等待队列中,因为我们前面分析过的tomcat。但是数据的相对值是有意义的。

 

 

使用redis缓存数据 


还是模拟500个用户,每个用户发送10次请求。

技术图片

 

 

 响应速度显著提高,注意一个值,Min=1,有些请求几乎不足1ms,因为redis直接从内存读取数值,非常快如果不是tomcat的请求在排队,我想平均响应时间是个位数。 

Redis下模拟5000个用户,每个用户发送一次请求。会是什么结果呢?

技术图片

 

 可以看到:模拟5000个用户比模拟500个用户的响应时间要慢很多,平均响应时间大概是8倍

 

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

技术图片

 

 可以看到,150个用户的话这种响应速度是比较快的,因此可以初步断定:响应的瓶颈在于tomcat的请求排队等待

 

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

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


原文链接:https://blog.csdn.net/OWEN_7/article/details/78319115

 

以上是关于秒杀系统性能测试和优化的主要内容,如果未能解决你的问题,请参考以下文章

系统性能测试方案

性能测试分析优化的方法论 | 运维进阶

我是新手,刚接触性能测试,实际工作中的性能测试的流程怎样的呢?

如何LoadRunner进行中间件的性能测试

某系统单点登录性能测试诊断分析优化过程

TPS从300笔/秒到5500笔/秒的性能测试优化之路