On Apr 25, 2013, at 11:38 AM, Wins Lin wrote: > 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?
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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
