capture_multi

tsingke.1987 · 2016-04-01T16:49:14+00:00

压力测试可以试试 Locust 和 wrk在 2016年4月1日上午10:10，&#x6...

capture_multi

tsingke.1987

文档上说：

Also note that subrequests just mimic the HTTP interface but there is no extra HTTP/TCP traffic nor IPC involved. Everything works internally, efficiently, on the C level.

我的做法是定义一个redis查询的处理

location = /redis/query {

#Do redis query

}

然后使用capture_multi来合并redis查询

ngx.location.capture_multi({

#query1,

#query2,

#query3

})

问题是这样做会导致大量TIME_WAIT

并且有很多lua tcp socket connect timed out 错误。

我的问题是既然文档是说不会有额外http/tcp为什么会产生这么多TIME_WAIT，是我理解有问题吗？

openresty version: 1.9.7.2

tsingke.1987

另外，根据我测试结果来看，这种方式和redis pipeline相比，性能差不多，比redis pipeline略差，这是为毛？

在 2016年4月1日星期五 UTC+8下午4:49:15，可二写道：

文档上说：
Also note that subrequests just mimic the HTTP interface but there is no extra HTTP/TCP traffic nor IPC involved. Everything works internally, efficiently, on the C level.

我的做法是定义一个redis查询的处理
location = /redis/query {
#Do redis query
}

然后使用capture_multi来合并redis查询
ngx.location.capture_multi({
#query1,
#query2,
#query3
})

问题是这样做会导致大量TIME_WAIT
并且有很多lua tcp socket connect timed out 错误。

我的问题是既然文档是说不会有额外http/tcp为什么会产生这么多TIME_WAIT，是我理解有问题吗？
openresty version: 1.9.7.2

doujiang24

hello

在 2016年4月1日下午4:49，可二 <tsing...@gmail.com>写道：

文档上说：
Also note that subrequests just mimic the HTTP interface but there is no extra HTTP/TCP traffic nor IPC involved. Everything works internally, efficiently, on the C level.

这一段说的是主请求调用子请求只有 C level 的调用

但是子请求本身涉及的 socket 调用还是一样会有的

我的做法是定义一个redis查询的处理
location = /redis/query {
#Do redis query
}

然后使用capture_multi来合并redis查询
ngx.location.capture_multi({
#query1,
#query2,
#query3
})

问题是这样做会导致大量TIME_WAIT
并且有很多lua tcp socket connect timed out 错误。

我的问题是既然文档是说不会有额外http/tcp为什么会产生这么多TIME_WAIT，是我理解有问题吗？
openresty version: 1.9.7.2

--

tsingke.1987

谢谢你的回复。

问题不是由于capture_multi造成的，是别的同事压测造成的。

但是使用capture_multi的方式cpu会比直接使用pipeline要高出30%左右，不知道是什么原因。

在 2016年4月2日星期六 UTC+8下午8:59:18，doujiang写道：

hello

在 2016年4月1日下午4:49，可二 <tsingk...@gmail.com>写道：
文档上说：
Also note that subrequests just mimic the HTTP interface but there is no extra HTTP/TCP traffic nor IPC involved. Everything works internally, efficiently, on the C level.

这一段说的是主请求调用子请求只有 C level 的调用

但是子请求本身涉及的 socket 调用还是一样会有的

我的做法是定义一个redis查询的处理
location = /redis/query {
#Do redis query
}

然后使用capture_multi来合并redis查询
ngx.location.capture_multi({
#query1,
#query2,
#query3
})

问题是这样做会导致大量TIME_WAIT
并且有很多lua tcp socket connect timed out 错误。

我的问题是既然文档是说不会有额外http/tcp为什么会产生这么多TIME_WAIT，是我理解有问题吗？
openresty version: 1.9.7.2

--

doujiang24

在 2016年4月5日下午8:42，可二 <tsing...@gmail.com>写道：

谢谢你的回复。

问题不是由于capture_multi造成的，是别的同事压测造成的。

好吧，下回报告问题还是仔细些好 :)

但是使用capture_multi的方式cpu会比直接使用pipeline要高出30%左右，不知道是什么原因。

pipeline 是在同一个 socket 上批量发送数据

capture_multi 是会创建多个 socket 并发发送

自然会更加消耗 cpu

在 2016年4月2日星期六 UTC+8下午8:59:18，doujiang写道：
hello

在 2016年4月1日下午4:49，可二 <tsingk...@gmail.com>写道：
文档上说：
Also note that subrequests just mimic the HTTP interface but there is no extra HTTP/TCP traffic nor IPC involved. Everything works internally, efficiently, on the C level.

这一段说的是主请求调用子请求只有 C level 的调用

但是子请求本身涉及的 socket 调用还是一样会有的

我的做法是定义一个redis查询的处理
location = /redis/query {
#Do redis query
}

然后使用capture_multi来合并redis查询
ngx.location.capture_multi({
#query1,
#query2,
#query3
})

问题是这样做会导致大量TIME_WAIT
并且有很多lua tcp socket connect timed out 错误。

我的问题是既然文档是说不会有额外http/tcp为什么会产生这么多TIME_WAIT，是我理解有问题吗？
openresty version: 1.9.7.2

--

--