2009/12/21 David De La Harpe Golden <david.delaharpe.gol...@ichec.ie>
> On Thu, Dec 17, 2009 at 03:54:02PM -0200, Victor Loureiro Lima wrote: > > Okay, let me further explain my problem... > > > > My website depends heavilly on the caching system, I'm using cache_page > to > > cache my view ( using memcached backend ), > > however I have the "Hello, <logged in user>" on top of every page when > the > > user is logged, thus I cant just cache everything. > > Well, there is (now) a mechanism in place for caching template fragments. > So I suppose you could cache everything but the hello... I haven't tried to > use > caching in such fine-grained fashion though: > > > http://docs.djangoproject.com/en/dev/topics/cache/#template-fragment-caching > Well, template caching invalidates view cache right? Plus, my understanding of the template cache is that it will hit my view, do all the DB stuff, but skip the template processing which takes a while to finish, is my understanding right? > > > as a side note, I had to apply a patch to > > django, in order for it to ignore certain cookie name regexp's > > Dirty, but if you're already mangling the django cache code to vary > on a subset of cookies rather than the standardised behaviour of varying > on all cookies (since it's really varying on the "Cookie" HTTP header), you > could > probably further mangle it to vary only on a custom cookie other than > the django session cookie. I don't think this is a good approach, just > saying. > Well, we use google analytics on all pages, and the analytics cookie changes very often, for the same user, thus it would generate another cache just because analytics cookie changed, and thats not what I want, I want one cache per session ID cookie, only... that why we followed that approach... And I know that patching django sucks a lot, but we couldnt live with the 5 requests/second that the non-cached django app was doing under heavy load. > > > That solved my problem, using @vary_on_cookie on my views, now I solved > my > > caching issues, however I noticed that whenever a user logs out, I > recieve a > > new sessionid, thus if the user log's in I will create a cache for him, > > based on its session id. But when it logs off, instead of joining the > other > > clients that dont have the sessionid, it will become another "cached > > instance", and I have to avoid that situation. > > How about clients that have a sessionid before login? Clients that dont have the session ID will all hit the same cache. > you may be assuming clients don't have a session cookie before they login? Clients that never logged in will not have the session ID cookie. Clients that have logged in, will have the session ID cookie set for the web-browser session ( cookie is set to exist while the browser is opened ). > That may wind up true in your case I guess, but n.b. don't think > that login creates sessions in general - it may "bless" an existing > anonymous session with data in it into ownership by the logger-in (except > when the existing > session is already owned by someone logged in, then it is replaced for > security). > > > http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L65 > > This is a feature - consider user starting filling out a form anonymously, > data > being stashed in the session, then user logs in to authorise doing > something (posting comment, say). > yes, in that case that would really be a problem... Maybe we could circunvent using our navigation scheme to avoid that scenario, but that would really be a bust in our designs... In your opinion, what would be the correct approach? Cache the views objects instead of the view it self, and cache some of the templating? That would avoid the vary_on_cookie and would had a more granular effect on the system. Atenciosamente, Victor Lima > -- > > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
