Sorry, meant to NOT vary on the value of the cookie header. On Nov 1, 11:39 am, Joe <[EMAIL PROTECTED]> wrote: > Correct me if I'm wrong, but wouldn't this place more load on the > server to to this, as an anonymous user visiting the site for the > first time would start a new session, and therefore bypass the cache? > > Is there a way I could hack the middleware to look at something > besides the HTTP headers to determine caching? > > My main question is this: If I changed the templates so there was only > two versions (one for authenticated users that said log out, and one > for anonymous users that said log in, how could I get the cache > middleware to vary on request.user.is_authenticated, and the value of > the cookie header? > > On Oct 30, 10:50 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > On Tue, 2007-10-30 at 05:43 -0700, Joe wrote: > > > I am running into a performace problem with Django and scaling. > > > > I have enabled the caching middleware, but had to set > > > CACHE_MIDDLEWARE_ANONYMOUS_ONLY=True so I could continue to use the > > > admin interface. > > > > Now, authenticated users are beginning to put a noticeable load on the > > > server. > > > > How do I implement caching on my normal views for authenticated > > > users? I can't just use the decorator because I have a "Hello, > > > Username" message on the page. > > > I keep meaning to look at this further, because I'm sure that if we work > > it out properly, CACHE_MIDDLEWARE_ANONYMOUS_ONLY shouldn't be necessary. > > So what I'm saying here is based on no testing, but it will take you two > > minutes to try out and see. > > > There's a middleware ordering problem here: if you're using > > CACHE_MIDDLEWARE_ANONYMOUS_ONLY, you need to have the session middleware > > come *before* the cache middleware in the middleware ordering. This is > > so that on the request path, we already know if the user is anonymous > > before attempting to hit the cache. > > > If you turn off CACHE_MIDDLEWARE_ANONYMOUS_ONLY, you should put the > > session middleware *after* the cache middleware. This is because the > > important path here is the response path: the session middleware sets > > the Vary: Cookie header and so the cache middleware knows to use that to > > generate the cache key. > > > So, just flipping the anonymous caching setting isn't all you need to do > > in this case. You also need to move the SessionMiddleware. Put it after > > CacheMiddleware in MIDDLEWARE_CLASSES and see if that improves things. > > This might not solve all your problems in one swing, since it will > > generate a new cache key for every session cookie. So if you are getting > > lots of different users, you'll eventually toss old entries out from the > > cache and have to regenerate them. > > > What we need to do, longer-term is solve the problem of how to split > > request ordering and response ordering for middleware (and this list > > isn't the place for that discussion) so that we can have something on > > the request path to say "all anonymous users should be treated the > > same", whilst letting the session middleware have the chance to set the > > "Vary: Cookie" header before it gets to the cache middleware so that > > authenticated users are cached properly. Right now, we can't do both. > > It'll be fixed one day. > > > Regards, > > Malcolm > > > -- > > How many of you believe in telekinesis? Raise my > > hand...http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
