Yes I am using Django
> Can you explain better what happens for that 1 request in 5000?
>
I get a 404 notification via Django's admin 404/500 error email
service that a URL is broken. However, that URL is 100% fine when I
try it myself. I realized after tons of debugging output that the
worker server for example1.com was using at least 2 things from
example2.com's settings: a custom setting in settings.py SITE_NAME =
'example2.com' and also example2.com's database connection. I output
all the request['META'] information and sure enough everything lined
up with the server thinking this was an example2.com request, but it
was actually to the example1.com virtual host.
By the way, it may have been more often than 1/5000 - after posting it
seemed to slowly increase, perhaps getting to 1/1000 or 1/500. It was
hard to get a precise number.
> When you say 'settings' module, do you mean you are using Django? Can
> you post the WSGI script file being used.
Here are the WSGI scripts:
import os, sys
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings.example1.live'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
import os, sys
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings.example2.live'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
>
> Do you set any other environment variables, ie., assign to os.environ,
> in WSGI script file, or know of any which are being set at request
> time anywhere in your application code, or third party modules you may
> use?
>
No environment variables that I am aware of. As I mentioned there is
the SITE_NAME variable in the Django settings.py module, and there is
also two python-path entries in the WSGIDaemonProcess line in the
originally posted apache configuration.
> I'll explain better later when have a chance, but there are issues
> with Python and multiple sub interpreters in respect of environment
> variable leakage, but if the only os.environ variable being set was
> DJANGO_SETTINGS_MODULE, it wouldn't usually present as a problem.
>
> That said, I have heard a couple of times of strange mixing still
> occurring whereby using distinct daemon processes for each instance
> solved the problem.
I used to have separate DaemonProcessGroup lines for each virtual
host. I decided to merge them (since I'd done it in testing and it
worked fine) to allow processes to be shared (I figured this would
provide better ability to absorb traffic spikes on an individual
website, that kind of thing). At that time there were no problems. I
am fairly certain that merging them caused the problem, but my logging
at that point was not good enough so I cannot get a precise time to
correlate with the change in settings.
Furthermore, I have since added WSGIApplicationGroup %{SERVER} to each
virtual host, and it has magically stopped all the problems. After
100,000+ requests there have been zero problems.
>
> If you have time, would like to try and dig deeper into this and try
> and work out this time what might be happening. For some background
> reading on environment variable leakage, look at:
>
> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_E...
I read through the environment variable section, and skimmed the rest
of the page. I don't think any of it applies to my situation, but it
was interesting!
>
> I'll explain later again though why this shouldn't be an issue for
> DJANGO_SETTINGS_MODULE.
>
> BTW, the 'SetEnvIf X_FORWARDED_PROTO https HTTPS 1' sounds like you
> are fronting by another web server and trying to detect whether
> fronting web server was using HTTPS. Yes/No? We were discussing that
> recently for nginx in:
>
Yup, that's what I'm doing. Seems to work like a charm, we've never
had a problem thus far. The load balancer has this:
RequestHeader set X_FORWARDED_PROTO 'https'
as well.
> http://groups.google.com/group/modwsgi/browse_frm/thread/94f952720c87...
>
Unfortunately I don't have the time to read through that at the
moment, but so far the SSL part seems to be incidental to this
situation.
As I mentioned above the WSGIApplicationGroup %{SERVER} setting seems
to have cured everything, so what I'm curious to know is, what did
that change? Isn't the default setting almost identical?
If this will help, there are actually 4 total websites spread across 4
worker servers (these are meant to spread the load and at the same
time provide redundancy, that's why there isn't one server per
website) and then two load balancers using heartbeat to enhance uptime
providing load balancing and also any SSL processing (which is fairly
small at the moment). Finally there is a separate dedicated database
server group. They all use the same group, but a different database
instance each. All software involved is from the debian lenny
distribution, and Django latest svn (except for a one line patch on
the contrib.admin code). One of the websites gets at least 60,000
visitors per day, another 30,000, another 5,000, and the final one
almost zero. All four websites have identical settings/wsgi scripts/
etc as posted and discussed here, it just seemed redundant to include
them. I can guarantee they are all appropriately different though,
they are automatically generated and checked very thoroughly.
Please let me know if I can provide more information, and thanks for
your thoughtful response,
Henry
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---
