线程组里面有三个接口请求，依次为：显示商品列表、登录秒杀平台账户、进行秒杀
对线程组用5000个线程循环10次
设置一下默认配置，之后就不用反复填写了
设置配置文件
这个具体功能就是读text文件并且设置变量的作用。
设置HTTP 请求
我们这次直接对秒杀功能进行压测，填写的路径如图所示，这个要参见之前的代码。访问这个路径时需要两个变量，其中token是从之前的文本文件中读取的（也可以从登录接口正则获取到），注意Value的语法（如何写的）。
结果展示
第一次运行的结果：
TPS：630.9/sec（不高）
错误率：64.73%（太高了）
错误率太高了，看一下程序，抛异常了。
Redis异常
很明显，这样的并发下Redis读取超时了。贴出Redis的配置：
数据库超卖现象
这是秒杀商品表，我们是对商品1进行秒杀的，库存成为负值，问题大了。我之前设置的秒杀商品个数给了9件，现在超卖了22件。
第二次运行结果
为了客观表现结果，重新再运行一次。注意把数据库信息清空的清空，恢复的恢复；把JMeter上次结果清空。
压力报告结果：
TPS：808.5/sec（不高）
错误率：67.16%（太高了）
Redis异常
和第一次一样，就不贴图了。
数据库超卖现象
4. 总结
这次实战结果就是：1. Redis读取超时抛异常导致压测的错误率太高；2. TPS不高，说明系统性能不佳；3. 数据库出现超卖现象，严重的业务逻辑错误。
5. 解决异常
程序抛异常，这是不应该产生的，先将抛异常的问题解决。
我一开始先把redis连接池重新配置：
运行后发现程序不抛异常了，但是压测的错误率并没有下降，依然在60%以上，意识到这可能不是简单改动程序就行了。
查看了压测的日志，也并没有报错，如果大家有遇到类似的问题，参考博文：
https://www.cnblogs.com/111testing/p/11437815.html
主要原因是：Windows 提供给 TCP/IP链接的端口为 1024-5000，并且要四分钟来循环回收他们。就导致我们在短时间内跑大量的请求时将端口占满了。
这个方法我试过了，用了这个方法可以把错误率大大降低，但是如果把并发调大还是会出现错误。
所以我想是不是本身就是我单机性能有限。可以把并发线程和循环次数适当调小。
原文链接：https://blog.csdn.net/Serena0814/article/details/89648174
