产业气象站|Hash 冲突还能这么玩,你的服务中招了吗?,没想到( 三 )


Morethanthemaximumnumberofrequestparameters(GETplusPOST)forasinglerequest([10,000])weredetected.Anyparametersbeyondthislimithavebeenignored.Tochangethislimit,setthemaxParameterCountattributeontheConnector.
产业气象站|Hash 冲突还能这么玩,你的服务中招了吗?,没想到
文章图片
post参数数量被限制
一种方法当然是去修改这个请求参数个数的限制 。 另外其实可以尝试用JDK1.7去验证 , 应该效果会更好(原因 , 聪明的读者你肯定知道吧?) 。 这里石头哥就懒得去折腾了 , 直接尝试以量来取胜 , 用前文说的ab进行并发提交请求 , 然后观察效果 。
这是我用如下参数跑的压测结果:
ab-c200-n100000-preq.txt"localhost:8080/hash"
压测的结果如图所示:
产业气象站|Hash 冲突还能这么玩,你的服务中招了吗?,没想到
文章图片
ab压测hash冲突结果
然后我们来看看CPU的变化情况 , 特意录屏做了个动图 , 可以看出还是相对比较明显的 。 从基本不占用cpu到39.6% , 然后突然就涨到158%了 。
产业气象站|Hash 冲突还能这么玩,你的服务中招了吗?,没想到
文章图片
hash-collision-demo动图
实际试验中这个过程没有一直持续(上面是重试过程中抓到的其中一次) , 一方面因为本人用的JDK1.8 , 本来冲突后的查找过程已经优化了 , 可能效果并不明显 , 另外也猜测可能会有一些cache之类的优化吧 , 另外对于10000的量也还不够?具体我也没有深究了 , 感兴趣的读者可以去尝试一下玩玩 。
到这里实验算成功了吧 。
产业气象站|Hash 冲突还能这么玩,你的服务中招了吗?,没想到
文章图片
【产业气象站|Hash 冲突还能这么玩,你的服务中招了吗?,没想到】实验成功就是拽


推荐阅读