Reply to comment

I put Apache as the front server, handling requests for Django generated pages and passing, via mod_proxy, requests for static content to Lighty on the back. A setup where Apache had to work even for files that wasn't supposed to serve was a very bad idea.

There is nothing wrong with the nginx pick. However, the proxy service runs somewhere anyway. It doesn't matter if that is nginx or Apache. I would assume that mod_python would beat mod_wsgi quite handily just as mod_php beats the fastcgi version. There is no way multiplexing a socket can come close to a bound memory location when it comes to writing to scoreboard. The problem is expensive language processes waiting on browser connections. The proxy removes that issue because the proxy "baby sits" of the connection once it receives the result, just as it did for lighttpd, and the language process can go on to the next request. With either this, or the way you showed with mod_proxy, the language processing modules won't need to handle static content anymore, and you aren't tying up smart processes to serve static content. However with this method, since the proxy is not running in Apache, how do you handle .htaccess and mod_rewrite? Those two are basic to many web apps. Then there is the additional vhost file maintenance.

While nginx does have a WSGI module, nginx runs as a single-threaded server and so it's not clear how scalable an nginx-only solution would be. Apache is a bit heavy for static media serving, so a combined nginx-for-static-media + Apache-for-dynamic-content seems about right.

That man understands. The performance comes from taking away static content from Apache language interpreter, and proxying it to a stripped down web server so that the language processes don't get tied up chasing static content or feeding content to browsers. When servers like Lighttpd and Nginx use FastCGI, their hope is that the efficiency gains more than offset the loses incurred by FastCGI vs an SO. The reason that can happen is because for every dynamic element there may be 10 to 20 static ones. But why give up the speed? There is only one justification, and that is if you want to use a threaded server with non-threadsafe scripts. But that reasoning isn't valid with a proxy because you wouldn't have KeepAlive on anyway because the language interpreter process is not maintaining the connection with the browser anymore, the proxy is. ?NIX has no performance issues with either threads or processes, so now we're down to Windows. Nginx, a fork of apache 1.3 with the multi-processing removed in favor of an event loop, is not a technological marvel. Event loops are great for a large number of low activity operations such as feeding static content from OS cache to a proxy or browser. The IO model with threads or processes is what you need when scheduling processes under load and when they are waiting for information from a database. When there is little load, you can't tell the difference. With the level of parallelism achievable in hardware rapidly going up, the event loop will be ceding more and more ground to the IO model. FastCGI simply gets the light weight servers off the hook for something they cannot do, or cannot do well.

Personally, I'd do mod_proxy + nginx. nginx may be slightly faster if it also does the reverse proxy, but it's going to cost you. In a shared hosting environment, software and customers won't let you get away with not having .htaccess, and apache mod_rewrite, a lot of software also won't, and I wouldn't want to lose the Apache speed and reliability for dynamic content. Moreover, there is third party software that I would want to run as an admin that requires mod_proxy.