I'm using Apache + mod_wsgi daemon mode for running a Django site. When another site is added (new virtualhost), a second daemon appears.
Is there any way to let those sites share the same proces / memory?
It seems to wasteful to have ~20MB persistently in use per site.
Bonus points: how does this compare to PHP hosting? (especially Drupal/Joomla)
Have a look at Django sites framework.
http://docs.djangoproject.com/en/dev/ref/contrib/sites/
Other than that, the answer is no, as Django use global variables for configuration and so not possible to have same code base dynamically switch what site it runs as on a per request basis.
Related
I come from a Java background where the web application is always resident in the memory. This allows it to perform all initialization tasks at the startup itself and, unlike PHP, it does not have to do that again and again for every request.
I see a lot of options to run Django projects but not sure which one of them will allow me to achieve the above? Furthermore I already have a Nginx running at 80 so requests to Django needs to be routed via it.
Django is run by python, and has a process which stays loaded in the memory, much like java. Unlike php, Django will not reload all of its data per request, and it has an application scope.
This is the reason why there are so many options for php hosting, but not as many for Django.
There are a few ways to use Nginx with Django, just google "nginx django" and you get a lot of results which teach you how, for example: https://code.djangoproject.com/wiki/DjangoAndNginx
Let's imagine I have two sites foo.com and bar.com. They both are on the same server and now running separate Django instances and apache to serve it. Of course each Django instance eats the memory.
While mainly those sites are the same systems, but with different apps loaded - maybe it is possible somehow to have for example one Django instance running and have multiple sites using it? Then I will save memory for the one instance in a particular example.
It is possible to have different sites with their url.py files, loaded apps and so on? And if this is the right way to go?
Any tips, ideas are welcome.
Thanks,
Ignas
Yes it is definitely possible to have different sites with different urls.py and shared apps.
I had to share a backend data between multiple sites. I just created 2 wsgi config files. And 2 settings files. The sites are very smiliar and didn't warrant two seperate projects. This allows me to use one django project and backend between multiple sites. I don't quite know if this is what you were asking though...
My own research today on the same topic leads me to the conclusion that you'll most likely have to have only one settings.py per Django instance/process. And the sticking point there is only one MEDIA_URL and one MEDIA_ROOT, which means all your projects media will have to be in the same location. And actually Django 1.3 has a new static file process that just goes through all the media of your seperate apps and puts them in one spot because for some reason it demands that. If you're using earlier versions I guess you can do it by hand.
https://docs.djangoproject.com/en/dev/howto/static-files/
uWSGI can serve more applications from one instance.
See "Two Pinax site in two virtualenv in two virtualhost with only one uWSGI instance" in uWSGI examples and VirtualHosting Mode.
I run a small VPS with 512M memory of memory that currently hosts 3 very low traffic PHP sites and a personal email account.
I have been teaching myself Django over the last few weeks and am starting to think about deploying a project.
There seem to be a very large number of methods for deploying a Django site. Given the limited resources I have available, what would be the most appropriate option?
Will the VPS be suitable to host both python and PHP sites or would it be worth getting a separate server?
Any advice appreciated.
Thanks.
There aren't really a great number of ways to do it. In fact, there's the recommended way - via Apache/mod_wsgi - and all the other ways. The recommended way is fully documented here.
For a low-traffic site, you should have no trouble fitting it in your 512MB VPS along with your PHP sites.
Django has documentation describing possible server arrangements. For light weight, yet very robust set up, I'd recommend Nginx setup. It's much lighter than Apache.
I run several low-traffic Django sites on a 256 VPS without problem. I have Nginx setup as a reverse proxy and to serve static files (javascript, CSS, images) and Apache using mod_wsgi for serving Django as described in the documentation.
Running PHP sites as well may add a little overhead, but, if you're talking about low-traffic "fun" sites then you should be fine.
I'm going to setup a simple Django app running in a production environment on a Linux box. The app will have very little traffic - less that 100 page loads per day. Is it okay to use the builtin Django webserver for this or should I install Apache and mod_wsgi? If so, what are the reasons for this? Security perhaps?
UPDATE
OK it is clear I shouldn't be using the builtin server. Some of the alternatives to Apache look interesting. Is there one that is more popular/more frequently used with Django perhaps?
Is it okay to use the builtin Django webserver for this
No.
Should I install Apache and mod_wsgi?
Yes.
If so, what are the reasons for this? Security perhaps?
Partly.
More importantly, the little toy Django server is single-threaded and any hangup in your code hangs the server. This means that when two users click almost at the same time, user one's query must go all the way through Django before user two's query can even starts.
And this will have to include the insanely slow download speed to the desktop.
Apache (like all the alternatives, lighttpd or nginx) is multi-threaded. The slowest part of the transaction is the download from Apache to the desktop. You don't want Python code (and Django) handling this in a single-threaded manner. Even for just a few users.
Also, you don't what Django serving static media (i.e., CSS and JS library files.)
A single slow spot in your application won't effect the overall system throughput if Apache and mod_wsgi are in place. One request 's output page can be slowly downloading to a PC desktop in parallel with another user's output.
DO NOT USE THIS (the builtin Django webserver) SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests.
http://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-port-or-address-port
But you don't have use Apache if you don't want to. You could directly use Spawning, Gunicorn etc.
Cherokee is also easy to setup.
Use nginx + gunicorn.
Nginx: five lines of configuration. Gunicorn: two lines of configuration. That's easy and efficient. For better control you can spawn the gunicorn process using supervisord.
Both gunicorn and supervisord are available to install with pip, and nginx is available in almost any distribution in the default package pool.
The built in Django server was not built for production. There are many reasons why, mainly security and efficiency.
The recommended way is to use mod_wsgi which is covered in the docs here
I have multiple sites for the same client, on the same server, running django, e.g. fooplumbing.com and bazheating.org. These two sites would each have different django apps, that is the plumbing site shouldn't be able to access the heating apps, and vice versa. There are no objects shared between the two sites, and each needs its own separate admin site.
Is this possible through something like the sites framework, or would I need to have two separate apache instances running the sites? (Yes, I need to use apache - no choice)
It's a Linux server, so is there some clever way of using symlinks to do this? I'm pretty experienced with basic django development, but I have no clue when it comes to server management.
The sites framework won't help you - they should be served as completely separate WSGI applications.
But there's no need for separate Apache instances. Just configure Apache to serve separate VirtualHosts, each with its own WSGI file.