Nginx-1.4.0 stable version has been released

http://nginx.org/#2013-04-24

by spindritf • 13 years ago

210 71 13 years ago

aioprisan• 13 years ago

the websocket support is very interesting and useful for node.js projects: http://nginx.org/en/docs/http/websocket.html

atto6• 13 years ago

As a tip to anyone using nginx to proxy websockets: make sure you increase the proxy read timeout for that connection. Otherwise, nginx will drop the (active) connection much sooner than you'd otherwise expect.

derefr4• 13 years ago

Indeed; all the docs I could find referred to the old pre-websockets-support behavior, where you used TCP-passthrough and there was a (hackish) "websocket_read_timeout" property.

I ended up going with

    proxy_read_timeout 31536000;

--meaning that a client can hold open a websocket without the server needing to say anything for a year at a time. I'm not sure whether that's a good idea in all cases, though; it means you won't detect silent backend netsplits (i.e. the network cable getting cut to your appserver box without giving it a chance to FIN) since the TCP connection will still look open.

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.

atto6• 13 years ago

Yep. We initially went with a 1 hour timeout — worst case, the client drops every hour, and then immediately reconnects. We actually moved to a heartbeat system recently, because we found issues with spotty connections where we'd have packets lost / delayed (for up to a couple minutes), but the server and client both believed they were connected.

Scaling the heartbeat is actually not a big issue. If you're actively using the socket for things, the overhead of that is likely much higher than supporting pings. You'll actually hit port limitations first (if you can support ~65k connected clients per machine), in our experience. 3000 pings a second isn't too bad (that's 100k clients, pinging every 30 seconds or so). You can also change how fast the client is pinging based on client activity.

ushi3• 13 years ago

The default proxy_send_timeout is 60s. If you rely on the information about connected clients (chat anyone?), it's way nicer to ping the server every 30s, than to set huge timeouts. If internet connection of the client breaks (mobile anyone?) and the client has no possibility to close the websocket connection, nginx keeps the connection open and you server thinks that there are some clients to talk to. Nice side effect: Your client knows about the disconnect, because the ping fails.

EDIT: it's the proxy_send_timeout directive.

atto6• 13 years ago

Agreed. We have a larger window so that we can adaptively ping (when the client isn't very active, we don't ping as often). We're not making chat though.

If you do want timeouts like this, an alternative is to handle this on the application layer, and not rely on nginx to drop connections.

derefr4• 13 years ago

EDIT: the parent originally said "proxy_read_timeout", and this comment was in response to that.

proxy_read_timeout times out reads from the upstream. It will trigger when a backend server goes AWOL, not when a client falls off the net.

If you want to detect client-side disconnection, you want proxy_send_timeout.

You can emulate this by having server sent heartbeats with a proxy_read_timeout with the client required to respond to them before the server will send any more, thus going read-silent whenever the client fails to respond, but why not just have the client do the pinging? Then the server doesn't have to say anything in response most of the time.

adisbladis• 13 years ago

Finally! I have really been looking forward to the SPDY support in stable.

e1ven• 13 years ago

It's a very cool thing. One thing you might not have been aware, due to the unusual naming- The 1.3 series is/was perfectly stable for production use.

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

GL with your deploy!

JennyZ3• 13 years ago

Me too, I just updated on Arch but activating SPDY isn't working so far:

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

Seems the Arch package was built without SPDY support?

ushi3• 13 years ago

Add --with-http_spdy_module to the configure flags in your PKGBUILD. But expect problems with parallel XHR file uploads in all major browsers.

JennyZ3• 13 years ago

Seems the package has been updated again with SPDY support this time (1.4.0-2)

fourstar• 13 years ago

I've always used Apache but I really want to use nginx for my next project (it's a Node/express app). How should I start? It'll be running on my Ubuntu VPS. Any tips, suggestions, common pitfalls?

Osiris• 13 years ago

The only pitfall that I've run into is converting Apache rewrite rules (htaccess) files and getting that into the nginx configuration file.

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

ceejayoz• 13 years ago

Once you get used to it, it's a lot nicer to work with, too.

lgbr• 13 years ago

There's really not that much to it. Use nginx that comes from APT and use a unix socket to communicate between node and nginx.

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

mixmastamyk2• 13 years ago

    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/

spindritf• 13 years ago

> sudo apt-get install nginx

If you want the newest version, nginx has their own deb repository[1]. It seems to get security updates faster, too.

[1] http://wiki.nginx.org/Install#Official_Debian.2FUbuntu_packa...

EDIT: Not the PPA because it's "maintained by volunteers and is not distributed by nginx.org." Their repository:

deb http://nginx.org/packages/ubuntu/ yourOScodename nginx

olouv• 13 years ago

This was really helpful to me: https://github.com/h5bp/server-configs/tree/master/nginx

didip• 13 years ago

If you use the famous upload module: http://www.grid.net.ru/nginx/upload.en.html, it no longer works since Nginx 1.3.9.

See: https://github.com/vkholodkov/nginx-upload-module/issues/41

mixedbit• 13 years ago

One feature I miss the most in nginx is a dynamic loading of modules. I wonder if this is anywhere on a roadmap, or is there some deeper reason for such limitation?

beagle32• 13 years ago

Just recompile, and live switch to the new version. It's comparable hassle to editing the apache config file and sighupping it.

mercurial• 13 years ago

Except that you don't need to touch your config file every time there is a security upgrade.

ch0wn• 13 years ago

There's a fork (or distribution) of nginx that includes dynamic loading: https://github.com/alibaba/tengine

andyfleming2• 13 years ago

When will the Ubuntu PPA will be updated?

sp332• 13 years ago

Here, ask the maintainers: https://launchpad.net/~nginx/+contactuser

sahaskatta• 13 years ago

I was about to ask the same thing. The current stable version in PPA is several versions behind.

pfg• 13 years ago

You could use the Ubuntu apt repository[0] managed by nginx. I've been using that repository for years, always worked great. New releases get pushed (almost?) instantly.

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

andyfleming2• 13 years ago

I'm getting a 504 on http://wiki.nginx.org/

nodesocket• 13 years ago

Using the official YUM repo http://nginx.org/packages/centos/6/$basearch/ they don't build with the `ngx_http_spdy_module` enabled. Is there a way to get it, without doing a custom compile? I'd like to continue to use the YUM package manager.

nacs• 13 years ago

From http://nginx.org/en/docs/http/ngx_http_spdy_module.html :

"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.

oconnore• 13 years ago

On Ubuntu, there is an "nginx-extras" package with more modules. I don't have a centos machine handy.

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.

druska• 13 years ago

Chris Lea has a PPA for nginx-devel with SPDY enabled: https://launchpad.net/~chris-lea/+archive/nginx-devel

stock_toaster• 13 years ago

grab the spec file, edit, and build. then use yum localinstall.

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

camus• 13 years ago

"So i'm still an apache httpd guy , can you sell me nginx in 3 simple points ?" (actually i'm using it already , i need to sell it to my boss).

gexla• 13 years ago

You probably don't need to. Apache is good enough and if you have to sell your boss on using Nginx then you probably don't have enough need to switch. It should sell itself or you are probably just wasting your time.

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

iso8859-12• 13 years ago

It's simpler, easier to configure, has event-driven "magic" :). But seriously, you can google this and it doesn't make sense to sell HTTP servers like toothpaste anyway.

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.

harshreality• 13 years ago

Being able to run a site using less memory on average, and much less memory in the worst case (traffic spike for a site running a dynamic language module like mod_php), is a major reason to switch to Nginx from Apache.

njharman• 13 years ago

If your using it already, why do you need to sell it?

seunosewa• 13 years ago

Its more efficient. It uses far less RAM when handling a lot of concurrent connections.

InclinedPlane• 13 years ago

Apache was designed in an era where the webserver did everything, and most of what it was doing was serving static content. And the fundamental design of apache as well as the design of its configuration system is optimized for that. And though it's been modified extensively to do everything a modern web server needs to do in many ways it's still held back by that heritage. Also, apache is fairly monolithic. The way to add functionality to apache is generally with modules, for example, and generally a random apache installation is going to have vastly more features active than you may actually need, or want. All of which affects performance.

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.

smcnally• 13 years ago

Nice. After many years of apache, I, too, already use nginx. This is helpful, still. "funnels you into a pattern" is especialy good. Thank you.

1SaltwaterC3• 13 years ago

I'd argue a little with the "Apache is monolithic". If you know your elbow from your butt, you can make a decent Apache setup as any decent sysadmin should do. The thing that I hate the most in nginx is the lack of DSO modules. When I need a new module, I need a new nginx build. nginx itself has more than you ask for in a standard build. As example, I counted the "with" and "without" flags from out nginx package build script. It has 3 "with" flags (SSL, gzip static, PCRE JIT) vs 14 "without" flags. And we can part with gzip static since most of the static objects are pushed by CDN's now.

Apache is catching up with its evented MPM and proxy support, but I still wouldn't go back to Apache though. The main selling point that the OP should get is the fact that evented servers have much better memory usage under the same load as the threaded servers or (cough) process based servers.

lobster_johnson2• 13 years ago

It's not so much switching to something qualitatively better than to something with a somewhat different style.

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).

zimpenfish• 13 years ago

I can accept Git >> Subversion and Varnish >> Squid but I'll take you on with sticks and pillows over Postfix >> Exim because that's entirely nonsense, sir, and I WILL NOT HAVE IT.

mattparlane2• 13 years ago

This page: http://nginx.org/en/docs/http/ngx_http_spdy_module.html says that the module is experimental. Is that accurate, or have they just not updated it once nginx stable was released?

pavs4• 13 years ago

Does anyone have a solution to this problem with nginx I have had few times over the years?

http://www.howtoforge.com/forums/showthread.php?p=296263#pos...

Please note that I am not 100% sure if its nginx related.

mattparlane2• 13 years ago

I see you're running FPM -- I had the same problem, and it turned out to be FPM's worker auto-spawning system. I set it to pm = static and set the number of workers to 50, which is the most I ever need, plus some headroom. Give that a go.

pavs4• 13 years ago

Thanks I will give it a shot when I go home, I can only ssh to my server from home computer. You are right the pm is set to dynamic last time I checked, its the default.

I will update you on this after observing my server for 24 hours.

pavs4• 13 years ago

Just wanted to update you on this. I switched to another hosting provider (for other reasons) so I ended up working on the server from scratch. The pm is still dynamic because I want to see if I can reproduce the problem again, and if it does I can always try static.

Thanks.

1SaltwaterC3• 13 years ago

I can provide you some pointers as we made it go away. Some data from one of our production virtual hosts:

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

For PHP-FPM we use static pm and unix domain sockets. This virtual host if fairly busy with some slow (~200 ms) requests, therefore it uses 96 processes per pool. listen.backlog = -1 in php-fpm.ini for letting the kernel decide the size of the actual connection backlog. UDS is getting filled faster than TCP and nginx starts responding with 502's. Throw net.core.somaxconn = 65535 somewhere in /etc/sysctl.d for increasing the actual backlog since even if you specify a high listen.backlog value, the actual value is truncated to SOMAXCONN. Couple of years ago I wrote an article about stuff like this: http://www.saltwaterc.eu/nginx-php-fpm-for-high-loaded-websi... (shameless plug, I know, but you may get some useful info). As a side note, I am curious how the backend persistency for nginx is playing. Our production still uses the same config since 2011 as it isn't broken, but it may be more efficient.

pavs4• 13 years ago

I tried your suggestions listen backlog and somaxconn, are they dependent on unix socket or do I get benefit from it either way?

Thanks.

xpose2000• 13 years ago

Is this .htaccess to nginx config convertor reliable? http://winginx.com/htaccess Seems like the biggest hurdle to adopting nginx is getting the config in order.

Nginx-1.4.0 stable version has been released

Related Stories