Thanks Joseph. Middleware is very useful.
--- On Mon 06/04, Joseph Heck < [EMAIL PROTECTED] > wrote: From: Joseph Heck [mailto: [EMAIL PROTECTED] To: django-users@googlegroups.com Date: Mon, 4 Jun 2007 09:41:29 -0700 Subject: Re: Big app, big db, all users are authenticated Another thing to keep an eye out for is referencing one model fromanother - when loading up the choices for something that has > 1000possible associated objects, then system will take a while to pull allthose into place. Setting "raw_admin_id" in the model will helpalleviate this, but you loose some additional functionality as aconsequence.Fundamentally, look at your queries to see how what's going on andtaking time. Maybe just a few indexes are needed, or it might help youidentify a coding mistake.I frequently use the middleware snippet athttp://www.djangosnippets.org/snippets/264/ to assist here (had aproblem with our sitemap setup over the weekend I diagnosed withthat). I didn't create that middleware originally - found it on thislist. Sorry I can't tell you who created it originally.-joeOn 6/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:>> Hi,>> On Jun 4, 3:48 pm, "and_ltsk" <[EMAIL PROTECTED]> wrote:> > 1. 100MB per request - is it normal?>> not likely. I have apache processes serving a couple of different> sites within separate python interpreters and they are all somewhere> in the 10-30MB memory range.>> Common gotcha: make sure you have DEBUG set to False, otherwise Django> stores all executed SQL queries in memory.>> > 2. I can't use cache because one user receives cached response for another user. Did you know any solution for authenticated cache?>> You can set up caching per-session, look for "vary_on_headers" and> "Cookie" in the cache documentation. But that greatly increases the> cache size, of course.>> I prefer to cache template fragments, see http://code.djangoproject.com/ticket/1065> -- this way the parts that don't depend on logged-in user can be> cached only once for the whole site and I still can cache fragments> per-session.>> > 3. While any table growing, the responses became slower to 2-10 minutes. How to avoid the big dicts or use another another solution?>> Make sure you have indexes in the database. Also, check your> templates and code for "if big_queryset" instead of "if> big_queryset.count" -- the former pulls all the data from the> queryset, the latter does not.>> > For any performance tip thanks in advance.>> Point 3. looks like a hint there is something wrong with the way you> pull data from the database. Look into the queries, perhaps there is> a large number of them or some of the queries download too much data.>> -mk>>>> >> _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
