Forum: Ruby on Rails What are "pages that require authentication" and why they cannot be cached?

1ac774797c9e79861840599b23653c3c?d=identicon&s=25 Wins Lin (zvooq)
on 2013-04-25 16:37
I don't understand what is meant in Rails Guide about caching:

>> Unfortunately, it can't be applied to every situation
>> (such as pages that need authentication) and since the webserver is literally
>> just serving a file from the filesystem, cache expiration is an issue
>> that needs to be dealt with.

What are "pages that require authentication"? Are they just the pages
with a form for authentication? Like the main page of facebook.com when
you are not logged in? Then why is it impossible to cache it? It is the
best page for caching because it is always the same, it has only the
html-form. Unlike the profile page that has a lot of fields that are
changed very frequently.
A47e0a6beeb9d048ff054fc1c3a97418?d=identicon&s=25 Walter Davis (walterdavis)
on 2013-04-25 16:59
(Received via mailing list)
On Apr 25, 2013, at 10:37 AM, Wins Lin wrote:

> best page for caching because it is always the same, it has only the
> html-form. Unlike the profile page that has a lot of fields that are
> changed very frequently.

No, it would be any page containing unique content meant for that user's
eyes only. You can't cache them because they are bound to the current
user's session -- you can only cache things that are meant for everyone
to see. No filtering or special content-creation can be going on in any
part of cached content. Now you can use what 37Signals refers to as
"Russian Doll" cacheing to cache parts of the page that are held in
common, while letting other parts be dynamically generated. It's a
yes-and sort of thing. But if you are after a win by caching the entire
page, then it has to be essentially a static page -- same for everyone
who views it.

Walter
1ac774797c9e79861840599b23653c3c?d=identicon&s=25 Wins Lin (zvooq)
on 2013-04-25 17:38
Walter Davis wrote in post #1106898:
> On Apr 25, 2013, at 10:37 AM, Wins Lin wrote:
>
> No, it would be any page containing unique content meant for that user's
> eyes only. You can't cache them because they are bound to the current
> user's session -- you can only cache things that are meant for everyone
> to see. No filtering or special content-creation can be going on in any
> part of cached content. Now you can use what 37Signals refers to as
> "Russian Doll" cacheing to cache parts of the page that are held in
> common, while letting other parts be dynamically generated. It's a
> yes-and sort of thing. But if you are after a win by caching the entire
> page, then it has to be essentially a static page -- same for everyone
> who views it.
>
> Walter

Thank you. Now I begin to understand the difference. But then I have
such a question. Why not to cache user's specific pages? Every user's
session has a session_id. So let it be also an id for cached content of
that particular user. Or is it cumbersome for storage to track the
content for thousand of users?
50bdc8b42649a550f6cb600204041e67?d=identicon&s=25 henrique matias (Guest)
on 2013-04-25 18:14
(Received via mailing list)
Hey have a look on some screencasts on youtube and railscasts:
http://www.youtube.com/watch?v=UnhHZJiSrSc

They'll completely explain everything you need, rails is able to do what
you want to do, you just need to learn how to do it.

peace,
A47e0a6beeb9d048ff054fc1c3a97418?d=identicon&s=25 Walter Davis (walterdavis)
on 2013-04-25 18:22
(Received via mailing list)
On Apr 25, 2013, at 11:38 AM, Wins Lin wrote:

>> yes-and sort of thing. But if you are after a win by caching the entire
>> page, then it has to be essentially a static page -- same for everyone
>> who views it.
>>
>> Walter
>
> Thank you. Now I begin to understand the difference. But then I have
> such a question. Why not to cache user's specific pages? Every user's
> session has a session_id. So let it be also an id for cached content of
> that particular user. Or is it cumbersome for storage to track the
> content for thousand of users?

You are certainly free to try this out, but I suspect that the trade-off
will be speed of retrieval from storage versus speed of generating the
content dynamically. Yes, I am sure you _can_ do this, but I'm not
convinced you _should_. The reason to cache is to divide the number of
visits to an asset over the lifespan of that asset, and thus distribute
the cost of generating it over a large number of views of the same
thing. If you had a "message of the day", that would definitely benefit
from being cached. In the case of a dynamically-generated page unique to
a certain user, that lifespan is usually the life of the page-view
itself, not the application or the day. Your application is unique, of
course, but you should think about the price you would pay to cache
something that will only be viewed once or twice.

Walter
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.