Skip to main content

Cleanest & Fastest server setup for Django


I'm about to deploy a mediumsized site powered by Django. I have a dedicated Ubuntu Server.



I'm really confused over which serversoftware to use. So i thought to myself: why not ask stackoverflow.



What i'm looking for is:



  • Easy to set up

  • Fast and easy on resources

  • Can serve mediafiles

  • Able to serve multiple djangosites on same server

  • I would rather not install PHP or anything else that sucks resources, and for which I have no use for.



I have heard of mod_wsgi and mod_python on Apache, nginx and lighty. Which are the pros and cons of these and have i missed someone?



@Barry : Somehow i feel like Apache is to bloated for me. What about the alternatives?



@BrianLy : Ok I'll check out mod_wsgi some more. But why do i need Apache if i serve static files with lighty? I have also managed to serve the django app itself with lighty. Is that bad in anyway? Sorry for beeing so stupid :-)



UPDATE : What about lighty and nginx - which are the uses-cases when these are the perfect choice?


Source: Tips4allCCNA FINAL EXAM

Comments

  1. Since i was looking for some more in-depth answers, i decided to research the issue myself in some more depth. Please let me know if i've misunderstood something.

    General recommendation is to use a separate webserver for handling media. Separate means a webserver which is not running django. This server can be for instance:


    Lighttpd (Lighty)
    Nginx (EngineX
    Or some other light-weight server


    Then, for django, you can go down different paths. You can either:


    Serve Django via Apache and:


    mod_python

    This is the stable and recommended/well documented way. Cons: uses a lot of memory.
    mod_wsgi

    From what i understand, mod_wsgi is a newer alternative. It appears to be faster and easier on resources.
    mod_fastcgi

    When using FastCGI you are delegating the serving of Django to another process. Since mod_python includes a python interpreter in every request it uses a lot of memory. This is a way to bypass that problem. Also there is some security concerns.

    What you do is that you start your django fastcgi server in a separate process and then configures apache via rewrites to call this process when needed.



    Or you can:


    Serve django without using Apache but with another server that supports FastCGI natively:

    (The documentation mentions that you can do this if you don't have any Apache specific needs. I guess the reason must be to save memory.)


    Lighttpd


    This is the server that runs Youtube. It seems fast and easy to use, however i've seen reports on memoryleaks.


    nginx


    I've seen benchmarks claiming that this server is even faster than lighttpd. It's mostly documented in russian though.

    Another thing, du to limitations in Python your server should be running in forked mode, note threaded.

    So this is my current research, But i want more opinions and experiences.

    ReplyDelete
  2. As @Barry said the documentation uses mod_python. I haven't used Ubuntu as a server, but had a good experience with mod_wsgi on Solaris. You can find documentation for mod_wsgi and Django on the mod_wsgi site.

    A quick review of your requirements:


    Easy to setup I've found apache 2.2 fairly easy to build and install.
    Fast and easy on resources I would say that this depends on your usage and traffic. * You may not want to server all files using Apache and use LightTPD (lighty) to server static files.
    Can serve media files I assume you mean images, flash files? Apache can do this.
    Multiple sites on same server Virtual server hosting on Apache.
    Rather not install other extensions Comment out anything you don't want in the Apache config.

    ReplyDelete
  3. The officially recommended way to deploy a django project is to use mod_python with apache. This is described in the documentation. The main pro with this is that it is the best documented, most supported, and most common way to deploy. The con is that it probably isn't the fastest.

    ReplyDelete
  4. I'm using Cherokee.

    According to their benchmarks (grain of salt with them), it handles load better than both Lighttpd and nginx... But that's not why I use it.

    I use it because if you type cherokee-admin, it starts a new server that you can log into (with a one-time password) and configure the whole server through a beautifully-done webmin. That's a killer feature. It has already saved me a lot of time. And it's saving my server a lot of resources!

    As for django, I'm running it as a threaded SCGI process. Works well. Cherokee can keep it running too. Again, very nice feature.

    The current Ubuntu repo version is very old so I'd advise you use their PPA. Good luck.

    ReplyDelete
  5. The best configuration is not so known I think. But here is:


    Use nginx for serving requests (dynamic to app, static content directly).
    Use python web server for serving dynamic content.


    Two most speedy solutions for python-based web server is:


    cogen
    fapws2


    You need to look into google to find current best configuration for django (still in development).

    ReplyDelete
  6. I’m using nginx (0.6.32 taken from Sid) with mod_wsgi. It works very well, though I can’t say whether it’s better than the alternatives because I never tried any. Nginx has memcached support built in, which can perhaps interoperate with the Django caching middleware (I don’t actually use it, instead I fill the cache manually using python-memcache and invalidate it when changes are made), so cache hits completely bypass Django (my development machine can serve about 3000 requests per second).

    A caveat: nginx’ mod_wsgi highly dislikes named locations (it tries to pass them in SCRIPT_NAME), so the obvious ‘error_page 404 = @django’ will cause numerous obscure errors. I had to patch mod_wsgi source to fix that.

    ReplyDelete
  7. I'm struggling to understand all the options as well. In this blog post I found some benefits of mod_wsgi compared to mod_python explained.

    Multiple low-traffic sites on a small VPS make RAM consumption the primary concern, and mod_python seems like a bad option there. Using lighttpd and FastCGI, I've managed to get the minimum memory usage of a simple Django site down to 58MiB virtual and 6.5MiB resident (after restarting and serving a single non-RAM-heavy request).

    I've noticed that upgrading from Python 2.4 to 2.5 on Debian Etch increased the minimum memory footprint of the Python processes by a few percent. On the other hand, 2.5's better memory management might have a bigger opposite effect on long-running processes.

    ReplyDelete
  8. If you're using lighthttpd, you can also use FastCGI for serving Django. I'm not sure how the speed compares to mod_wsgi, but if memory serves correctly, you get a couple of the benefits that you would get with mod_wsgi that you wouldn't get with mod_python. The main one being that you can give each application its own process (which is really helpful for keeping memory of different apps separated as well as for taking advantage of multi-core computers.

    Edit: Just to add in regards to your update about nginix, if memory serves correctly again, nginix uses "greenlets" to handle concurrency. This means that you may need to be a little bit more careful to make sure that one app doesn't eat up all the server's time.

    ReplyDelete
  9. We use nginx and FastCGI for all of our Django deployments. This is mostly because we usually deploy over at Slicehost, and don't want to donate all of our memory to Apache. I guess this would be our "use case".

    As for the remarks about the documentation being mostly in Russian -- I've found most of the information on the English wiki to be very useful and accurate. This site has sample configurations for Django too, from which you can tweak your own nginx configuration.

    ReplyDelete
  10. Keep it simple: Django recommends Apache and mod_wsgi (or mod_python). If serving media files is a very big part of your service, consider Amazon S3 or Rackspace CloudFiles.

    ReplyDelete
  11. There are many ways, approach to do this.For that reason, I recommend to read carefully the article related to the deployment process on DjangoAdvent.com:
    Eric Florenzano - Deploying Django with FastCGI: http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/
    Read too:
    Mike Malone - Scaling Django
    Stochastictechnologies Blog: The perfect Django Setup
    Mikkel Hoegh Blog: 35 % Response-time-improvement-switching-uwsgi-nginx

    Regards

    ReplyDelete
  12. In my opinion best/fastest stack is varnish-nginx-uwsgi-django.
    And I'm successfully using it.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex