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
nginx get my vote by far. I've worked with all of them for years.
ReplyDeletelighttpd is not an option right now, it's got major memory leak issues that have been outstanding for years, mark it off your list immediately.
The pros and cons of apache are well documented elsewhere, I'll let someone else address that.
nginx is very simple to configure, a dream for your static content task. I haven't run django behind nginx, but I've run 20 different servers with mongrels behind nginx, and it's really, really nice. Compared to apache, nginx is much less memory and cpu intensive, coupled with very simple config it's a simple decision in my book.
I would highly suggest you give it a shot before you sink the time into apache. It's possible that the python handling is better in apache, someone else can probably lend their experience.
I run Django on Apache behind Nginx, with Nginx handling the static content. I'm happy with the arrangement, but if you really value simplicity of configuration over performance, you'd probably be happiest using just Apache alone. Can't beat the simplicity of configuring one webserver rather than two. (Running Django on just Nginx using FastCGI is possible, but IMO that's more difficult to configure and less well supported; you have to manually start the FCGI processes yourself).
ReplyDeleteIf you use mod_wsgi in daemon mode and Apache's worker MPM, and you're careful not to bloat Apache with lots of unneeded modules, you still gain a lot of the same memory usage benefits as with a frontend Nginx: the Python code bloat is limited to only a few WSGI daemon processes and your Apache worker threads can stay quite slim for serving static content.
I will not talk about apache... it is well known and documented. I'll talk about nginx vs lighttpd.
ReplyDeleteThe second one (lighttpd) is much more feature rich, easier to configure and it has a way better documentation. When talking about deployment of FCGI or SCGI application (the API Django actually uses) there are several important points that lighttpd has:
It provides support for spawning FCGI and SCGI applications on its own, meaning it can fork and manage it for you if you want. (For SCGI spawning use lighttpd >= 1.4.20). When it comes to nginx you must manage you fastcgi/SCGI application on your own -- use your own startup scripts.
It provides support of both TCP/IP sockets and Unix domain sockets for both protocols. (AFAIK nginx and apache does not provide support of unix domain sockets for SCGI).
It provides native support of CGI PATH_INFO variable. In nginx you should do a silly workarounds using regular expressions to provide PATH_INFO that is not supported.
nginx does not support CGI spawning, meaning that if you have a simple task to do that can be easily done with CGI, it is impossible for nginx to handle it.
Configuration of FCGI for lighttpd is way simpler -- about 4-5 lines.
So... Nginx is indeed nice web server, but it isn't my first choice.
That is my little experience with FCGI/SCGI development using various servers.
You might want to have a look at Cherokee, if ease of configuration and high performance are your goals. You'll find it friendlier than lighttpd as far as configuration, about if not more efficient than nginex and even hooks for some Apache compatibility (easy to port rewrites, etc).
ReplyDeleteI recently moved most of my lighttpd installations over to Cherokee with great success. I'm even using it as a front end load balancer, both for http and mysql. Its really a well written, very versatile and extremely friendly server.
I pretty much agree with all that Carl Meyer writes. Wonder how Stack Overflow handles "me too" responses? :-)
ReplyDeleteThe original question doesn't give much specific information about the intended use - expected load / requests per second, hosting type, etc. Assuming that the load is small'ish, I would recommend using just Apache with mod-wsgi, or Apache with mod-wsgi and S3 for static file serving.
mod-wsgi recently became the recommended way to deploy Django, see http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/ . Given this status, you should expect this method to see a lot of usage, and therefore a lot of documentation, tips'n'tricks and blog posts. Graham Dumpleton also recently release mod-wsgi 2.4 which looks quite mature (I haven't used it yet).
You can put nginx in front of Apache to proxy dynamic requests, and serve static files. This setup serves many people well. The nginx wiki has good tutorials on setting this up, http://wiki.nginx.org/Main . But this also gives you two sets of config files to learn, and two HTTP servers to keep updated.
Using only Apache, you could use Apache to serve static files, use mod-wsgi in deamon mode to handle Django. Then split up the requests by URL so that static file requests do not invoke the WSGI / Django stack, but are handled by Apache alone. This is again well documented, see your favorite Apache book for location handlers, or see the Apache / mod-wsgi docs. This at least 'centralizes' your learning, so that you only need to learn Apache & mod-wsgi configuration, and to keep Apache & mod-wsgi updated.
Another simple way to go would be to use Apache + mod-wsgi for all dynamic Django content, and put all static content on f.x. Amazon S3. Depending on your expected use / frequency of updating static content, this might be the very best. Amazon lists a couple of freeware applications to make working with S3 simple, such as S3Fox, Bucket Explorer etc.
HTH,
By far, lighttpd is the easiest to configure (as a matter of fact, I migrated from Apache to lighttpd due to configuration easiness/comfortableness).
ReplyDeleteApache has far more options, and customizability, but, if you don't need that, stick with lighttpd. Most benchmarks out there give it about 50% better performance than Apache.
I've never used nginex, so I've no opinion on it in particular.
In reply to Carl Meyer's Jan 24 '09 answer,
ReplyDelete(Running Django on just Nginx using
FastCGI is possible, but IMO that's
more difficult to configure and less
well supported; you have to manually
start the FCGI processes yourself).
There's a very handy init script on the Django site for managing multiple Django FCGI sites. You can start/stop/restart/status sites individually too.
Nginx and lighttpd are better for low-memory environments such as on a VPS. Apache is good if you want a wide range of configuration options. Since lighttpd is being "rewritten", I would go with nginx right now.
ReplyDeleteOne nginx feature I like a lot is the ability to reload its configuration on the fly without dropping any requests. lighttpd's solution for this (lighttpd-angel) will drop incoming requests on a busy system.
ReplyDeleteComparing both nginx and lighttpd with Apache the biggest win I've found is the easy, per URL regex based configs which make complex configs with different settings for different directories (or file patterns) really easy to do.
Simple, Cherokee + uwsgi is the perfect combo. I like Cherokee very much, it is fast and efficient. It has a clean code and also has a web based configuration Program called cherokee-admin. There is nothing that chould beat that. You don't need to write a config file yourself. I used to backup do yourself config files. But, cherokee-admin makes it too easy to give it up. It'd suggest you to read-up on Cherokee vs Everything else ( there are benchmarks btw ) or you could try both and let us know your results.
ReplyDeleteBoth lighttpd and nginx have similar memory footprint. Both serve well its purpose so it's a matter of personal taste - to me lighttpd configuration is easier to understand and maintain.
ReplyDeleteApache has long been preferred solution but mod_python has some serious problems when it comes to more complicated configurations, for example running 2 Django apps with different LANGUAGE_CODE is impossible due to race condition in setting locale (you have to load separate interpreters or run separate apache instances, effectively making your apache to eat doubled amount of memory).
On the other hand, FastCGI processes are separated (and no, you do not need to start them separately, see runfcgi command of django-admin.py).
I really like the way how nginx behaves under heavy load. I've experienced myself that its predictable memory footprint feature (due to asynchronous request handling) saves you a lot of pain.
ReplyDeleteThe only problem with nginx I have is that you don't have per-directory configuration file (eg. .htaccess), which is usable when you host diffrerent applications each with its own rewrite requirements.
lihttpd has memory leaks, nginx is great as reverse proxy and for caching but is a little complex to configure it; cherokee is light and easy use, has a web administration interface with wizards for Django, Rails, WordPress... and many other plataforms...
ReplyDeleteI will favor onto a nginx personally. But if it's not optimized properly it'll be like hell.
ReplyDeleteBut i would also have my view onto specs like having a SAS hard disk.
I'm running Django on nginx+wsgi module (Gentoo build from connectical-contrib overlay). It's a speed of lightning compared to Apache.
ReplyDeleteI used Apache with mod_python and mod_wsgi for a while and then switched to nginx in combination with gunicorn. I found the latter to be way easier and more intuitive to configure as I mentioned in a blog post.
ReplyDelete