what is the underlying infrastructure Django uses to handle its requests?
did it use thread, can someone give some reference on this ?
Django is not a web server. It is a web framework. The behavior of how it is being run as an application is dependant on your method for serving it.
It could be threaded requests. It could be processes. It could even be async.
Serving Files
Django doesn't serve files itself; it leaves that job to whichever Web server you choose.
Wsgi is the most common way to serve django right now, so really you should just investigate the configuration options of different wsgi implementations.
If you get random segmentation faults when using manage.py runserver because some underlying C libraries you have to use in your project are not thread-safe, try
manage.py runserver --nothreading
instead.
For production services that run wsgi with tools like mod_wsgi, there is usually an option to disable threading. In this case
WSGIDaemonProcess example processes=5 threads=1
See https://modwsgi.readthedocs.io/en/develop/user-guides/processes-and-threading.html
Related
The question is in the title.
I need to deploy a Django application in a local network (i still don't know how to do but i suppose it's quite easy) but i still need to develop it. My question is how to do to allow users to use the application while i'm still developing it ?
Is it a solution to keep to versions of the application, one deployed and one in development ? In this way, I can replace the application deployed by the newly developed one when I finish coding it.
Another question concerns the database, can I still modify the database if I just add new models without touching existing ones ?
Thank you in advance,
This is a good blog entry that covers deploying Django using Heroku. I'll give you a quick rundown of what makes all the different technologies important:
Git
Git, or any other version control system, is certainly not required. Why it lends itself to deploying Django projects is that your usually distributing your application by source, i.e. your not compiling it or packaging it as an egg. Usually you'll organize your Git repository as such that updating your application on the server only requires you to do a checkout of the latest sources--nothing else.
virtualenv and pip
This, again, is not a strict requirement, but I'd strongly suggest you take the time to familiarize yourself with virtualenv and pip if you already haven't done so, since it's going to make deploying your Python applications across different runtime environments, local or remote, a breeze.
Basically, your project will need to have at least Django and Gunicorn available on the Python path, possibly even a database driver. What that means is that every time you try to deploy your application somewhere you'll have to install Python and do the easy_install dance all over.
virtualenv will redistribute a Python installation, which in turn means that the new Python instance will, by default, have it's very own Python path configuration relative to the installation. pip is like easy_install on steroids, since it supports checking out Python dependencies directly from code repositories and supports a requirements file format with which you can install and configure all of your dependencies in one fell swoop.
With virtualenv and pip, all you'd need to do is have a simple text file with all your dependencies that can be parsed with pip and an installed Python distribution on the machine. From there you just do git checkout repo /app/path; easy_install virtualenv; virtualenv /app/path; ./app/path/scripts/activate; pip install -r /app/path/requirements.txt. Voila, Gunicorn, Django and all other dependencies are then installed and available immediately. When you run the Gunicorn Django script with the Python instance in /app/path/scripts, then the script will immediately have access to the Gunicorn sources and it will be able to locate your Django project which will have access to Django and other dependencies as well.
Gunicorn
This is the actual Python application that will manage your Django instance and provide an HTTP interface that exposes it to HTTP clients. It'll start several worker processes which will all be distinct Python virtual machines loaded with the sources of your application and it's dependencies. The main Gunicorn process will in turn take charge of managing which worker processes manage which requests for maximum throughput.
The basic principle of wiring Nginx and Gunicorn
The most important thing to observe is that Nginx and Gunicorn are separate processes that you manage independently.
The Nginx Web server will be publicly exposed, i.e. it will be directly accessible over the internet. For requests to static media, such as actual images, CSS stylesheets, JavaScript sources and PDF files accessible via the filesystem, Nginx will take charge of returning them in the response body to HTTP clients if you configure it to look for files on the path where you configured your project to collect static media.
Any other request should be proxied to your Gunicorn instance. It will be configured to listen to HTTP requests on a certain port on the loopback interface, so you'll using Nginx as a revers proxy to http://127.0.0.1:8080 for requests to your Django instance.
This is the basic rundown for deploying your Django projects into production that should satisfy the needs of 95% Django projects running out there. While I did reference Nginx and Gunicorn, it's the usual approach when it comes to setting up any Web server to act as a reverse-proxy to a Python WSGI server.
I have been developing an application in Django. The production version of the app is running on an Apache server in a unix system. In order to get my app to play nicely with over applications running on the server, I had to create a WSGIScriptAlias (so on the production server www.example.com/home became www.example.com/alias/home). This change initially broke a few links and AJAX calls where the urls were a little too hard coded, but I think I've weeded out those issues.
However, for testing purposes and so that my development environment more closely reflects the production system, I would like to be able to alias the dev server as well. Is there any way to do this short of setting up an apache on my dev machine as well? manage.py runserver 0.0.0.0:8000/alias does not seem to work.
I have recently switched to Django for a web app I'm developing and I followed the instructions at Heroku for getting a Django app running on Heroku. I have a virtual environment in which my app is developed and I use git for version control and to push to Heroku. The link above suggests that I intall gunicorn:
The examples above used the default HTTP server for Django. For
production apps, you may wish to use a more production-ready embedded
webserver, such as Tornado, gevent’s WSGI server, or Gunicorn.
They then walk the user through installing Gunicorn.
My question is: what problems might I run into if I skip this step and just stay with the default? What benefits will Gunicorn give me?
Gunicorn is production ready and really easy to use. I use it for my websites. You usually should run it via a reverse proxy like Nginx. I'm not sure what Heroku is using. You really should try it.
In my experience it's much easier to use and configure than apache & mod_wsgi, and the other similar setups.
edit/update:
As a summary of the comments below, Heroku already uses Nginx as a reverse proxy
Much better performance, and probably better security and stability, too. Django's development web server (which is used by Heroku by default) isn't really designed to serve production applications.
django's server, is a development server . It is light weigh and easy to use but should not be used in production because it is not production ready. it cannot handle many requests. This link offers a comparison between gunicorn, uwsgi and django's development server.
Essentially,
I am doing some of the development for my Django app straight on my shared server rather than on a local machine (I know that initially is the problem) however regardless, I would like to know if there is a way to restart the apache server on my shared hosted server (Bluehost) for when I modify any of the python files.
I'm not sure how the Django framework is setup, maybe restarting the webserver is not needed?
THanks!
How is the apache configured to run python codes? are you using fcgi, wsgi or something else?
What i do is, i use a fcgi process and restart fcgi process without the need to restart the webserver. In my case web server is nginx but it should be same in apache if you are using fcgi.
I am quite a noob when it comes to deploying a Django project. I'd like to know what are the various methods to deploy Django project and which one is the most preferred.
The Django documentation lists Apache/mod_wsgi, Apache/mod_python and FastCGI etc.
mod_python is deprecated now, one should use mod_wsgi instead.
Django with mod_wsgi is easy to setup, but:
you can only use one python version at a time [edit: you even can only use the python version mod_wsgi was compiled for]
[edit: seems if I'm wrong on mod_wsgi not supporting virtualenv: it does]
So for multiple sites (targeting different django/python versions) on a server mod_wsgi is not
the best solution.
FastCGI can be used with virtualenv, also with different python versions, as you run it with
./manage.py runfcgi …
and then configure your webserver to use this fcgi interface.
The new, hot stuff about django deployment seems to be gunicorn. It's a webserver that implements wsgi and is typically used as backend with a "big" webserver as proxy.
Deployment with gunicorn feels a lot like fcgi: you run a process doing the django processing stuff with manage.py, and a webserver as frontend to the world.
But gunicorn deployment has some advantages over fcgi:
speed - I didn't find the sources, but benchmarks say fcgi is not as fast as the f suggests
config files, for fcgi you must do all configuration on the commandline when executing the manage.py command. This comes unhandy when running multiple django instances via an init.d (unix-like OS' system service startup). It's always the same cmdline, with just different configuration files
gunicorn can drop privileges: no need to do this in your init.d script, and it's easy to switch to one user per django instance
gunicorn behaves more like a daemon: writing pidfile and logfile, forking to the background etc. makes again using it in an init.d script easier.
Thus, I would suggest to use the gunicorn solution, unless you have a single site on a single server with low traffic, than you could use the wsgi solution. But I think in the long run you're more happy with gunicorn.
If you have a django only webserver, I would suggest to use nginx as frontendproxy, as it's the best performing (again this is based on benchmarks I read in some blogposts - don't have the url anymore).
Personally I use apache as frontendproxy, as I need it for other sites hosted on the server.
A simple setup instruction for django deployment could be found here:
http://ericholscher.com/blog/2010/aug/16/lessons-learned-dash-easy-django-deployment/
My init.d script for gunicorn is located at github:
https://gist.github.com/753053
Unfortunately I did not yet blog about it, but an experienced sysadmin should be able to do the required setup.
Use the Nginx/Apache/mod-wsgi and you can't go wrong.
If you prefer a simple alternative, just use Apache.
There is a very good deployment document: http://lethain.com/entry/2009/feb/13/the-django-and-ubuntu-intrepid-almanac/
I myself have faced a lot of problems in deploying Django Projects and automating the deployment process. Apache and mod_wsgi were like curse for Django Deployment. There are several tools like Nginx, Gunicorn, SupervisorD and Fabric which are trending for Django deployment. At first I used/configured them individually without Deployment automation which took a lot of time(I had to maintain testing as well as production servers for my client and had to update them as soon as a new feature was tested and approved.) but then I stumbled upon django-fagungis, which totally automates my Django Deployment from cloning my project from bitbucket to deploying on my remote server (it uses Nginx, Gunicorn, SupervisorD, Fabtic and virtualenv and also installs all the dependencies on the fly), all with just three commands :) You can find more about it in my blog post here. Now I even don't have to get involved in this process(which used to take a lot of my time) and one of my junior developers runs those three commands of django-fagungis mentioned here on his local machine and we get a crisp new copy of our project deployed in minutes without any hassle:)