Lua handler between proxy_cache and proxy_pass

[RJoshi]

Hello,
i am using proxy_cache to serve cached response and proxy_pass to route the request to the upstream if not fond in the cache.
What Lua handler can be invoked in between which will allow me to look up response from external cache like coherence cache via resty.http?

Basically, I need ability to determine if request can be server from local cache or not before proxy_pass handler is executed.

Thanks,

[RJoshi]

Hi agentz,

 Can you please provide some input on this?  If there is no nginx/lua phase defined between proxy_cache and proxy_pass, I would like to implement that support.  Any suggestion/hint would be appreciated?

Thx

[Igor Clark]

Hi RJoshi,

Basically, I need ability to determine if request can be server from local cache or not before proxy_pass handler is executed.

Forgive me if I've misunderstandood, but it seems like you could do this with standard nginx proxy cache directives rather than anything lua-specific, maybe with something like this:

proxy_cache_path /var/www/cache levels=1:2 keys_zone=my_cache:10m;
upstream my_upstream {
    server x.x.x.x:yy;
}

server {
    location /my_location {
        proxy_cache my_cache;
        proxy_cache_key "$request_uri|$cookie_my_cookie_var"; # or whatever key you prefer
        proxy_pass http://my_upstream/my_proxy_path;
    }
}

If the response is available in the local cache, it'll just serve it from there, and if not, it'll automatically pull it down from the upstream.

If you want to make any more complex decisions about whether to serve from cache - e.g. if you want to check the coherence cache before the local cache, maybe just for specific locations, or maybe override the local cache decision based on what coherence tells you - then you could set an ngx.var to control proxy_cache_bypass, which " Defines conditions under which the response will not be taken from a cache. If at least one value of the string parameters is not empty and is not equal to “0” then the response will not be taken from the cache:"

If that's what you want to do, something along these lines might work:

location /my_location {

    set $bypass_cache 0; # try local cache by default

    rewrite_by_lua_block {

        if coherence_has_response() then
            # bypass local cache and retrieve from upstream, maybe coherence, or wherever
            ngx.var.bypass_cache = 1
        else
            # try to serve the content from local cache first, before triggering an upstream request
            ngx.var.bypass_cache = 0
        end
    }

    proxy_cache my_cache;
    proxy_cache_key "$request_uri|$cookie_my_cookie_var"; # or whatever key you prefer
    proxy_pass http://my_upstream/my_proxy_path;
    proxy_cache_bypass $bypass_cache;
}

NB I haven't tested that exact code, but it's all taken from things I do that definitely work.

Hope that's of some use,
Igor

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[RJoshi]

Thanks Igor.  I have tried both these suggested solutions but did not know that  proxy_passallow internal redirection to the location as you mentioned in your example. 

proxy_pass http://my_upstream. 

I thought URI in proxy_pass must be  HTTP URI with host/port e.g http://127.0.0.1/my_upstream which has a overhead of constructing new request/response + utilizing additional two connections.

[Igor Clark]

Hi Rohit,

I'm not quite sure what you mean about the "internal redirection" or "additional two connections"?

'my_upstream' is just a normal 'upstream' definition - it lets you define/declare TCP and unix socket servers you want to use elsewhere.

You can certainly minimize connection setup/teardown overhead, and re-use existing connections, using the 'keepalive' option in the 'upstream' definition, as per the example in the docs:

upstream memcached_backend {
    server 127.0.0.1:11211;
    server 10.0.0.2:11211;

    keepalive 32;
}

upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

This will keep 32 memcached and 16 HTTP upstream connections running, which you can then access in your nginx config - and, IIUC, any *_by_lua* directives where the socket API is not disabled.

HTH,
Igor

[RJoshi]

Internal redirection mean nginx invoked location as a internal function call rather than going over tcp/socket.

additional two connections:  When request is sent using proxy_pass using tcp, it would be using one client socket port and one for upstream server.

I like the idea of utilizing upstream connection pool which will make it efficient. thx