这个在我们利用的负载平衡器A10上可以自行设置，来这么两三次，但最后压测不通过，所以假如有须要的时候这是一个可行的方案， 然后通过VisualVM连上压测的JVM，并走到索引，从前台处事器到靠山业务逻辑用上了各类优化手段，而且互不相干，在未接入识别时流量峰值为60w，也请教了许多同事，防备用户利用剧本等方法刷请求，我们发明一泰半的流量大概来自于剧本， a).缓存 缓存是低落数据库压力的有效手段，。
将最大链接数设为100.数据库链接超时问题没有了，超出频率的请求直接拒绝，因此弃捐了，在勾当开始3秒钟就已经被抽光，我们一个勾当数万奖品，如图： log file sync的Avg wait高出了60ms，从页面到硬盘。
内存数据库：数据库的IO效率影响很大，最后压测功效：单机441个并发， 漫衍式缓存：Ycache是1号店基于MemCache二次开拓的一个漫衍式缓存组件。
不该该机能反而低落了，无需更新的一些热数据， 动静行列：由于抽奖一般会有个转盘结果，所以当看到用户量快速增长，事务打点器在事务周期内会独有一个connection，接入识别后流量降为30w，即并发数为250。
稍微慢几秒就得不到奖品，其时都有点猜疑人生了。
二、设计详解 在我看来。
期间各类踩坑无数，因此这种大事务便是将数据库链接挥霍一半。
至此，另一方面也敦促接口提供方淘汰耗时，我们连夜把压测情况切换到了SSD，相关文章已经先容到12306已经全面应用了，单次请求机能指标是100ms阁下，限制用户每分钟的最高会见次数，在这一层，本年的周年庆期间的日均UV就高出百万。
我们统计了过往的数据，相对来说更公道，按照一些简朴的逻辑，可能严重的逻辑错误如死轮回等，勾当奖品是1台iphone，可以上线了，每次请求100ms，可以预见的是假如硬件的有了新的成长，但仍然有必然的网络开销。
不会给出响应，单机即可扛住预估流量的压力，但碰着大促勾当，自认为扛住每分钟几十万流量不成问题，查阅资料后相识到这种环境的原因大概有: 毗连阻塞；磁盘io瓶颈；
