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 -~----------~----~----~----~------~----~------~--~---
