Multiple caching solutions for anonymous and logged in users with SSI on

Hi all,

I currently have a good caching solution for non-logged in users as
shown
below

location / {

proxy_pass http://localhost:82;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Accept-Encoding “”;

proxy_ignore_headers Set-Cookie;

proxy_ignore_headers Cache-Control;

proxy_ignore_headers Expires;

proxy_ignore_headers X-Accel-Expires;

proxy_no_cache $cookie_sessionid;

proxy_cache_bypass $cookie_sessionid;

proxy_cache cache;

proxy_cache_key $scheme$host$request_uri;

proxy_cache_valid 200 302 5m;

proxy_cache_valid 404 1m;

proxy_cache_use_stale updating;

}

But this is proving to be a lot of load when accessed by logged-in
users(with cookie). Typically situations like homepage (collection of a
lot
of snippets)

So in the same location directive, how can I apply an additional
caching
strategy with SSI on
(users name details which needs to be pulled up
every
time) for logged in users. Say cache pages for logged in users for a
minute
with caching for non logged in users at 15 minutes. I also want

proxy_cache_bypass $cookie_sessionid;

to refresh cache entries.

I believe this is scenario for a lot of websites out there.

Can someone help please?

-Quintin

Hi all,

I guess many people didn’t understand my question.

To make it simple, Can I have two caching strategies together:

one for logged in users and one for non-logged in users in the same
location directive?

-Quintin

On 5 Mar 2012 04h20 CET, [email protected] wrote:

Hi all,

I guess many people didn’t understand my question.

To make it simple, Can I have two caching strategies together:

one for logged in users and one for non-logged in users in the same
location directive?

I think that you need two locations for each batch of users. Define
two locations and use map to test for the session cookie. If Present
return a 418 and use error_page to redirect to the logged in users
setup.

You probably can do more “dynamic” things using the embedded Lua
module [1].

— appa

[1] http://wiki.nginx.org/HttpLuaModule

Thanks Antonio.

On a side note, if I craft a proxy cache key with cookie_sessionid and
if
the sessionid cookie does not exist, will nginx take it as an empty
value
?

Can nginx do a try_files or “if” on the existence of a cookie? This will
help me deliver two caching strategies in the same location directive.

-Quintin

Bird brain me :slight_smile:

What does this mean?

~SESS[[:alnum:]]+=(?<session_id>[[:graph:]]+) $session_id;

Also “if” is evil inside a location. Right ?

Thanks Antonio.

On a side note, if I craft a proxy cache key with cookie_sessionid and if
the sessionid cookie does not exist, will nginx take it as an empty
value
?

Sure. Here’s an example using map.

map $http_cookie $cache_id {
default nil; # hommage to Lisp :slight_smile:
~SESS[[:alnum:]]+=(?<session_id>[[:graph:]]+) $session_id;
}

When there’s no SESS cookie then $cache_id is nil.

Can nginx do a try_files or ‘if’ on the existence of a cookie? This
will
help me deliver two caching strategies in the same location directive.

Sure. Example. At the http level:

map $http_cookie $cookie_exists {
default 0;
~ 1;
}

On the “main” cache location:

error_page 418 @other-cache-location;

if ($cookie_exists) {
return 418;
}

Something of this kind will work.

–appa

Bird brain me :slight_smile:

What does this mean?

~SESS[[:alnum:]]+=(?<session_id>[[:graph:]]+) $session_id;

Also ‘if’ is evil inside a location. Right ?

Not really. Here it’s a mere return. From the famous IfIsEvil wiki page:

The only 100% safe things which may be done inside if in location
context
are:

return …;
rewrite … last;

On 05/03/2012 03:20, Quintin P. wrote:

I believe this is scenario for a lot of websites out there.

In theory GET is designed to be idempotent, therefore whilst it’s
desirable to customise pages per user, you quickly get tied in knots, as
here.

Can you
a) Make the URLs different for logged in and non logged in users? Then
the problem goes away. eg user sees site at http://profile/myname or
whatever

b) Use client side features to customise the page, ie write the username
to a cookie (sounds like it’s done already). Then use client side
javascript to customise the page for each request. In this way each
page is absolutely identical, any modifications are done client side.
Frequently it can be designed to fail gracefully in the case of disabled
javascript, etc

I think that whilst this has some compromises, if you can accept those
then you end up with a MUCH simpler application and simpler caching?

Good luck

Ed W

06 марта 2012, 14:02 от “Antonio P.P. Almeida” [email protected]:

~SESS[[:alnum:]]+=(?<session_id>[[:graph:]]+) $session_id;

map $http_cookie $cookie_exists {
}
What a load of… unnecessary directives! This does the job
much more efficiently and cleanly:

server {

    if ($cookie_sessionid) {
        rewrite ^ /logged_in$request_uri last;
    }

    location / {
        # Non-logged in clients
        #...
    }

    location /logged_in {
        # Logged in clients

        internal;

        proxy_cache_key $cookie_sessionid$scheme$host$request_uri;

        proxy_pass http://localhost:82/; # Note the trailing slash
        #...
    }
}

Max

06 марта 2012, 14:02 от “Antonio P.P. Almeida” [email protected]:

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