why does replace_filter not use ngx_chain_update_chains

rvsw · 2014-05-08T23:07:46+00:00

Hello! On Wed, May 7, 2014 at 3:12 AM, monsif20 wrote: > My issue is i want execute perl script before exectuting a git-http-backend > script , i us...

why does replace_filter not use ngx_chain_update_chains

rvsw

Hello agentzh

I have been trying to understand the replace_filter code. It seems to follow the general outline of an output_filter. However, in the ngx_http_replace_output routine, we seem to take a different path as compared to say ,ngx_http_lua_body_filter. In both cases, we have finished the processing of the buffer and called the next filter in line. However, in case of ngx_http_lua_body_filter, we call ngx_chain_update_chains. In the case of replace_filter, we don't call it. Though we do something similar in the sense we assign the chain output buffers to the chain of busy buffers and free any bufs that are not marked with the replace_filter tag.

I did not understand the reason for it. I sometimes see a slow client not able to get data (it gets around 64K data for a > 100K file). Nginx sends a zero TCP window upstream and so does not get data to send to the client. There are other filters in the play also e.g. gzip but it seems you have resolved that bug as detailed at http://forum.nginx.org/read.php?29,244138,244138#msg-244138. I am not able to isolate the issue to any individual filter. It happens when multiple filters are involved.

Any insights will be useful

Thanks

agentzh

Hello!

On Thu, May 8, 2014 at 8:07 AM, rvsw wrote:
> I have been trying to understand the replace_filter code. It seems to follow
> the general outline of an output_filter. However, in the
> ngx_http_replace_output routine, we seem to take a different path as
> compared to say ,ngx_http_lua_body_filter. In both cases, we have finished
> the processing of the buffer and called the next filter in line. However, in
> case of ngx_http_lua_body_filter, we call ngx_chain_update_chains. In the
> case of replace_filter, we don't call it. Though we do something similar in
> the sense we assign the chain output buffers to the chain of busy buffers
> and free any bufs that are not marked with the replace_filter tag.
>

We essentially duplicate the logic of ngx_chain_update_chains (with
our own optimizations) in ngx_replace_filter, see:

    https://github.com/openresty/replace-filter-nginx-module/blob/master/src/ngx_http_replace_filter_module.c#L593

Because the in-stock ngx_chain_update_chains does not fit our needs.

> I did not understand the reason for it. I sometimes see a slow client not
> able to get data (it gets around 64K data for a > 100K file). Nginx sends a
> zero TCP window upstream and so does not get data to send to the client.

Please do not correlate the problem you have with the way
ngx_replace_filter is doing things so soon. To be sure, we definitely
need more details to analyze.

One suggestion is try to create an isolated minimal example that can
reproduce the issue on my side.

Another suggestion is to do dynamic tracing with tools like systemtap
and dtrace.

Finally, you can review ngx_replace_filter's test suite and check if
there is any special code path or case that has never been carefully
exercised.

> There are other filters in the play also e.g. gzip but it seems you have
> resolved that bug as detailed at
> http://forum.nginx.org/read.php?29,244138,244138#msg-244138. I am not able
> to isolate the issue to any individual filter. It happens when multiple
> filters are involved.
>

BTW, Mozilla's rr recording and replaying tool might be helpful for
analyzing this:

    http://rr-project.org/

It is i386 only at this point, but you can rebuild nginx with -m32 on
x86_64 and use rr anyway.

Regards,
-agentzh