Server software choice for Django live/staging_问答_开发者

For developing our Django web app, I'd like to move to an autonomous system that automatically updates the source (from VCS) of a staging copy of the app which has near identical properties to the live version of the application. The general idea of doing t开发者_开发技巧his has already been covered here on SO #625256. The Django documentation also talks about setting up virtual hosts to host 2 instances of Django on the same Apache. Many of the pieces I need to set this up are already in place.

What my question specifically -- What server software should I choose if this setup will be running under Windows Server 2000?

Apache+mod-wsgi seems like the natural choice, but according to this blog post by Graham Dumpleton mog-wsgi on Apache running on Windows can't reload it's individual process and needs to restart the whole Apache service. This is a no-go as I don't want the live site dropping out whenever we update the staging's code.

What is the best choice of server software for this situation?

Maintain 2 copies of Apache which can be independently restarted (this feels bad)?
Migrate to something other than Apache?
???

There are no 'individual processes' on Windows when using Apache, there is only one Apache worker process. Also, there is no daemon mode on Windows either. Anyway, what it all means is that both Django instances do run in the one process, albeit in different sub interpreters. So yes, to cause code for one Django site to be reloaded will have impacts on the other site because of them being in the same process.

If one was on a UNIX system one could send a kill signal to the worker/daemon processes and they would restart without restart whole of Apache. On UNIX this does not overly cause problems even when multiple sites in same process as the listener socket for port on which HTTP requests are accepted is maintained open at all times, so subsequent requests which arrive during the restart just queue up and will be handled once worker/daemon processes are running again.

On Windows as you rightly pick up the whole of Apache has to be restarted. This means that for ever so small a time that listener socket will be closed off and there will be a small window where requests will get a connection failed. How long a window this is you will really need to do some testing on. Usually it isn't a huge problem as is short enough that low probability that request will hit at that precise moment. In other words, you may be unduly worrying if you are only talking about a staging environment given that wouldn't expect to restart very often. If you were trying to run a development site on same Apache instance then that would be a problem.

That all said, if you want the staging instance to be as close as possible to production then would still need to be running Apache so multiple Apache instances on different ports would be only logical solution. You could run Django on top of CherryPy WSGI server or Paste WSGI server and proxy to it, but then it is a different hosting system and will behave differently to the extent that you may not pick up issues which would ultimately occur when on production setup.

All up, I would suggest you actually do some tests where you run benchmarks against Apache and perform a restart at same time and see how many requests fail as a result. This will help you understanding whether it is the big problem you think it is.

Django sessions are, by default, persistent and database backed. Restarting the webserver does not interrupt the session; when the server comes back up the user will proceed as before. After a restart the session key is presented by the cookie, the database recalls the session variables, and we proceed uninterrupted.

http://docs.djangoproject.com/en/dev/topics/http/sessions/

If you're worried about hijacked sessions then reduce the expiry time, destory the cookie with browser close, and routinely clear expired sessions from the database.

At least that's how I read it.

I'd stick to the most common implementation simply because that will expose you to the most support. I expect that is apache+mod_wsgi on unix. Two out of three will have to do. Obviously staging and production connect to the same database.

You get my interest because I'm considering establishing a 'staging' deployment under another domainname so after we get the alternate all tested and ready then we simply swap the "servername" variable in the apache conf to go-live. With a graceful restart I'm hoping it would be unnoticeable to users... excepting all the new features suddenly appearing :-)