Comment Re:Great loadbalancer (Score 4, Informative) 340
Yep, it's mostly used for front-end duties like connection pooling, load balancing, SSL offloading, gzip, that type of thing. If you're running PHP stuff, it's still debatable whether you want to go FCGI or PDM instead of Apache's built-in module. There are ups and downs in both cases and you'll have to see what works best for your site. At my company we use Nginx up front (with server type obfuscated) for SSL offloading and gzip and connection pooling. From there it goes into a varnishd cache on the same server (stored in 100% RAM) which handles the static stuff. Varnishd then forwards remaining requests to an L7 load balancer appliance type thing which then drops requests to each of 10 web "application" servers which are a combination of Apache with mod_php, Tomcat and Jetty Java servers. We've also used Nginx as an IMAP proxy and cache and it works quite well for that.
Apache has a good architecture but it's horrible at handling a lot of simultaneous connections and recycling them (that will change in 2.4 but it's not out yet). Also, if you're using mod_php, over time each Apache process will take the total maximum amount of RAM your php process uses, and many of our PHP applications use 128-256M of RAM or more (data management type stuff). So you can run a server out of RAM if you're trying to maximize connections.
Nginx can handle 10K connections on a little box with very little RAM due to the way it threads stuff. It's basically a copy engine and it's very fast. Varnishd can also handle a lot of connections and can serve up content straight from RAM in less time than apache takes to build a connection. That being said, Apache is reliable, and has I feel better logging at the moment and just more of everything. It's a reference implementation. It's actually fine for most purposes but if you're handling 1000 users simultaneously and they are making 10-20 connections each with various service calls and static downloads, you gotta have something that can pool the conenctions on the front end and handle static content or you're going to spend a lot of money on RAM. And if you're serving up static content with Tomcat, Tomcat is absolutely garbage. I think it has to boot the whole JVM to serve up your one file. If not that bad, it's still awfully slow, and it REALLY benefits from caching up front. BTW, Nginx does caching as well but varnishd seemed more mature and elegant.
Now lastly, you can just go out and buy an F5 BigIP and it does all this stuff on specialized hardware (Ok, special board, intel chip) and it's out of the box. But even the little ones are $20K which is a lot of software dev hours and/or web server/database/storage hardware. Would be nice and fun to have but if you can't spend the money on hardware (and training!) the nginx/varnishd frontend is pretty much the best setup in my book at the moment. A little complex but once it's set up you just let it run. I made an internal nginx cache for all our internal sites, including some Java apps (e.g. Jira) and with requests going through the cache everything just flies. If you use sharepoint on IIS, you would be prettty stupid to not try a cache server up front, it's amazing. If nginx fixed mod_rewrite stuff to be the same as apache, it would probably be possible to make it into an application server, and we're going to get a test environment set up with php-fpm and see how it fares. We'll see how managable it is though.