有关lua-resty-limit-traffic模块【高手请进】

[fishba...@gmail.com]

hello，有疑问，请砖家帮忙解答。

1.我在使用lua-resty-limit-traffic的resty.limit.req模块时，设置limit=300，后端接口响应时间为0.010, 在使用两个并发情况下，总qps在200时，出现部分delay的情况，这样很影响正常调用，为什么qps<limit值时也会出现delay？

2.resty.limit.req示例中（https://github.com/openresty/lua-resty-limit-traffic），delay为什么要大于等于0.001，这个0.001的值是否可更改，更改后会有什么影响？

               if delay >= 0.001 then
                    -- the 2nd return value holds the number of excess requests
                    -- per second for the specified key. for example, number 31
                    -- means the current request rate is at 231 req/sec for the
                    -- specified key.
                    local excess = err

                    -- the request exceeding the 200 req/sec but below 300 req/sec,
                    -- so we intentionally delay it here a bit to conform to the
                    -- 200 req/sec rate.
                    ngx.sleep(delay)
                end

[tokers]

> 1.我在使用lua-resty-limit-traffic的resty.limit.req模块时，设置limit=300，后端接口响应时间为0.010, 在使用两个并发情况下，总qps在200时，出现部分delay的情况，这样很影响正常调用，为什么qps<limit值时也会出现delay？

你的 limit 有包括 burst 吗？

> 2.resty.limit.req示例中（https://github.com/openresty/lua-resty-limit-traffic），delay为什么要大于等于0.001，这个0.001的值是否可更改，更改后会有什么影响？

ngx.sleep 时间精确到毫秒，小于 0.001 起不到 "sleep" 的效果。

[fishba...@gmail.com]

1.不包括，实际qps还没到300，就开始delay

2.经过测试，delay>0.5也会有控流效果，但是qps波动会增大。

在 2018年2月1日星期四 UTC+8下午7:52:52，tokers写道：

[tokers]

resty.limit.req 限速不是特别准确。

比如按你的设置，期望 qps 到 300 时才开始对请求进行延迟，然而它内部计算时精度是毫秒，

300r/s 它认为是平均 3.333 ms 来一个请求，所以如果你测试的时候某一小段时间内请求十分密集，

比如达到了 1ms 一个请求，那么即使 qps 没到 300，incoming 函数计算出来的 delay 也会是大于 0.001 的。

   excess = max(tonumber(rec.excess) - rate * abs(elapsed) / 1000 + 1000, 0)

这是它的核心公式，rec.excess 是上次计算得到的超过 rate 的请求数（*1000），rate 是用户设置的请求频率（*1000），

elapsed 是距离上次检查至今过去的时间(ms)。

按刚才的例子来看，假设 elapsed 是 1ms，rec.excess 是 0，rate 是 300r/s，那么

excess = max(0 - 300 * 1000 * 1 / 100 + 1000, 0)

此时得到 excess 是 700，所以延迟时间 delay 会是

delay =700 / (300 * 1000)

也就是 7/3000。

[Ming]

是的，resty.limit.req 是漏桶算法。

如果想按照总请求数来限速，可以用 resty.limit.count。

--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+unsubscribe@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html

[学不可以已]

@tokers, @WenMing 正好我也有类似问题，想看看有什么解释没有，使用是resty.limit.req,设置了rate=8 ,burst=0, 测试并发请求了20个，按这个示例漏桶我的理解是说，8个请求会200状态码，剩下12个请求都会被限制rejected，可是实际测试的时候，测了好几次都这样，发现只有2个请求200状态码，剩下18个被rejected，。想问下原因，这个怎么控制准确率？感谢

 

[tokers]

Hi!

感觉请求得是均匀进来的，这个控制才会准确。如果要按总量来控制，得用温铭老师说的 resty.limit.count。

On Sunday, February 11, 2018 at 5:51:18 PM UTC+8, 学不可以已 wrote:

[woodvillage]

想问下，nginx本身自带的limit_req也是和resty.limit.req一样的方案吗

在 2018年2月12日星期一 UTC+8下午4:52:31，tokers写道：

[DeJiang Zhu]

嗯，是一样的，一样的漏桶算法，所以一般需要配置合理的 burst

woodvillage <198...@gmail.com> 于2018年9月7日周五 下午5:05写道：

--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty...@googlegroups.com
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+...@googlegroups.com