On 11/1/07, 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?
Sessions aren't created unless you modify a v
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 theref
Sorry for the mistake. This should read:
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
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 det
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 begi
Joe napisał(a):
> I tried to look at caching querysets, but this won't work because they
> are lazy.
Do a list() on query set and cache the resulting list.
> If I use fragment caching, would that save hits on the database
> because of the lazy querysets?
Entire fragments (rendered content) wil
6 matches
Mail list logo
