
Nginx-1.4.0 stable version has been released - spindritf
http://nginx.org/#2013-04-24
======
atto
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.

~~~
ushi
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.

~~~
derefr
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.

~~~
ushi
> but why not just have the client do the pinging?

That's exactly what i meant. Sorry if it was unclear. I accidentally switched
proxy_send_timeout and proxy_read_timeout.

------
didip
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>

------
pavs
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...](http://www.howtoforge.com/forums/showthread.php?p=296263#post296263)

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

~~~
mattparlane
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.

~~~
pavs
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.

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

~~~
JennyZ
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?

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

~~~
JennyZ
Thanks but I'm not going to build it myself, I think it's better for me if I
leave that up to the package maintainers ^^

~~~
cerales
The Arch package maintainers' job mostly boils down to managing the PKGBUILD.
If you get comfortable using ABS your experience with Arch will improve
dramatically.

------
mixedbit
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?

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

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

~~~
beagle3
Only if your distro handles that for you; but point taken.

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

------
fourstar
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
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
Once you get used to it, it's a lot nicer to work with, too.

~~~
drazion
I whole heartedly agree - htaccess and virtual host rules were such a pain in
Apache, I've really come to appreciate how easy it was to get nginx setup in
comparison.

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

------
andyfleming
When will the Ubuntu PPA will be updated?

~~~
pfg
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>

------
mattparlane
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?

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

------
andyfleming
I'm getting a 504 on <http://wiki.nginx.org/>

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

~~~
InclinedPlane
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.

~~~
1SaltwaterC
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.

