(By comparison, Apache is quite the memory hog and I still haven't figured out how to say the magic words to get it to not effectively crash my blog and every other site on the server if I burst to 10,000 visitors in an hour. That is not supposed to be a big number. Apache has 500 MB to play with and still can't keep up.)

I also find, and this might just be a matter of taste, that the configuration makes more sense to me than Apache configuration does. This is funny because Apache configuration is obsessively well-documented and Nginx configuration is not.

Additionally, some easy-to-use features cover weak points in typical Rails (&etc) deployment scenarios. The big one for me is file serving, since my website is essentially one big PDF printing press. The simplest level (works for me, won't work for Facebook) is just having the file anywhere accessible on the disk and having the application put a special header on the response saying "Hey, Nginx: give them this path.", then terminating Rails' involvement. That frees up your Mongrel to start doing hard work again and greatly, greatly, GREATLY decreases the resources you need to stream your 5 MB PDF, 20 MB executable, etc to the user.

So it scales down, but does it scale up? Ooooooooh yeah. Impressively so. See the tales of Wordpress deployment, where not a whole lot of Nginx gets hit with a year's worth of my traffic every couple of seconds and still keeps on trucking.

Give it a try next time you set up a server. It'll save you about 30 minutes to an hour of screwing around with mongrel cluster configs and nginx proxying.

Can't say enough good things about this peice of software. It just works and it's smoking fast and very resource friendly. Thumbs up all around

http://brainspl.at/articles/2006/08/23/nginx-my-new-favorite...

that config file lives in infamy on many thousands of vps's across the land ;)

Take a look at the source sometime. It's kind of fun to see an HTTP parser written like, "if (ngx_str3_cmp(m, 'G', 'E', 'T', ' ')) { r->method = NGX_HTTP_GET;"

haproxy's HTTP feature set is comparatively limited and we simply have too much traffic to put one machine in front of a bunch of web servers.

Speaking of good Web servers, I've heard good things about Yaws lately. Anyone have any real world experience with it? This is the only seemingly solid comparison I've fond: http://www.planeterlang.org/en/planet/article/Nginx_vs_Yaws_...

I just wanted to say that I absolutely love your search engine. Really really good job on that.

    Pingdom: Where do you think nginx will be in 5 years?

    Sysoev: I really have no idea.

As Sysoev was working for one of the Russia's biggest portals that apache couldn't handle very well.. So he wrote a server that did one thing very well - waits until client submits their request and then serves this request as fast as possible. And he did it well :)

Slowloris HTTP DoS - http://ha.ckers.org/slowloris/

I'm proud to say I contributed to this. From RailsSpace (2007), p. 506:

  Nowadays, it seems that many of the cool kids have switched
  to a webserver called Nginx, used on its own or as a proxy
  server. Since much of its documentation is in Russian,
  Nginx (pronounced "engine X") is relatively obscure, but
  we've heard great things about it, and it's currently being
  used by several prominent Rails hosting companies.

That said, compliments on spotting a solid piece of software from a mile away.

This is interesting. On Sysoev's personal website, there is an article "Why Google V8 is not suitable for embedding into a server yet"(Russian) http://sysoev.ru/prog/v8.html

Basically, he's saying that V8 was developed with Google Chrome in mind, so it's not an easy task to embed it with any other software. The main point is, V8 can't handle memory allocation errors - it just crashes the process, which is suitable for Google Chrome but not for a server.

I think it takes time to gain that expertise.

nginx's code is amazing, even being barely undocumented.

EDIT: I had to add dotdeb repo for php-fpm.

http://library.linode.com/web-servers/nginx/php-fastcgi-ubun...

Also, unrelated, but I see most arguments in favor of nginx say that it is excellent at serving _static_ files. Since my application serves mostly dynamic content, what do you think can be performance benefits?

EDIT: This article is fantastic too http://interfacelab.com/nginx-php-fpm-apc-awesome/

And if you host your static files on a CDN that's even less reason to use nginx.

Here's some benchmarks: http://blog.a2o.si/2009/06/24/apache-mod_php-compared-to-ngi...

It shows that if you just run PHP, mod_php results in better performance. So, many people who also need to serve static content use nginx for static, and then proxy PHP requests to apache (though this seems like it would defeat the purpose of needing apache).

Of course this all becomes moot if you consider that when you get to these points of performance demand you'll probably take a look at HipHop (assuming you use PHP) and compile your PHP+Web server into a single daemon.

EDIT: By the way, that linode article uses spawn-fcgi, not php-fpm. php-fpm is in the dotdeb repository and you have to add that to your sources.list.

  from what I hear mod_php is faster than fastcgi

On a sidenote, does it make sense to use HipHop in conjunction with xcache?

Here's what I'm thinking:

  nginx > static files
  nginx > php > apache + mod_php > xcache > HipHop

The nginx for static and php-fpm (which runs php as a fcgi) will get you very very far. Wordpress.com for example uses a similar setup (with a hell of a lot of caching in between).

Most of my apps aren't bound by php cpu time, I'd only use hiphop to play with personally. =)

We (at the time I was the CTO for massify.com) evaluated a lot of different configurations and nginx+php-fpm+apc was about the fastest we could get the site going.

Glad the article was useful for you.

And setup was pretty easy, as most components are available from the package manner of your choice - http://www.newmediaist.com/n/installing-nginx-mysql-php-fpm-...

Fortunately, nginx allows you to upgrade to a new binary on the fly.

http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Bi...

http://gist.github.com/313430

Development effort is probably the real reason. It takes a fair amount of planning to design a table-driven module loader and indirection layer. Indirection with raw pointers costs brain power. (And do not even think about the reference counting hell of a dynamically unloadable module.)

Edit: And think about what happens when you upgrade a Django or Rails plug-in: it generally gets recompiled and what amounts to relinked. The difference is that the language system itself hides the work, while nginx uses explicit build tools.

Among the most famous sites using Cherokee are the (recently hyped) chatroulette.com and Lawrence Lessig's web properties.

I really hope he includes lua and javascript. Both would be cutting edge (Javascript server side is still pretty new) and Lua which should be used more. Kepler Project (http://www.keplerproject.org/) is pretty good but Lua gets no love, this could change things big time for Lua.

It's in russian unfortunately... Probably google translate will help? In short - article says that V8 is not ready to be embedded in servers because of certain shortcomings.

The only feature I miss from Apache is being able to use .htaccess.

.htaccess made sense in the world of spaghetti code CGI/PHP scripts running on shared servers, in the world of app frameworks like Rails and Django that stuff (redirection, authentication, etc.) is better handled in the application.

The only cases .htaccess is useful in modern app development is for requests for static assets you don't want routed through the app (images, javascript, etc). Say you want to change MIME types of perhaps the content-disposition. But even in those cases, usually that should be documented as something to enable in the global server config, for two reasons: 1.) .htaccess needs to be checked each request for changes, slowing down your server 2.) you can't just assume .htaccess works, so the administrator needs to be aware of whats going on, in which case they may as well just put it in the global config. Unless your own a shared host like Dreamhost, in which case, yes, .htaccess is very useful.

You can also setup nginx for Basic Authentication with NginxHttpAuthBasicModule - http://wiki.nginx.org/NginxHttpAuthBasicModule

Emiller's Advanced Topics In Nginx Module Development: http://www.evanmiller.org/nginx-modules-guide-advanced.html

(this is especially true of software, where you don't need money- only time)

Ya know, Occam's razor and all.

I was at this point, playing with Lighty as an alternative, when nginx first starting poking its head about.

After trying one installation of it, it was so much quicker and smoother that I basically instantly ditched any ideas of bothering with much else. Then you start running sites with any real traffic, where it's more stable than anything I've ever seen, with no real effort and it makes the amount of bs that goes into lighty look ridiculous.

So I guess "the story" is it targets the same niche, and it's better. Bonus being that the deeper you go or the heavier into that niche you are, the wider the margin is.

Perhaps this is a bit unfair, but this is what led me to move over to nginx from lighttpd.

Does nginx work with any Java stuff?

[1] http://docs.google.com/present/view?id=dcbpz3ck_24f3v83ggz (slide 16)

-harryh

Wrote a bit about my recreational CentOS install: http://todd.is/nginx-php-and-wordpress-migrating-from-lightt...

http://almosteffortless.com/2009/10/22/installing-varnish-wi...

http://almosteffortless.com/2009/09/16/passenger-with-nginx-...

Nginx + Passenger + REE

FTW

nginx config files are logical

It's brilliant. Almost effort-free and insanely fast, in most cases.

It offers a really cool path too, in nginx + Py -> nginx + Py/C -> nginx + C plugin, to grow from a quick throw-together prototype to something that will take as much load as you can make up with silly benchmarking tools, while development takes a sensible route.

Edit: As a cool more concrete example, I used this trick to build a very quick 'hardware access layer' for an embedded device when it was insisted that Flash be used for the UI. It was 99% Python but with nginx to serve static files and proxy the rest to Flash, and CherryPy as an access layer to a local SQLite DB for data, with Python C calls to proprietary hardware drivers for the device.

Sounds sloppy perhaps but for what it had to do and how well it runs it was incredibly quick and painless to put together.

http://shoptalkapp.com is nginx -> haproxy -> (cherrypy/diesel)

I.e., if Host header is X, and Ip is Y, but no cookie was provided, then use pool... with this balancing scheme.

nginx's proxy setup out of the box is useful, but I wouldn't consider it on par with things like ZXTM or a Big IP when it comes to robust balancing/fallback patterns and flexible routing rules.

If there's a module that provides all that, I'm happy to hear about it--I haven't found it yet.

So I can't do my fancy HAProxy routing rules on HTTP requests HAProxy can't read--it would be reduced to a simple TCP-level balancer then.

Basically, nginx is there for ssl, gzip, caching (redis/memcache mod), and all those http-plugin-goodness things. Simple proxy directly to HAProxy on loopback, which specializes in load balancing, traffic routing, failover, etc. Then, finally, the application code on N nodes behind HAProxy.