Nginx webserver

The Nginx webserver is a small, fast webserver with very small footprint. It is very good as a static content server as well as a webserver for low memory servers and as a reverse proxy. Nginx isn't based on threads or preforks, instead it was designed as an asynchronous event driven application. The main benefit is small memory footprint, however it also means that processes may be blocked by long running operations if you run things like mod_perl or mod_wsgi. So just avoid those things and let Nginx do what it was designed for: serving static files and reverse proxying (fastcgi and the likes included of course).

Pros:

• Modular design
• Small memory footprint, damn fast.
• Cache is very tweakable
• FastCGI module with optional caching
• Easy yet powerful rewrite configuration
• Fast caching module
• Has a "mirror store" for saving FastCGI responses as files (and serving them later instead of proxying requests)
• Has the essential features required for production webserver, feature-set is reacher then Lighttd's
• Zero downtime upgrade
• Userbase is growing fast, new modules are added every day

Cons:

• No dynamic module loading, recompilation needed to add modules
• Some features misbehave
• No mod_php, mod_perl is experimental, no cgi support (but who needs it anyway?)
• Forget about changing php/cgi behavior in specific locations, all setting must be done on the FastCGI backend - so you might need a few php-cgi process or just insert ini_set in the app
• The documentation used to be pretty horrid, but there has been gradual improvement. The mailing list is a big help when in trouble.
• No digest authentication, limited number of auth backend (htpasswd files, pam), no group auth
• No user config files (.htaccess)

Quirks

• Varnish backend polling - returns error 499 if needs to proxy the request

Configuration tips

• location directive can only be nested inside static locations (e.g. non regex)
• the try_files directive can be used to serv dynamic content when static content cannot be found (e.g. automatic image resize with a cgi script). try_files is faster and more explicit then if..else..set and should be used whenever possible.
• No if nesting - for multiple conditions a cumulative variable must be used:

  if ($http_user_agent ~ "iPhone") {
     set $iphone_redirect "iphone";
  }
  if ($uri ^~ ^/iphone) {
     set $iphone_redirect "${iphone_redirect}_redirect";
  }
  if ($iphone_redirect = "iphone_redirect") {
     rewrite (.*)      /ipohone$1;
  }
  

  The same goes for using a match from multiple conditions. Set a variable to the value of the match in the immediate if block then use the variable later when rewriting.
• Make sure upstreams are defined before any proxy statements, if upstreams are included check inclusion order.
• On the 0.8.x branch, named capture groups in regex matches are available. This makes set $1 statements redundant. E.G. location ~ /bin/(?<script>.+)\.php)$
• X-Accel-Redirect

Application configurations

• Foswiki
• Drupal

Benchmarks and testcases

TODO

-- AvishaiIshShalom - 02 Aug 2009