On Wed, 2007-06-06 at 21:20 +0000, [EMAIL PROTECTED] wrote: > Malcolm: > > We have currently implemented a Middleware Hack to alter the > settings.SITE_ID > > The problem being that our project is serving more then 10 domain > names and we are aiming at about 1200 requests/second. We don't want > to hesitate when the load gets high, to through another App Server to > handle the traffic. > > I am wondering how this exactly affects the caching? Shouldn't the > caching be getting and setting based off of settings.SITE_ID? Your > post scares me and makes me want to dig through all the Django Caching > code to see how exactly it will break. Maybe we will be the first to > patch the breakage as it doesn't seem like it should break to me.
Remember that the word caching just means "storing for later use". It doesn't always mean HTTP caching, which is what I suspect you are talking about. There are many places in the code where a settings value is read and then some action taken and data stored somewhere based on that setting. For example, the list of installed apps (which is a setting) is used to populate the global app cache (once!) in django/db/models/loading.py. The USE_I18N setting is used to determine which translation functions to install -- we only do that once. Those are two I can think of off the top of my head; there are other instances, though. In short, I was using "cached" in the generic Comp Sci sense, not in the HTTP sense. Sorry for any confusion. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
