nginx lua 是否有关闭特定 worker 处理 request 的 api

xbsura · 2016-01-11T19:30:03+00:00

自己解决了:下载个pcre-8.37库 #!/bin/shcd ngx_openresty-1.9.7.1./configure --prefix=/home/sgws...

nginx lua 是否有关闭特定 worker 处理 request 的 api

xbsura

hi,all

最近在做一个流量调度模块, 作用是按照 uri 与一些负载信息将请求发送到不同后端, 全局配置存储在中心数据库, 遇到几个问题, 麻烦请教下

第一, 性能问题

测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简, 一些必要的操作都会导致 qps 下降, 比如重试

if ngx.ctx.tries == nil then

balancer.set_more_tries(1)

ngx.ctx.tries = 1

end

在 ab 测试中都会有接近100的性能下降, 更别说增加 header 头信息这样的字符串操作了, 问下是否有提高的办法

第二, share dict 的 incr 是否可以增加不存在设成1的参数控制

流量转发中, 有根据后端负载/2xx 比例/当前 running 数目进行转发的逻辑, 有一些数据记录在 shared dict 中, 由于 shared dict 对 incr 不存在返回错误, 而多个操作不能原子进行, 现在在初始化时全部设置成0, 增加了一些额外的麻烦, 有没有考虑 incr 时不存在设置成1, 像 redis 那样

第三, timeout 的设置

转发时客户端可能会带 timeout 参数过来, 但是没有找到在 lua 中设置 proxy_conn_timeout, write/read timeout 的 api, 如果有, 可否给下文档地址, 或者说明有即可

第四, 是否有关闭特定worker 请求处理的api

想实现部分 worker 处理请求, 部分 worker 同步策略的逻辑, 现在是通过启动时各个 worker 竞争全局锁, 拿到锁的进入死循环+sleep同步, 问下是否有更好的办法

另外, 赞一下 set_current_peer, 把请求交给 nginx 处理, 比 ngx 默认的 http 性能好很多, 也比基于 ngx.socket 的 http 库性能好很多

3ks

doujiang24

Hello,

在 2016年1月11日下午7:30，肖贝贝 <xb...@gmail.com>写道：

hi,all
最近在做一个流量调度模块, 作用是按照 uri 与一些负载信息将请求发送到不同后端, 全局配置存储在中心数据库, 遇到几个问题, 麻烦请教下

第一, 性能问题
测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简, 一些必要的操作都会导致 qps 下降, 比如重试

if ngx.ctx.tries == nil then
balancer.set_more_tries(1)
ngx.ctx.tries = 1
end

在 ab 测试中都会有接近100的性能下降, 更别说增加 header 头信息这样的字符串操作了, 问下是否有提高的办法

如果能有 CPU 采样火焰图出来就比较适合分析了

我觉得 ngx.ctx.tries 这个，或许提供一个 get_current_tires 可以更加高效一些，改天我测试一下

第二, share dict 的 incr 是否可以增加不存在设成1的参数控制
流量转发中, 有根据后端负载/2xx 比例/当前 running 数目进行转发的逻辑, 有一些数据记录在 shared dict 中, 由于 shared dict 对 incr 不存在返回错误, 而多个操作不能原子进行, 现在在初始化时全部设置成0, 增加了一些额外的麻烦, 有没有考虑 incr 时不存在设置成1, 像 redis 那样

这个已经有 PR 了，或许你可以尝试一下，也可以耐心等待春哥的 review

第三, timeout 的设置
转发时客户端可能会带 timeout 参数过来, 但是没有找到在 lua 中设置 proxy_conn_timeout, write/read timeout 的 api, 如果有, 可否给下文档地址, 或者说明有即可

据我所知是没有的，目前只有 balancer 部分的控制

确实，如果能把 upstream 里的原有控制指令，都能在 Lua 里实现，那就嗨皮了，哈哈

第四, 是否有关闭特定worker 请求处理的api
想实现部分 worker 处理请求, 部分 worker 同步策略的逻辑, 现在是通过启动时各个 worker 竞争全局锁, 拿到锁的进入死循环+sleep同步, 问下是否有更好的办法

没太看明白你的需求，或许 ngx.worker.id 是你需要的

另外, 赞一下 set_current_peer, 把请求交给 nginx 处理, 比 ngx 默认的 http 性能好很多, 也比基于 ngx.socket 的 http 库性能好很多

3ks

--

xbsura

3ks

超时应该可以先用

set_by_lua_file $proxy_conn_timeout ""设置值, 再用

proxy_conn_timeout $proxy_conn_timeout

qps 又要掉了...

火焰图还没弄好, 开发机的环境, oh...

在 2016年1月11日星期一 UTC+8下午8:38:10，doujiang写道：

Hello,

在 2016年1月11日下午7:30，肖贝贝 <xbs...@gmail.com>写道：
hi,all
最近在做一个流量调度模块, 作用是按照 uri 与一些负载信息将请求发送到不同后端, 全局配置存储在中心数据库, 遇到几个问题, 麻烦请教下

第一, 性能问题
测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简, 一些必要的操作都会导致 qps 下降, 比如重试

if ngx.ctx.tries == nil then
balancer.set_more_tries(1)
ngx.ctx.tries = 1
end

在 ab 测试中都会有接近100的性能下降, 更别说增加 header 头信息这样的字符串操作了, 问下是否有提高的办法

如果能有 CPU 采样火焰图出来就比较适合分析了
我觉得 ngx.ctx.tries 这个，或许提供一个 get_current_tires 可以更加高效一些，改天我测试一下

第二, share dict 的 incr 是否可以增加不存在设成1的参数控制
流量转发中, 有根据后端负载/2xx 比例/当前 running 数目进行转发的逻辑, 有一些数据记录在 shared dict 中, 由于 shared dict 对 incr 不存在返回错误, 而多个操作不能原子进行, 现在在初始化时全部设置成0, 增加了一些额外的麻烦, 有没有考虑 incr 时不存在设置成1, 像 redis 那样

这个已经有 PR 了，或许你可以尝试一下，也可以耐心等待春哥的 review

第三, timeout 的设置
转发时客户端可能会带 timeout 参数过来, 但是没有找到在 lua 中设置 proxy_conn_timeout, write/read timeout 的 api, 如果有, 可否给下文档地址, 或者说明有即可

据我所知是没有的，目前只有 balancer 部分的控制
确实，如果能把 upstream 里的原有控制指令，都能在 Lua 里实现，那就嗨皮了，哈哈

第四, 是否有关闭特定worker 请求处理的api
想实现部分 worker 处理请求, 部分 worker 同步策略的逻辑, 现在是通过启动时各个 worker 竞争全局锁, 拿到锁的进入死循环+sleep同步, 问下是否有更好的办法

没太看明白你的需求，或许 ngx.worker.id 是你需要的

另外, 赞一下 set_current_peer, 把请求交给 nginx 处理, 比 ngx 默认的 http 性能好很多, 也比基于 ngx.socket 的 http 库性能好很多

3ks

--

xbsura

oh, 超时似乎不能是变量, 好伤感

在 2016年1月11日星期一 UTC+8下午8:38:10，doujiang写道：

Hello,

在 2016年1月11日下午7:30，肖贝贝 <xbs...@gmail.com>写道：
hi,all
最近在做一个流量调度模块, 作用是按照 uri 与一些负载信息将请求发送到不同后端, 全局配置存储在中心数据库, 遇到几个问题, 麻烦请教下

第一, 性能问题
测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简, 一些必要的操作都会导致 qps 下降, 比如重试

if ngx.ctx.tries == nil then
balancer.set_more_tries(1)
ngx.ctx.tries = 1
end

在 ab 测试中都会有接近100的性能下降, 更别说增加 header 头信息这样的字符串操作了, 问下是否有提高的办法

如果能有 CPU 采样火焰图出来就比较适合分析了
我觉得 ngx.ctx.tries 这个，或许提供一个 get_current_tires 可以更加高效一些，改天我测试一下

第二, share dict 的 incr 是否可以增加不存在设成1的参数控制
流量转发中, 有根据后端负载/2xx 比例/当前 running 数目进行转发的逻辑, 有一些数据记录在 shared dict 中, 由于 shared dict 对 incr 不存在返回错误, 而多个操作不能原子进行, 现在在初始化时全部设置成0, 增加了一些额外的麻烦, 有没有考虑 incr 时不存在设置成1, 像 redis 那样

这个已经有 PR 了，或许你可以尝试一下，也可以耐心等待春哥的 review

第三, timeout 的设置
转发时客户端可能会带 timeout 参数过来, 但是没有找到在 lua 中设置 proxy_conn_timeout, write/read timeout 的 api, 如果有, 可否给下文档地址, 或者说明有即可

据我所知是没有的，目前只有 balancer 部分的控制
确实，如果能把 upstream 里的原有控制指令，都能在 Lua 里实现，那就嗨皮了，哈哈

第四, 是否有关闭特定worker 请求处理的api
想实现部分 worker 处理请求, 部分 worker 同步策略的逻辑, 现在是通过启动时各个 worker 竞争全局锁, 拿到锁的进入死循环+sleep同步, 问下是否有更好的办法

没太看明白你的需求，或许 ngx.worker.id 是你需要的

另外, 赞一下 set_current_peer, 把请求交给 nginx 处理, 比 ngx 默认的 http 性能好很多, 也比基于 ngx.socket 的 http 库性能好很多

3ks

--

agentzh

Hello!

2016-01-11 3:30 GMT-08:00 肖贝贝:
> 第一, 性能问题
> 测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer
> 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简,
> 一些必要的操作都会导致 qps 下降, 比如重试

感觉这有些不正常。你的测试环境是什么硬件配置，不是虚拟机吧？（即使是我 Macbook Pro 上的 VMWare
虚拟机，也不可能有这么夸张的性能变化）。怀疑有什么服务器配置方面的问题。

Regards,
-agentzh

xbsura

实体物理机, 详细信息

cpu: 【INTEL Xeon E5-2620 6C 2.0GHZ】*2

内存: 【---------------- 8G】*8

硬盘: 【---------------- 300G 10K】*6

另外, 编译 openresty 之后, 直接运行的 nginx 应该就使用了 git 吧? 不需要做额外配置吧?

附测试:

配置:

location / {

proxy_pass http://backend;

}

upstream backend {

server 0.0.0.0;

balancer_by_lua_file "flow.lua";

}

8021端口为 nginx 8 worker 的 echo, 性能较好

file 内容:

balancer.set_current_peer("127.0.0.1", 8021)

ab 测试结果

Requests per second: 6538.56 [#/sec] (mean)

增加重试

20 --------------------------------------------------------------------

21 if ngx.ctx.tries == nil then

22 balancer.set_more_tries(1)

23 ngx.ctx.tries = 1

24 else

25 ngx.ctx.tries = ngx.ctx.tries + 1

26 local service = ngx.ctx.service

27 local backend = ngx.ctx.backend

28 if ngx.ctx.tries <= static_conf["backends_max_tries"] then

29 dynamic_conf.request_callback(service, backend)

30 balancer.set_more_tries(1)

31 else

32 dynamic_conf.request_callback(service, backend)

33 return

34 end

35 end

36 --------------------------------------------------------------------

ab 测试结果:

Requests per second: 6228.97 [#/sec] (mean)

300没了, 所有流程下来, 6500 -> 4500, 整个代码的逻辑大概有:

header 赋值, 获取 uri, string.format()字符串拼接, shared dict 读写

3ks

在 2016年1月13日星期三 UTC+8上午3:50:18，agentzh写道：

Hello!

2016-01-11 3:30 GMT-08:00 肖贝贝:
> 第一, 性能问题
> 测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer
> 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简,
> 一些必要的操作都会导致 qps 下降, 比如重试

感觉这有些不正常。你的测试环境是什么硬件配置，不是虚拟机吧？（即使是我 Macbook Pro 上的 VMWare
虚拟机，也不可能有这么夸张的性能变化）。怀疑有什么服务器配置方面的问题。

Regards,
-agentzh

yuansheng

lua cache 是否设置了 on ？

如果有这么明显的效率差别，对两个场景抓取火焰图，对比一下，应该就可以看出问题在哪里了。

2016-01-13 10:36 GMT+08:00 肖贝贝 <xb...@gmail.com>:

实体物理机, 详细信息

cpu: 【INTEL Xeon E5-2620 6C 2.0GHZ】*2
内存: 【---------------- 8G】*8
硬盘: 【---------------- 300G 10K】*6

另外, 编译 openresty 之后, 直接运行的 nginx 应该就使用了 git 吧? 不需要做额外配置吧?

附测试:

配置:

location / {
proxy_pass http://backend;
}

upstream backend {
server 0.0.0.0;
balancer_by_lua_file "flow.lua";
}

8021端口为 nginx 8 worker 的 echo, 性能较好

file 内容:
balancer.set_current_peer("127.0.0.1", 8021)

ab 测试结果
Requests per second: 6538.56 [#/sec] (mean)

增加重试

20 --------------------------------------------------------------------
21 if ngx.ctx.tries == nil then
22 balancer.set_more_tries(1)
23 ngx.ctx.tries = 1
24 else
25 ngx.ctx.tries = ngx.ctx.tries + 1
26 local service = ngx.ctx.service
27 local backend = ngx.ctx.backend
28 if ngx.ctx.tries <= static_conf["backends_max_tries"] then
29 dynamic_conf.request_callback(service, backend)
30 balancer.set_more_tries(1)
31 else
32 dynamic_conf.request_callback(service, backend)
33 return
34 end
35 end
36 --------------------------------------------------------------------

ab 测试结果:

Requests per second: 6228.97 [#/sec] (mean)

300没了, 所有流程下来, 6500 -> 4500, 整个代码的逻辑大概有:

header 赋值, 获取 uri, string.format()字符串拼接, shared dict 读写

3ks

在 2016年1月13日星期三 UTC+8上午3:50:18，agentzh写道：
Hello!

2016-01-11 3:30 GMT-08:00 肖贝贝:
> 第一, 性能问题
> 测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer
> 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简,
> 一些必要的操作都会导致 qps 下降, 比如重试

感觉这有些不正常。你的测试环境是什么硬件配置，不是虚拟机吧？（即使是我 Macbook Pro 上的 VMWare
虚拟机，也不可能有这么夸张的性能变化）。怀疑有什么服务器配置方面的问题。

Regards,
-agentzh

--

YuanSheng Wang

---------------------------------------

My Github: https://github.com/membphis

OpenResty lover ^_^

xbsura

画火焰图需要内核的一些开发包, 公司的都是自己的东西, 编译完替换之后, 现在机器起不来了, 还没搞好

发下代码吧

看了下所有的逻辑, 基本可以简化成以下调用

----------------------------------------------------------------------------------------------

1 local balancer = require "ngx.balancer"

2 local shm = ngx.shared.ufc

4 for i=0, 15 do

5 shm:get(string.format("%s%s", "fgwuugfuiweg", "hofhiushu"))

6 end

8 for i=0, 5 do

9 ngx.ctx.ss = "dhauihdqu"

10 ngx.var.ufc_logid = 0

11 end

12 balancer.set_more_tries(1)

13 local args = ngx.req.get_uri_args()

14 local headers = ngx.req.get_headers()

15 string.format("%s%d", tostring(ngx.req.start_time()*1000):reverse():sub(1, 8) ,math.random(0,1000))

16 os.time()

17 os.time()

18 balancer.set_current_peer("127.0.0.1", 8021)

-------------------------------------------------------------------------------------------------------------------------------------------------

这种逻辑加上去, 与只使用

--------------------------------------------------

balancer.set_current_peer("127.0.0.1", 8021)

--------------------------------------------------

的单 worker 性能对比, ab 测试是

6200:5000, 麻烦问一下, 这种性能差别, 是不是预期之内的

cache 开了 on

jit 应该改了, ldd nginx, 能看到 jit 的 so 路径

其他还有什么需要注意的配置么

多谢

在 2016年1月13日星期三 UTC+8上午11:31:56，YuanSheng写道：

lua cache 是否设置了 on ？

如果有这么明显的效率差别，对两个场景抓取火焰图，对比一下，应该就可以看出问题在哪里了。

2016-01-13 10:36 GMT+08:00 肖贝贝 <xbs...@gmail.com>:
实体物理机, 详细信息

cpu: 【INTEL Xeon E5-2620 6C 2.0GHZ】*2
内存: 【---------------- 8G】*8
硬盘: 【---------------- 300G 10K】*6

另外, 编译 openresty 之后, 直接运行的 nginx 应该就使用了 git 吧? 不需要做额外配置吧?

附测试:

配置:

location / {
proxy_pass http://backend;
}

upstream backend {
server 0.0.0.0;
balancer_by_lua_file "flow.lua";
}

8021端口为 nginx 8 worker 的 echo, 性能较好

file 内容:
balancer.set_current_peer("127.0.0.1", 8021)

ab 测试结果
Requests per second: 6538.56 [#/sec] (mean)

增加重试

20 --------------------------------------------------------------------
21 if ngx.ctx.tries == nil then
22 balancer.set_more_tries(1)
23 ngx.ctx.tries = 1
24 else
25 ngx.ctx.tries = ngx.ctx.tries + 1
26 local service = ngx.ctx.service
27 local backend = ngx.ctx.backend
28 if ngx.ctx.tries <= static_conf["backends_max_tries"] then
29 dynamic_conf.request_callback(service, backend)
30 balancer.set_more_tries(1)
31 else
32 dynamic_conf.request_callback(service, backend)
33 return
34 end
35 end
36 --------------------------------------------------------------------

ab 测试结果:

Requests per second: 6228.97 [#/sec] (mean)

300没了, 所有流程下来, 6500 -> 4500, 整个代码的逻辑大概有:

header 赋值, 获取 uri, string.format()字符串拼接, shared dict 读写

3ks

在 2016年1月13日星期三 UTC+8上午3:50:18，agentzh写道：
Hello!

2016-01-11 3:30 GMT-08:00 肖贝贝:
> 第一, 性能问题
> 测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer
> 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简,
> 一些必要的操作都会导致 qps 下降, 比如重试

感觉这有些不正常。你的测试环境是什么硬件配置，不是虚拟机吧？（即使是我 Macbook Pro 上的 VMWare
虚拟机，也不可能有这么夸张的性能变化）。怀疑有什么服务器配置方面的问题。

Regards,
-agentzh

--

--

YuanSheng Wang
---------------------------------------
My Github: https://github.com/membphis
OpenResty lover ^_^

doujiang24

Hello,

在 2016年1月15日下午5:47，肖贝贝 <xb...@gmail.com>写道：

画火焰图需要内核的一些开发包, 公司的都是自己的东西, 编译完替换之后, 现在机器起不来了, 还没搞好

根据我的经验，最好是找一个新一点的发行版，比如 centos 6.3，然后编译一个新版本的内核，比如 3.10.x

发下代码吧

看了下所有的逻辑, 基本可以简化成以下调用

----------------------------------------------------------------------------------------------
1 local balancer = require "ngx.balancer"
2 local shm = ngx.shared.ufc
3
4 for i=0, 15 do
5 shm:get(string.format("%s%s", "fgwuugfuiweg", "hofhiushu"))
6 end
7
8 for i=0, 5 do
9 ngx.ctx.ss = "dhauihdqu"
10 ngx.var.ufc_logid = 0
11 end

以上两处，没看明白为什么要放入 for 循环

12 balancer.set_more_tries(1)
13 local args = ngx.req.get_uri_args()
14 local headers = ngx.req.get_headers()

这两个，可以在更之前的时序里完成并且缓存起来

比如在 access_by_lua 里缓存起来，在 balancer_by_lua 里直接使用

这样，即使有多次重试，也不会让这两个执行多次

15 string.format("%s%d", tostring(ngx.req.start_time()*1000):reverse():sub(1, 8) ,math.random(0,1000))
16 os.time()
17 os.time()

os.time() 可以说是禁忌项（每次 os.time 都会有系统调用）

建议你使用 ngx.time()

估计这里是导致性能下降的主因

18 balancer.set_current_peer("127.0.0.1", 8021)
-------------------------------------------------------------------------------------------------------------------------------------------------

这种逻辑加上去, 与只使用
--------------------------------------------------
balancer.set_current_peer("127.0.0.1", 8021)
--------------------------------------------------

的单 worker 性能对比, ab 测试是

6200:5000, 麻烦问一下, 这种性能差别, 是不是预期之内的

cache 开了 on
jit 应该改了, ldd nginx, 能看到 jit 的 so 路径

其他还有什么需要注意的配置么

多谢

在 2016年1月13日星期三 UTC+8上午11:31:56，YuanSheng写道：
lua cache 是否设置了 on ？

如果有这么明显的效率差别，对两个场景抓取火焰图，对比一下，应该就可以看出问题在哪里了。

2016-01-13 10:36 GMT+08:00 肖贝贝 <xbs...@gmail.com>:
实体物理机, 详细信息

cpu: 【INTEL Xeon E5-2620 6C 2.0GHZ】*2
内存: 【---------------- 8G】*8
硬盘: 【---------------- 300G 10K】*6

另外, 编译 openresty 之后, 直接运行的 nginx 应该就使用了 git 吧? 不需要做额外配置吧?

附测试:

配置:

location / {
proxy_pass http://backend;
}

upstream backend {
server 0.0.0.0;
balancer_by_lua_file "flow.lua";
}

8021端口为 nginx 8 worker 的 echo, 性能较好

file 内容:
balancer.set_current_peer("127.0.0.1", 8021)

ab 测试结果
Requests per second: 6538.56 [#/sec] (mean)

增加重试

20 --------------------------------------------------------------------
21 if ngx.ctx.tries == nil then
22 balancer.set_more_tries(1)
23 ngx.ctx.tries = 1
24 else
25 ngx.ctx.tries = ngx.ctx.tries + 1
26 local service = ngx.ctx.service
27 local backend = ngx.ctx.backend
28 if ngx.ctx.tries <= static_conf["backends_max_tries"] then
29 dynamic_conf.request_callback(service, backend)
30 balancer.set_more_tries(1)
31 else
32 dynamic_conf.request_callback(service, backend)
33 return
34 end
35 end
36 --------------------------------------------------------------------

ab 测试结果:

Requests per second: 6228.97 [#/sec] (mean)

300没了, 所有流程下来, 6500 -> 4500, 整个代码的逻辑大概有:

header 赋值, 获取 uri, string.format()字符串拼接, shared dict 读写

3ks

在 2016年1月13日星期三 UTC+8上午3:50:18，agentzh写道：
Hello!

2016-01-11 3:30 GMT-08:00 肖贝贝:
> 第一, 性能问题
> 测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer
> 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简,
> 一些必要的操作都会导致 qps 下降, 比如重试

感觉这有些不正常。你的测试环境是什么硬件配置，不是虚拟机吧？（即使是我 Macbook Pro 上的 VMWare
虚拟机，也不可能有这么夸张的性能变化）。怀疑有什么服务器配置方面的问题。

Regards,
-agentzh

--

--

YuanSheng Wang
---------------------------------------
My Github: https://github.com/membphis
OpenResty lover ^_^

--

toruneko.dai

在 2016年1月11日星期一 UTC+8下午7:30:04，肖贝贝写道：

hi,all
最近在做一个流量调度模块, 作用是按照 uri 与一些负载信息将请求发送到不同后端, 全局配置存储在中心数据库, 遇到几个问题, 麻烦请教下

第一, 性能问题
测试环境下, 一个 nginx worker, 原生的 upstream 可以到7000 qps, 直接使用 set_current_peer 也可以到接近7000 qps, 但是增加了一些逻辑操作之后, 性能掉的很厉害, 完整的逻辑下来, 已经到了不到5000 qps, 代码已经很精简, 一些必要的操作都会导致 qps 下降, 比如重试

if ngx.ctx.tries == nil then
balancer.set_more_tries(1)
ngx.ctx.tries = 1
end

在 ab 测试中都会有接近100的性能下降, 更别说增加 header 头信息这样的字符串操作了, 问下是否有提高的办法

第二, share dict 的 incr 是否可以增加不存在设成1的参数控制
流量转发中, 有根据后端负载/2xx 比例/当前 running 数目进行转发的逻辑, 有一些数据记录在 shared dict 中, 由于 shared dict 对 incr 不存在返回错误, 而多个操作不能原子进行, 现在在初始化时全部设置成0, 增加了一些额外的麻烦, 有没有考虑 incr 时不存在设置成1, 像 redis 那样

第三, timeout 的设置
转发时客户端可能会带 timeout 参数过来, 但是没有找到在 lua 中设置 proxy_conn_timeout, write/read timeout 的 api, 如果有, 可否给下文档地址, 或者说明有即可

提交了PR

https://github.com/openresty/lua-nginx-module/pull/700

https://github.com/openresty/lua-resty-core/pull/30

欢迎Review。

ps:我对lua-resty-core下面的test不太懂，依葫芦画瓢写了一些，至于repeat_each，blocks 就不知道咋改了

在本地测试的时候发现send_timeout不起作用，即使是proxy_send_timeout 0;也一样。还不晓得是为啥

第四, 是否有关闭特定worker 请求处理的api
想实现部分 worker 处理请求, 部分 worker 同步策略的逻辑, 现在是通过启动时各个 worker 竞争全局锁, 拿到锁的进入死循环+sleep同步, 问下是否有更好的办法

另外, 赞一下 set_current_peer, 把请求交给 nginx 处理, 比 ngx 默认的 http 性能好很多, 也比基于 ngx.socket 的 http 库性能好很多

3ks