nginx的content handler需要生成大量的buf应用场景下，应该如何写这个handler?

peeonsky · 2014-10-31T11:58:02+00:00

你使用了锁吗，lua-resty-lock在 2014年11月10日星期一 UTC+8下午...

nginx的content handler需要生成大量的buf应用场景下，应该如何写这个handler?

peeonsky

hi, 各位大神：

我具体描述下我碰到的问题：

需求：

1)nginx的content handler接收到客户端的request后，会从一个大文件中(例如5G)根据某种规则选择数据片段发送给客户端

2)数据片段在文件中是不连续的，需要跳过数据片段之间的废数据

3)需要发送的数据片段可能达到50万个。

方案：

1）创建了50万个buf，每个buf里边标识了这些数据片段在file中的位置，并通过若干条chain发送给客户端

问题：

1)由于创建了50万个buf，导致占用了nginx很多内存，大概170M。在有多个请求同时发出时，导致nginx内存耗尽。

改进方案：

1）在content handler中创建timer 事件，在timer handler中检查已发送数据，当已发送数据达到某个阈值时，才继续生成新数据发送给客户端，否则再次挂载timer时间，直到下次继续检查。

改进方案的问题：

1）有时候timer事件醒来时，发现连接已经被nginx释放掉了，r->pool已经被置为NULL，会导致最后一部分数据没有发送出去（特别是客户端下载速度快，但服务端由于timer事件，未及时生成数据的时候）

2）只是减慢了内存的耗尽速度，无法重复利用nginx已经发送完的数据buf和chain。在请求多时，内存依旧会耗尽。

像这样的应用场景，我应该如何去写这个handler，或者干脆不是用handler来处理的，而是其它的机制？

恳切盼望赐教。

agentzh

Hello!

2014-10-30 20:58 GMT-07:00 peeonsky:
> 方案：
> 1）创建了50万个buf，每个buf里边标识了这些数据片段在file中的位置，并通过若干条chain发送给客户端
>

建议自己开辟一个或多个定长的内存缓冲区，把不连续的文件数据块填充到这个缓冲区里。

缓冲区满了（或者没新数据了）就往下游写，只到下游全部刷出再接着填充。

具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。

这种需求使用 ngx_lua 模块只需十几行 Lua 代码就可以搞定，而且效率可以很高。最有用的就是 ngx_lua 模块提供的 Lua
API 函数 ngx.flush(true):

    https://github.com/openresty/lua-nginx-module#ngxflush

这样可以做到严格的流式输出，nginx 一侧对于单位请求的内存占用保持一个很小的常数，而无论响应数据流本身有多大。

> 改进方案：
> 1）在content handler中创建timer 事件，在timer
> handler中检查已发送数据，当已发送数据达到某个阈值时，才继续生成新数据发送给客户端，否则再次挂载timer时间，直到下次继续检查。
>

既然已经有 epoll/kqueue/poll 这样的 API 驱动的事件循环了，就应该直接使用现成的“写事件”（write
event），而不是自己通过 timer 去 poll. 前者显然要高效得多，同时也不会引入不必要的延时。

Regards,
-agentzh

peeonsky

hi:

谢谢回答。

我先试试原生模块的处理方式。

在 2014年11月1日星期六UTC+8上午4时33分49秒，agentzh写道：

Hello!

2014-10-30 20:58 GMT-07:00 peeonsky:
> 方案：
> 1）创建了50万个buf，每个buf里边标识了这些数据片段在file中的位置，并通过若干条chain发送给客户端
>

建议自己开辟一个或多个定长的内存缓冲区，把不连续的文件数据块填充到这个缓冲区里。

缓冲区满了（或者没新数据了）就往下游写，只到下游全部刷出再接着填充。

具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。

这种需求使用 ngx_lua 模块只需十几行 Lua 代码就可以搞定，而且效率可以很高。最有用的就是 ngx_lua 模块提供的 Lua
API 函数 ngx.flush(true):

https://github.com/openresty/lua-nginx-module#ngxflush

这样可以做到严格的流式输出，nginx 一侧对于单位请求的内存占用保持一个很小的常数，而无论响应数据流本身有多大。

> 改进方案：
> 1）在content handler中创建timer 事件，在timer
> handler中检查已发送数据，当已发送数据达到某个阈值时，才继续生成新数据发送给客户端，否则再次挂载timer时间，直到下次继续检查。
>

既然已经有 epoll/kqueue/poll 这样的 API 驱动的事件循环了，就应该直接使用现成的“写事件”（write
event），而不是自己通过 timer 去 poll. 前者显然要高效得多，同时也不会引入不必要的延时。

Regards,
-agentzh

jie123108

原生模块处理这种情况还很复杂的，之前我也尝试过，发现只是简单的循环输出１０W个hello world都比较困难的。最终我还是使用了ngx_lua。

jie1...@gmail.com

发件人： peeonsky
发送时间： 2014-11-03 12:03
收件人： openresty
主题： Re: [openresty] nginx的content handler需要生成大量的buf应用场景下，应该如何写这个handler?
hi:
谢谢回答。
我先试试原生模块的处理方式。

peeonsky

hi, agentzh:

根据您的提醒，利用ngx_chain_update_chains我已经实现了内存重复利用了，目前不会内存消耗过大了。

但目前利用timer事件的实现，连接会被nginx提前释放掉。这个我猜是因为我的content handler已经返回OK了，nginx以为不会再产生内容了，

但nginx不知道我的内容产生是通过timer的事件处理函数来产生内容的。

>> 具体做法是使用 r->write_event_handler、ngx_http_output_filter、和

>> ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。

这个能更加详细地提示下如何根据输出情况来触发产生后续内容吗？

在 2014年11月1日星期六UTC+8上午4时33分49秒，agentzh写道：

Hello!

2014-10-30 20:58 GMT-07:00 peeonsky:
> 方案：
> 1）创建了50万个buf，每个buf里边标识了这些数据片段在file中的位置，并通过若干条chain发送给客户端
>

建议自己开辟一个或多个定长的内存缓冲区，把不连续的文件数据块填充到这个缓冲区里。

缓冲区满了（或者没新数据了）就往下游写，只到下游全部刷出再接着填充。

具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。

这种需求使用 ngx_lua 模块只需十几行 Lua 代码就可以搞定，而且效率可以很高。最有用的就是 ngx_lua 模块提供的 Lua
API 函数 ngx.flush(true):

https://github.com/openresty/lua-nginx-module#ngxflush

这样可以做到严格的流式输出，nginx 一侧对于单位请求的内存占用保持一个很小的常数，而无论响应数据流本身有多大。

> 改进方案：
> 1）在content handler中创建timer 事件，在timer
> handler中检查已发送数据，当已发送数据达到某个阈值时，才继续生成新数据发送给客户端，否则再次挂载timer时间，直到下次继续检查。
>

既然已经有 epoll/kqueue/poll 这样的 API 驱动的事件循环了，就应该直接使用现成的“写事件”（write
event），而不是自己通过 timer 去 poll. 前者显然要高效得多，同时也不会引入不必要的延时。

Regards,
-agentzh

peeonsky

另外，如果使用ngx_lua模块来实现，还能够利用sendfile特性吗？

即不将文件里边的内容读出来放到内存再通过ngx_lua模块出去，这样可以省IO

在 2014年11月4日星期二UTC+8下午4时53分03秒，peeonsky写道：

hi, agentzh:
根据您的提醒，利用ngx_chain_update_chains我已经实现了内存重复利用了，目前不会内存消耗过大了。

但目前利用timer事件的实现，连接会被nginx提前释放掉。这个我猜是因为我的content handler已经返回OK了，nginx以为不会再产生内容了，
但nginx不知道我的内容产生是通过timer的事件处理函数来产生内容的。

>> 具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
>> ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。

这个能更加详细地提示下如何根据输出情况来触发产生后续内容吗？

在 2014年11月1日星期六UTC+8上午4时33分49秒，agentzh写道：
Hello!

2014-10-30 20:58 GMT-07:00 peeonsky:
> 方案：
> 1）创建了50万个buf，每个buf里边标识了这些数据片段在file中的位置，并通过若干条chain发送给客户端
>

建议自己开辟一个或多个定长的内存缓冲区，把不连续的文件数据块填充到这个缓冲区里。

缓冲区满了（或者没新数据了）就往下游写，只到下游全部刷出再接着填充。

具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。

这种需求使用 ngx_lua 模块只需十几行 Lua 代码就可以搞定，而且效率可以很高。最有用的就是 ngx_lua 模块提供的 Lua
API 函数 ngx.flush(true):

https://github.com/openresty/lua-nginx-module#ngxflush

这样可以做到严格的流式输出，nginx 一侧对于单位请求的内存占用保持一个很小的常数，而无论响应数据流本身有多大。

> 改进方案：
> 1）在content handler中创建timer 事件，在timer
> handler中检查已发送数据，当已发送数据达到某个阈值时，才继续生成新数据发送给客户端，否则再次挂载timer时间，直到下次继续检查。
>

既然已经有 epoll/kqueue/poll 这样的 API 驱动的事件循环了，就应该直接使用现成的“写事件”（write
event），而不是自己通过 timer 去 poll. 前者显然要高效得多，同时也不会引入不必要的延时。

Regards,
-agentzh

agentzh

Hello!

2014-11-04 0:53 GMT-08:00 peeonsky:
>      但目前利用timer事件的实现，连接会被nginx提前释放掉。这个我猜是因为我的content
> handler已经返回OK了，nginx以为不会再产生内容了，
>      但nginx不知道我的内容产生是通过timer的事件处理函数来产生内容的。
>

nginx 主要是靠 IO 事件驱动的，而不是靠一堆的 timer 来驱动 :) 总是使用 timer 自己来 poll IO，其实就根本没
epoll/kqueue 啥事了。

>     >> 具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
>     >> ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。
>
>      这个能更加详细地提示下如何根据输出情况来触发产生后续内容吗？
>

当 ngx_http_output_filter 返回 NGX_AGAIN 时，表明系统写缓冲区以满，此时你简单地结束当前的 event
handler 的执行（一般通过返回 NGX_DONE），然后等 nginx 事件循环在当前连接上有新的可写事件时自动调用你的
r->write_event_handler. 然后在 r->write_event_handler 里你再通过 NULL 作为 chain
参数调用 ngx_http_output_filter 继续刷写 nginx
尚未刷出的数据（如果有成功刷出更多的数据，你可以同时生成更多的数据供刷出）。

具体可以参考包括 ngx_lua 在内的现有的 nginx C 模块在这一块的实现。

> 另外，如果使用ngx_lua模块来实现，还能够利用sendfile特性吗？
> 即不将文件里边的内容读出来放到内存再通过ngx_lua模块出去，这样可以省IO
>

对于你这里产生大量很碎的不连续的 buf 的场景，我极端怀疑 sendfile 会帮助你提高性能，相反我觉得很可能 sendfile
会严重降低你的系统吞吐能力。这是因为你需要产生数目极多的 sendfile
系统调用（因为你的数据不连续，这些系统调用无法合并），而系统调用一般是非常昂贵的（涉及上下文切换等等），调用次数能减一点都是好的（这一点对于
writev 等其他系统调用也是适用的）。当你通过 ngx_lua 把很零碎的文件数据进行合并之后，所需的 writev
系统调用的次数相对会减少非常多，这有助于提升你的系统的整体吞吐能力。当然，你总是应当进行实地的测量和 profile（火焰图工具 [1]
在这里会极为有用！）. 我的意见仅供参考。

一般地，涉及到系统性能分析，往往是比较复杂的，通常并不是一个因素在起作用（比如并不是简单地 sendfile 就一定能提高 IO
效率），而是很多因素相互影响，相互牵制。而调优则是在各种复杂制约因素之间寻求对于系统整体而言（而不是仅对系统的某一个方面）的最佳平衡点。

Regards,
-agentzh

[1] https://github.com/openresty/nginx-systemtap-toolkit#sample-bt 与
https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu

peeonsky

好的，非常感谢。我到时两种方案都试一下。

在 2014年11月5日星期三UTC+8上午2时01分37秒，agentzh写道：

Hello!

2014-11-04 0:53 GMT-08:00 peeonsky:
> 但目前利用timer事件的实现，连接会被nginx提前释放掉。这个我猜是因为我的content
> handler已经返回OK了，nginx以为不会再产生内容了，
> 但nginx不知道我的内容产生是通过timer的事件处理函数来产生内容的。
>

nginx 主要是靠 IO 事件驱动的，而不是靠一堆的 timer 来驱动 :) 总是使用 timer 自己来 poll IO，其实就根本没
epoll/kqueue 啥事了。

> >> 具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
> >> ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。
>
> 这个能更加详细地提示下如何根据输出情况来触发产生后续内容吗？
>

当 ngx_http_output_filter 返回 NGX_AGAIN 时，表明系统写缓冲区以满，此时你简单地结束当前的 event
handler 的执行（一般通过返回 NGX_DONE），然后等 nginx 事件循环在当前连接上有新的可写事件时自动调用你的
r->write_event_handler. 然后在 r->write_event_handler 里你再通过 NULL 作为 chain
参数调用 ngx_http_output_filter 继续刷写 nginx
尚未刷出的数据（如果有成功刷出更多的数据，你可以同时生成更多的数据供刷出）。

具体可以参考包括 ngx_lua 在内的现有的 nginx C 模块在这一块的实现。

> 另外，如果使用ngx_lua模块来实现，还能够利用sendfile特性吗？
> 即不将文件里边的内容读出来放到内存再通过ngx_lua模块出去，这样可以省IO
>

对于你这里产生大量很碎的不连续的 buf 的场景，我极端怀疑 sendfile 会帮助你提高性能，相反我觉得很可能 sendfile
会严重降低你的系统吞吐能力。这是因为你需要产生数目极多的 sendfile
系统调用（因为你的数据不连续，这些系统调用无法合并），而系统调用一般是非常昂贵的（涉及上下文切换等等），调用次数能减一点都是好的（这一点对于
writev 等其他系统调用也是适用的）。当你通过 ngx_lua 把很零碎的文件数据进行合并之后，所需的 writev
系统调用的次数相对会减少非常多，这有助于提升你的系统的整体吞吐能力。当然，你总是应当进行实地的测量和 profile（火焰图工具 [1]
在这里会极为有用！）. 我的意见仅供参考。

一般地，涉及到系统性能分析，往往是比较复杂的，通常并不是一个因素在起作用（比如并不是简单地 sendfile 就一定能提高 IO
效率），而是很多因素相互影响，相互牵制。而调优则是在各种复杂制约因素之间寻求对于系统整体而言（而不是仅对系统的某一个方面）的最佳平衡点。

Regards,
-agentzh

[1] https://github.com/openresty/nginx-systemtap-toolkit#sample-bt 与
https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu

peeonsky

hi, agentzh:

根据你的提示，我已经利用nginx 模块的方式实现了。但有两个疑问，不知道是否是有问题的：

1）使用NULL作为chain的参数调用ngx_http_output_filter （）来刷数据，有时候会导致 ngx_http_write_filter 模块抛出"the http output chain is empty"错误，

从而终止了请求。

这一块查阅ngx_http_write_filter的模块后，我使用了一个只用来flush的特殊chain来刷数据检查了，类似：

static ngx_int_t check_output_filter( ngx_http_request_t* r, ngx_http_foo_ctx_t *ctx )
{
    ngx_chain_t * chain_flush    = NULL;
    chain_flush = ngx_chain_get_free_buf( r->pool, &ctx->free );
    if ( chain_flush == NULL ) {
        return NGX_ERROR;
    }

    chain_flush->buf->pos       = 0;
    chain_flush->buf->last      = 0;
    chain_flush->buf->start     = 0;
    chain_flush->buf->end       = 0;
    chain_flush->buf->in_file   = 0;
    chain_flush->buf->memory    = 0;
    chain_flush->buf->flush     = 1;
    chain_flush->buf->last_in_chain  = 1;
    chain_flush->buf->tag            = (ngx_buf_tag_t) &ngx_http_foo_module;

    ngx_int_t rc = ngx_http_output_filter(r, chain_flush);

    if ( rc != NGX_AGAIN && rc != NGX_OK ) {
        return NGX_ERROR;
    }

    ngx_chain_update_chains(r->pool, &ctx->free, &ctx->busy, &chain_flush, (ngx_buf_tag_t) &ngx_http_foo_module);

    return rc;
}

我不知道这个是否是正常的做法。如果不正常，能否告知通常是如何检查ngx_http_ouput_filter是否能够继续刷写数据的。

2）刚开始我挂了自己的write_event_handler，但nginx不会调用我的write_event_handler，后来查阅相关代码，加上了r->count++; ，我的write_event_handler才会被触发调用到。

但我不知道r->count 这个标识是做什么用的。类似代码：

r->count++;  //留意，加上这行代码后，我自己的ngx_http_foo_sample_handler才会被执行。
r->write_event_handler = ngx_http_foo_sample_handler;

ngx_connection_t     *c;

c = r->connection;

if (!c->write->active) {
    rc = ngx_add_event(r->connection->write, NGX_WRITE_EVENT, NGX_CLEAR_EVENT);
    if ( rc != NGX_OK) {
        return rc;
    }
}

return NGX_DONE;

能否简单说下r->count 这个参数是起什么作用的？

3）是否有nginx代码风格的cindent配置？有的话能否共享下。

多谢指教。

在 2014年11月5日星期三UTC+8上午2时01分37秒，agentzh写道：

Hello!

2014-11-04 0:53 GMT-08:00 peeonsky:
> 但目前利用timer事件的实现，连接会被nginx提前释放掉。这个我猜是因为我的content
> handler已经返回OK了，nginx以为不会再产生内容了，
> 但nginx不知道我的内容产生是通过timer的事件处理函数来产生内容的。
>

nginx 主要是靠 IO 事件驱动的，而不是靠一堆的 timer 来驱动 :) 总是使用 timer 自己来 poll IO，其实就根本没
epoll/kqueue 啥事了。

> >> 具体做法是使用 r->write_event_handler、ngx_http_output_filter、和
> >> ngx_chain_update_chains 这些东西。timer 只用于写超时的保护。
>
> 这个能更加详细地提示下如何根据输出情况来触发产生后续内容吗？
>

当 ngx_http_output_filter 返回 NGX_AGAIN 时，表明系统写缓冲区以满，此时你简单地结束当前的 event
handler 的执行（一般通过返回 NGX_DONE），然后等 nginx 事件循环在当前连接上有新的可写事件时自动调用你的
r->write_event_handler. 然后在 r->write_event_handler 里你再通过 NULL 作为 chain
参数调用 ngx_http_output_filter 继续刷写 nginx
尚未刷出的数据（如果有成功刷出更多的数据，你可以同时生成更多的数据供刷出）。

具体可以参考包括 ngx_lua 在内的现有的 nginx C 模块在这一块的实现。

> 另外，如果使用ngx_lua模块来实现，还能够利用sendfile特性吗？
> 即不将文件里边的内容读出来放到内存再通过ngx_lua模块出去，这样可以省IO
>

对于你这里产生大量很碎的不连续的 buf 的场景，我极端怀疑 sendfile 会帮助你提高性能，相反我觉得很可能 sendfile
会严重降低你的系统吞吐能力。这是因为你需要产生数目极多的 sendfile
系统调用（因为你的数据不连续，这些系统调用无法合并），而系统调用一般是非常昂贵的（涉及上下文切换等等），调用次数能减一点都是好的（这一点对于
writev 等其他系统调用也是适用的）。当你通过 ngx_lua 把很零碎的文件数据进行合并之后，所需的 writev
系统调用的次数相对会减少非常多，这有助于提升你的系统的整体吞吐能力。当然，你总是应当进行实地的测量和 profile（火焰图工具 [1]
在这里会极为有用！）. 我的意见仅供参考。

一般地，涉及到系统性能分析，往往是比较复杂的，通常并不是一个因素在起作用（比如并不是简单地 sendfile 就一定能提高 IO
效率），而是很多因素相互影响，相互牵制。而调优则是在各种复杂制约因素之间寻求对于系统整体而言（而不是仅对系统的某一个方面）的最佳平衡点。

Regards,
-agentzh

[1] https://github.com/openresty/nginx-systemtap-toolkit#sample-bt 与
https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu