使用JMeter对黑马点评进行测压，在单Tomcat的情况下，无限循环运行1000个线程在1秒内并发抢购秒杀券的qps在2600 左右。为了进一步探索系统的性能上限，我尝试在本地进行Tomcat 水平扩展实验。
首先将Tomcat提升到双节点，端口分别为8081和8082。这里可以在JMeter里面的HTTP Reques的Port Number使用一个${__Random(min,max)}指令，比如我这里就是${__Random(8081,8082)},这样就会随机向这两个端口发送请求了
双节点测压qps来到了4150左右。按道理来讲两个节点，效率不是应该翻倍吗？为什么这里只有一点五倍左右？别急，先往下看
运行结果如图：
将Tomcat提升到三节点，端口分别为8081，8082，8083，全部启动。将Port Number调成${__Random(8081,8083)}，运行结果如图：
停止压测一定要点击shutdow，不要点击stop！stop相当于直接拔掉电源，我截图里面那几个0.96%的error就是这么来的，我还找半天原因来着。（专业术语是这样的：
Shutdown (优雅停止) ：JMeter 会等待当前正在执行的线程完成手头的请求后再停止，保证了测试数据的完整性。 Stop (强制停止) ：JMeter 会直接断开所有线程的 Socket 连接（类似于 kill -9），导致客户端抛出 Socket closed 或 Connection reset 异常，从而产生错误的 Error 数据，干扰测试结果。）
并且本应该继续增加一倍的qps却和双节点情况下差不多，由此可以推测在双节点情况下已经到达性能瓶颈，也就是说性能瓶颈并不在Tomcat上。而我现在使用的实际上是在单机上跑多太Tomcat，所以我首先怀疑是单机CPU出现瓶颈，在多个tomcat之间切换导致性能不足。 开始实验：依旧是3节点tomcat运行，使用JMeter测压，开启一段时间后查看cpu的利用率：
如图可见，CPU的利用率远远没有达到瓶颈，所以不是主机CPU的原因。
，used_cpu_sys 和 used_cpu_user分别为A1A2和B1B2，这两条指令中间隔了十秒钟左右，经计算可得CPU使用率达到了86.23%（有点误差），所以这个时候性能瓶颈在redis的cpu上。
以上测试均为无redis写的情况，也就是库存为0进行抢优惠券，如果是1000线程一秒内抢100张票，不循环的话，实测无论是单机tomcat还是双节点三节点，qps都在900左右。性能下降的原因这里推测是由于lua脚本的执行时间变长。lua脚本是原子执行的，如果没有库存会直接判断完就退出，时间较短。如果有库存就涉及到库存扣减也就是redis写操作，Redis 是单线程的，假设一个脚本执行时间从 5 微秒变成 50 微秒，理论 QPS 就会直接除以 10，这可能就是 QPS 从 4000 掉到 900 的根本原因。
