|
|
最近比较闲，就顺便看看怎么能控制该死的flood。
据说这里的限制是3秒 80cmds， 我们姑且就按这个基础设计几套flood control throttle模型
模型1： 最简单最基础的模型。 Queue with delay
顾名思义，利用mushclient自身的Queue功能， 设定delay。 我初步尝试是35-40个命令每秒
偶尔会有flood，但是还是非常流畅。30个命令下几乎没有flood，脚本基本不会出错。
但是多多少还是会有影响。
结论：
- 大部分情况下不需要throttle，急速跑效率更高
- delay queue比较适合多步寻找，找到后原地bfs 2-3步就足够了。效率比公版单步寻找理论更好
进阶控制，计算过去3秒总共命令， 预测快到flood点把queue设成delay模式
计算3秒命令倒是不难，利用os.time 获取当前epoch值，这个是秒为单位的。
然后利用这个值作为key存存到lua table。 等于把table当成hashmap。
这样只要判断T(当前秒), T-1, T-2. 3个key的总值就可知道命令数量。
然后我们再做一个模型
模型2： 3 秒内大于 50个命令， 设置queue delay为30 如果小于30，queueu delay0
效果还是很不错，虽然偶尔还会有flood，但已经非常少了。 主要发生再1秒内怼>50个命令的极端情况下。
但是我还是不太满意，于是继续尝试第三种模式。。
模型3： 过去3秒内如果>75命令， 设置queue delay为1秒，等于强破下一个命令1秒后执行。 然后1秒后恢复到queue delay0
这种比较适合爆发性flood。 只能控制第一次爆发点。
这种需要配合脚本在必爆发的点稍微delay下，基本也不可能flood了。
主要也就是领悟的无止境爆发比较恶心。。。
模型3还是很稳定，flood需要微调脚本部分wait
模型2基本可以把脚本所有delay删掉，用这套throttle模型来控制
但是这几个模型还是比较简单，下一步应该就是尝试自己写cmd queue with pause
因为模型的缺点是计算的命令是放进queue的时间，而不是真正执行的时间。要知道真正执行的时间才能完美控制flood。
那我们只能自己写queue了。。
这个大家可以尝试下写个order table，整个放在coroutine下实现pause 和 delay两种模式
|
评分
-
1
查看全部评分
-
|
闽公网安备 35050202000162号 )
发表于 2020-2-23 12:54:49
