Nginx eval with memc set command very slowly

when use eval with memc set(all dev by agentzh ) ,I feel the response
is
very slowly,but get is very quickly,below is the configue

location /myset {
eval &var1{
set $memc_cmd ‘set’;
set $memc_key ‘test1’;
set $memc_flags 12345;
set $memc_exptime 24;
set $memc_value ‘my_value’;

      memc_pass 127.0.0.1:11211;
  }

}

does any one has meet this problem,any advice is welcome
thanks very much

On Mon, Mar 8, 2010 at 4:30 PM, yaoxinming [email protected] wrote:

when use eval with memc set(all dev by agentzh ) ,I feel the response is
very slowly,but get is very quickly,below is the configue

Which version of ngx_memc, ngx_eval, and memcached are you using? And
which OS?

Cheers,
-agentzh

On Tue, Mar 9, 2010 at 10:52 AM, agentzh [email protected] wrote:

On Mon, Mar 8, 2010 at 4:30 PM, yaoxinming [email protected] wrote:

when use eval with memc set(all dev by agentzh ) ,I feel the response is
very slowly,but get is very quickly,below is the configue

I’m guessing that it’s caused by the “201 Created” status returned by
the ngx_memc set command. According to the source of ngx_eval, it only
accepts “200 OK”. So in case of 201, it simply returns NGX_DECLINED,
which may produce that hang.

I’ve reproduced this hang on my side and spent half of my day tracking
this issue. But it looked deeper than I had expected.

Using subrequests issued by echo_location and echo_location_async does
not trigger this hang, but “eval” does. I’m now guessing it has
something to do with subrequests issued from the rewrite phase because
the ngx_echo module starts subrequests in content handlers only.

I don’t have enough time to track this further for now. Will get back
to this issue some time later. Sorry.

Cheers,
-agentzh

On Fri, Mar 12, 2010 at 11:05 AM, agentzh [email protected] wrote:

I’ve reproduced this hang on my side and spent half of my day tracking
this issue. But it looked deeper than I had expected.

Forgot to mention that the “post subrequest” handler does not get
called in this case. It seems ngx_http_upstream does not call
finalize_request. Most likely an issue in ngx_memc’s input filters.

If others can take a look at the ngx_http_memc_empty_filter_init and
ngx_http_memc_empty_filter functions in ngx_memc below, I’ll really
appreciate that:

http://github.com/agentzh/memc-nginx-module/blob/master/src/ngx_http_memc_response.rl

Thanks!
-agentzh

On Mon, Mar 8, 2010 at 4:30 PM, yaoxinming [email protected] wrote:

when use eval with memc set(all dev by agentzh ) ,I feel the response is
very slowly,but get is very quickly,below is the configue

I’m guessing that it’s caused by the “201 Created” status returned by
the ngx_memc set command. According to the source of ngx_eval, it only
accepts “200 OK”. So in case of 201, it simply returns NGX_DECLINED,
which may produce that hang.

I’m currently in the Hangzhou city and far from my laptop in Beijing.
So I can’t confirm this right now. I’ll look into this and hopefully
do a fix in my branch of ngx_eval if it’s indeed the case.

Thanks for the report!
-agentzh

On Fri, Mar 12, 2010 at 11:09 AM, agentzh [email protected] wrote:

On Fri, Mar 12, 2010 at 11:05 AM, agentzh [email protected] wrote:

I’ve reproduced this hang on my side and spent half of my day tracking
this issue. But it looked deeper than I had expected.

Forgot to mention that the “post subrequest” handler does not get
called in this case. It seems ngx_http_upstream does not call
finalize_request. Most likely an issue in ngx_memc’s input filters.

I’ve fixed this bug in ngx_memc v0.08:

http://wiki.nginx.org/NginxHttpMemcModule#v0.08

ngx_memc didn’t support subrequests in memory for memcached commands
other than “get” in earlier versions. Now it’s finally fixed by
setting r->upstream->buffer’s .pos and .last pointers properly in the
upstream input filters.

Also I’ve fixed a nasty bug in the discard_bufs function in my fork of
ngx_eval. It used to produce random hanging or segfaults when
eval_subrequest_in_memory was turned off.

Thanks!
-agentzh

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs