Nginx-1.4.0 stable version has been released

I ended up going with

    proxy_read_timeout 31536000;

The more cautious solution might be to use a lower timeout (120s or so) but to have the server send heartbeats over the websocket when it's not doing anything. (If you're using socket.io, you're already getting this behavior for free; if you're using sock.js, you can enable it.) This breaks down at true scale, though: when you have 100000 idle clients you might want to announce to at any time, but don't usually have anything to say to most of them, sending heartbeats to every client in that pool can saturate your link.

A compromise is probably to set the long timeout, but then use a cluster-monitoring service which will push a new config to your load-balancers in response to observed network-toplogy changes.

EDIT: it's the proxy_send_timeout directive.

  cat access.log.1 | wc -l
  1054423 # no static objects served here
  cat error.log.1 | grep timed

The name referred to API/module stability, more than production-worthy-ness.

GL with your deploy!

  nginx[20116]: nginx: [emerg] the "spdy" parameter requires ngx_http_spdy_module in /etc/nginx/nginx.conf:26

"This module is not built by default, it should be enabled with the --with-http_spdy_module configuration parameter."

So unless you go with an unofficial binary, you'll have to compile it in yourself.

But really, the burden of a 'custom compile' is small. Nginx configuration is simple, it has minimal dependencies, and it builds quickly. You will need zlib-dev and openssl-dev.

EDIT: looks like spdy (on same port as https) requires openssl >= 1.0.1. centos has 1.0.0. nuts.

For sure, the configuration file format is different, but it's not terribly complicated.

I use this code to open a unix socket in production at tmp/socket : https://gist.github.com/lgbr/5453355

And use a configuration like this for nginx (replace /etc/nginx/sites-available/default with this): https://gist.github.com/lgbr/5453375

    sudo apt-get install nginx
    $BROWSER http://wiki.nginx.org/Configuration
    $EDITOR /etc/nginx/nginx.conf
    man nginx
    man upstart
    sudo start nginx
    $BROWSER http://localhost:$PORT/

[0]: http://nginx.org/en/linux_packages.html#distributions

Nginx was written from the ground up in the modern web era, when we had already learned about the common ways that real websites worked (dynamic, high throughput, tied into other technology like php or rails, possibly living on multiple servers, etc.) Nginx is designed for efficiency and low overhead. It's also designed to live within an ecosystem rather than live as the container of an ecosystem, at its heart it's not a web-server it's a proxy. And all of this makes nginx easier to set up, easier to configure, and generally more efficient with superior performance compared to apache.

Here's an example. I have a server set up with a couple different sites, some of them are fronted by varnish (for caching), several run on php, and another runs on rails. With nginx this is all fairly easy to do. Instead of installing modules as you would tend to do with apache you set up php and rails as standalone socket-based servers (e.g. php-fpm and unicorn) and then in your nginx configuration you simply tell the web server where those are and how to use them.

Nginx also funnels you into a pattern which makes it easier to scale. Because nginx is just part of an ecosystem and not the container of an ecosystem you can easily migrate components to other servers as necessary. In my example I could push varnish off to another server, push each php app off onto its own server, push rails off onto separate servers, etc. The configuration changes would be fairly minimal and it would all still just work.

Just be absolutely sure that you never need the additional features that Apache Httpd provides, and Nginx will probably be a good choice.

Read http://stackoverflow.com/a/3635081/309483 There is also a linked 100+ vote question, but I think it has too much noise.

I'm an Apache guy too. If you know how to configure it, there's not much reason to switch from Apache.

I use Nginx because I find it easier to configure and more lightweight out of the box.

For example, Apache is chock full of modules with a certain richness to them, they do everything and everything you could possibly think of, with a verbose configuration that usually comes filled with "defaults" by the maintainer, and plenty of options to choose between processes and threads; Nginx is "lean and mean", strictly event-based and minimalistic in almost every way, is usually compiled to include just what you need (and still feels un-monolithic despite modules being statically compiled), comes with sensible defaults and is usually bundled with almost no config.

Some rough analogues: Nginx is to Apache what (Varnish, Postfix, Go, Git) is to (Squid, Exim, C++, Subversion).