nginx output flow control

eran.kornblau · 2015-06-03T21:18:22+00:00

Hello! On Tue, Jun 2, 2015 at 9:36 PM, rvsw wrote: > I need to access the value of one of the variables (part of response body) > that I set in lua du...

nginx output flow control

eran.kornblau

Hi,

Hope you can provide me some guidance on this one -

I'm working on a native nginx module that is generating some output, and I would like to add some kind of "flow control" to it, meaning -
if the client is not reading the data fast enough, I would like to postpone the creation of new buffers in order to avoid using too much

memory on the nginx server.

My questions are:

1. Is there a way to know how much data is currently waiting to be sent ? or alternatively, if there's a way to know how much

data was sent, I can do <total size I passed to nginx so var> - <total size sent to the client>

2. Is there a way to be notified when data is sent ? (required so that I can re-initiate the generation of buffers as the queue size decreases)

Also, on a slightly different subject - when a buffer is sent (by calling ngx_http_output_filter) does nginx free it after it finishes sending it
to the client ? is there some flag on the buffer that controls this behavior (temporary, recycled, etc.) ?

Thank you,

Eran

eran.kornblau

Ok, I believe I found the answers to all my questions above, this thread has most of the info: http://forum.nginx.org/read.php?29,223517,223517#msg-223517.

I took the approach that is explained there for buffer reuse and set a limit to the number of buffers my module allocates.

Only part that was missing from that thread is how to get a notification when more data can be sent, the solution I found for this
(don't know if that's the "correct" solution by the book) was to register my module as a body filter module (in addition to being a
content handler module).

When more data can be sent, the event module (epoll in my case) calls ngx_http_request_handler which in turn calls ngx_http_writer.

This function does ngx_http_output_filter(r, NULL); which basically notifies the whole body filters chain.

A different solution could have been to change r->write_event_handler, but since this function is used internally by nginx as well,
it sounds like a riskier solution.

Eran

On Wednesday, June 3, 2015 at 4:18:22 PM UTC+3, erankor wrote:

Hi,

Hope you can provide me some guidance on this one -
I'm working on a native nginx module that is generating some output, and I would like to add some kind of "flow control" to it, meaning -
if the client is not reading the data fast enough, I would like to postpone the creation of new buffers in order to avoid using too much
memory on the nginx server.

My questions are:
1. Is there a way to know how much data is currently waiting to be sent ? or alternatively, if there's a way to know how much
data was sent, I can do <total size I passed to nginx so var> - <total size sent to the client>
2. Is there a way to be notified when data is sent ? (required so that I can re-initiate the generation of buffers as the queue size decreases)

Also, on a slightly different subject - when a buffer is sent (by calling ngx_http_output_filter) does nginx free it after it finishes sending it
to the client ? is there some flag on the buffer that controls this behavior (temporary, recycled, etc.) ?

Thank you,

Eran

agentzh

Hello!

On Sat, Jun 6, 2015 at 2:31 AM, erankor wrote:
> I took the approach that is explained there for buffer reuse and set a limit
> to the number of buffers my module allocates.

Yes, sure.

> Only part that was missing from that thread is how to get a notification
> when more data can be sent,

Hook your own handler to r->write_event_handler. You get notifications
in terms of "write events", for obvious reasons :)

> the solution I found for this
> (don't know if that's the "correct" solution by the book) was to register my
> module as a body filter module (in addition to being a
> content handler module).

Invoking body filter is just a way to force lower-level filters (like
ngx_http_write_filter) to flush buffered data that was not possible to
send to the system socket send buffers in the previous run (or cycle).

> When more data can be sent, the event module (epoll in my case) calls
> ngx_http_request_handler which in turn calls ngx_http_writer.

When ngx_http_writer gets involved, the request is already finalised,
that is, a bit too late :) Well, it's async writing. In your case, you
need *sync* writing (still nonblocking + multiplexed I/O, of course).

> This function does ngx_http_output_filter(r, NULL); which basically notifies
> the whole body filters chain.

Yes. But you should only call this when you actually run out of your
own buffers. After calling this (and other variants of
ngx_http_output_filter calls), you should always call
ngx_chain_update_chains to update the state of your buffers.

> A different solution could have been to change r->write_event_handler,
> but
> since this function is used internally by nginx as well,
> it sounds like a riskier solution.
>

Not at all. This hook is *supposed* to be overridden by modules. And
you should do this in your case. No risk at all.

BTW, you can take a look at how the ngx_lua module schedules things in
a synchronous but still nonblocking fashion. Or maybe better, just use
ngx_lua for your scenarios instead of hacking on your own nginx C
modules from scratch.

Just my 2 cents.

Best regards,
-agentzh