subrequest in limit_rate

Wu Bingzheng wubingzheng at 163.com
Mon Nov 1 12:40:59 MSK 2010


Hi all,
 
Does limit_rate, which is in write filter module, work right when many subrequests exist?
I meet a problem with limit_rate for many subrequests. Here is the problem.
 
1. limit_rate works like this:
a) after sending data, it will set wev->delayed which disable data sending, and sleep for a while(add_timer);
b) when timedout, the wev handler will clear wev->delayed, to enable data sending.
For example, the handler may like this;

src/http/ngx_http_upstream.c:ngx_http_upstream_process_downstream()

  2361    if (wev->timedout) {

  2363        if (wev->delayed) {

  2367            wev->delayed = 0;

  2389        }

  2395    }

 
2. but 1 wev (write event) corresponds to 1 connection; while 1 (downstream) connection may has many subrequests.
so when wev timedout, wev gets the active request of the connection, like this:
 

src/http/ngx_http_request.c:ngx_http_request_handler()

  1724    c = ev->data;

  1725    r = c->data;

  1726

  1733    if (ev->write) {

  1734        r->write_event_handler(r);

  1737    } else {

  1738        r->read_event_handler(r);

  1739    }

 

 

3. The problem is that: the active request of this connection maybe not the one who added the timer. which means that the active request of the connection changes before timedout. So its write_event_handler maybe not the one expected. For example, if the active request's write_event_handler is happened to be ngx_http_request_empty_handler(), which is set in ngx_http_core_content_phase(), then the handler doesn't clear the wev->delayed.So the data sending in write filter module will never be enabled again.

 

Is my analysis right? Does limit_rate work right for many subrequests?

 

I hope I made myself understood.

Thanks,

Wu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20101101/ba09d8e8/attachment.html>


More information about the nginx mailing list