春哥， nginx subrequest性能问题

lihang_net

Hi,

章老师好，目前我用nginx 做redis3.0集群的proxy，普通接口都是利用upstream模块开发的，性能也不错。

但是，对于mset/mget 我是用nginx subrequest模块开发的， subrequest请求会去调用upstream模块，然后根据key%16386，得到槽slot_id。

根据slot_id就分为一次子请求，目前我有50个key mset/mget请求，一次请求，最多可能会有50次子请求。

由于子请求跟主请求都在一个work上，导致cpu瞬间就100%。

问题：

1. 想请教下春哥，关于nginx subrequest性能的问题，如果去优化？

2. 关于nginx proxy 实现redis的mset/mget 这样分发多次子请求好吗？

3. 或者nginx 有更好的方式来处理这种批量的接口吗？

感谢了，期待您的回复！

agentzh

Hello!

2016-01-27 8:57 GMT-08:00 Lucien Li:
>      章老师好， 目前我用nginx 做redis3.0集群的proxy，  普通接口都是利用upstream模块开发的， 性能也不错。
> 但是， 对于mset/mget 我是用nginx subrequest模块开发的， subrequest请求会去调用upstream模块，
> 然后根据key%16386，得到槽slot_id。
> 根据slot_id就分为一次子请求，目前我有50个key mset/mget请求，  一次请求， 最多可能会有50次子请求。
> 由于子请求跟主请求都在一个work上， 导致cpu瞬间就100%。
>

建议使用火焰图工具分析一下 CPU 时间具体花在哪里了，请见

    https://openresty.org/#Profiling

另外，建议尽量使用 lua-resty-redis 库，比你自己写 nginx C 模块简单多了，同时性能也有保证。

    https://github.com/openresty/lua-resty-redis

Regards,
-agentzh

lihang_net

感谢，在请教下春哥，关于子请求，请求是顺序请求，响应是无序的，怎样保证请求的和响应的对上。因为我同时发送很多子请求，怎么保证请求的和响应的是一致的？

感谢您的回复！

在 2016年1月28日星期四 UTC+8上午4:06:57，agentzh写道：

Hello!

2016-01-27 8:57 GMT-08:00 Lucien Li:
> 章老师好，目前我用nginx 做redis3.0集群的proxy，普通接口都是利用upstream模块开发的，性能也不错。
> 但是，对于mset/mget 我是用nginx subrequest模块开发的， subrequest请求会去调用upstream模块，
> 然后根据key%16386，得到槽slot_id。
> 根据slot_id就分为一次子请求，目前我有50个key mset/mget请求，一次请求，最多可能会有50次子请求。
> 由于子请求跟主请求都在一个work上，导致cpu瞬间就100%。
>

建议使用火焰图工具分析一下 CPU 时间具体花在哪里了，请见

https://openresty.org/#Profiling

另外，建议尽量使用 lua-resty-redis 库，比你自己写 nginx C 模块简单多了，同时性能也有保证。

https://github.com/openresty/lua-resty-redis

Regards,
-agentzh

agentzh

Hello!

2016-01-27 21:53 GMT-08:00 Lucien Li:
> 感谢， 在请教下春哥， 关于子请求， 请求是顺序请求， 响应是无序的， 怎样保证请求的和响应的对上。 因为我同时发送很多子请求，
> 怎么保证请求的和响应的是一致的？
>

这是通常是由 nginx 核心中的 ngx_http_postpone_filter_module 来自动保证的。

Regards,
-agentzh

lihang_net

春哥，

您好！关于subrequest的性能问题。

目前我用nginx做redis3.0集群的proxy，对于单个key/value 请求可以达到20w+, 但是对于mget/mset 我目前的做法是用subrequest 模块开发的，同时并行请求到后端的redis集群。

问题：

1. 当我mset/mget key/value数量是50个时候，进行压测，发现nginx的qps不高， 50个key/value会同时发起50次subrequest。（以前的版本是用java阻塞的方式循环发送50次，跟java相比对效果不明显， qps提不起来）

2. 我的架构师nginx 调用so， so是用c++开发的，大量用到了vector/map 不知道会不会很影响性能。

火焰图见附件。采样的cpu

sample-bt-off-cpu -p $1 --min 10 -t 10

非常感谢，期待的春哥的回复，感谢了！

在 2016年1月29日星期五 UTC+8上午3:23:46，agentzh写道：

Hello!

2016-01-27 21:53 GMT-08:00 Lucien Li:
> 感谢，在请教下春哥，关于子请求，请求是顺序请求，响应是无序的，怎样保证请求的和响应的对上。因为我同时发送很多子请求，
> 怎么保证请求的和响应的是一致的？
>

这是通常是由 nginx 核心中的 ngx_http_postpone_filter_module 来自动保证的。

Regards,
-agentzh

Attachment: 5826.svg
Description: image/svg

Attachment: 5825.svg
Description: image/svg

Attachment: 5824.svg
Description: image/svg

chen.wei37

2. 我的架构师nginx 调用so， so是用c++开发的，大量用到了vector/map 不知道会不会很影响性能。
---优酷的包解析那块代码感觉很耗CPU啊。

发件人: Lucien Li <liha...@126.com>
收件人: openresty <openresty@googlegroups.com>,
日期: 2016/02/02 16:39
主题: Re: [openresty] 春哥， nginx subrequest性能问题
发件人: openresty@googlegroups.com

春哥，
您好！关于subrequest的性能问题。

目前我用nginx做redis3.0集群的proxy，对于单个key/value 请求可以达到20w+, 但是对于mget/mset 我目前的做法是用subrequest 模块开发的，同时并行请求到后端的redis集群。

问题：
1. 当我mset/mget key/value数量是50个时候，进行压测，发现nginx的qps不高， 50个key/value会同时发起50次subrequest。（以前的版本是用java阻塞的方式循环发送50次，跟java相比对效果不明显， qps提不起来）

2. 我的架构师nginx 调用so， so是用c++开发的，大量用到了vector/map 不知道会不会很影响性能。

火焰图见附件。采样的cpu
sample-bt-off-cpu -p $1 --min 10 -t 10

非常感谢，期待的春哥的回复，感谢了！

在 2016年1月29日星期五 UTC+8上午3:23:46，agentzh写道：
Hello!

2016-01-27 21:53 GMT-08:00 Lucien Li:
> 感谢，在请教下春哥，关于子请求，请求是顺序请求，响应是无序的，怎样保证请求的和响应的对上。因为我同时发送很多子请求，
> 怎么保证请求的和响应的是一致的？
>

这是通常是由 nginx 核心中的 ngx_http_postpone_filter_module 来自动保证的。

Regards,
-agentzh


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

Attachment: 5826.svg
Description: Binary data

Attachment: 5825.svg
Description: Binary data

Attachment: 5824.svg
Description: Binary data

agentzh

Hello!

2016-02-02 0:38 GMT-08:00 Lucien Li:
> 火焰图见附件。 采样的cpu
> sample-bt-off-cpu -p $1  --min 10 -t 10
>

从火焰图上看，内存的动态分配和 C++ 字符串操作是性能瓶颈，特别是前者。你下回记得用 c++filt 过滤一下含有 C++ 函数调用帧的
bt 文件，否则 mangle 过的 C++ 函数符号根本没法看。

我没看出从图上看出你的性能问题和子请求本身的开销有什么关系。

另外，注意观察你的 redis cluster 有没有被压满。

我觉得这种东西用 ngx_lua 的轻线程 + cosocket 搞要方便和灵活得多。子请求也不是什么好东西，呵呵。

Regards,
-agentzh