Live data from Hacker News

Optimizing Nginx, Node.js and networking for heavy workloads

engineering.gosquared.com

1–10 of 26 posts

Re: Optimizing Nginx, Node.js and networking for heavy workloads

#2
have you tried making nodejs listen on a unix socket http://nodejs.org/docs/v0.5.4/api/net.html#socket.connect and then set your proxy upstreams in nginx to use that?

edit:

scratch that, it seems you're using node on cluster of servers (not on same box as nginx). In which case the article is good advice.

Re: Optimizing Nginx, Node.js and networking for heavy workloads

#3
For the tl;dr people:

On the nginx side, author discusses tweaking sysctl.conf, cutting down the number of sockets stuck in TIME_WAIT, some other tweaks for performance resulting in a 90% reduction in occupied sockets. On the node.js side, author uses the cluster module to fully utilize available CPU cores, arriving at N-1 for the magic number of node processes to spawn, where N is the # of CPU cores.

Definitely suggested reading for anyone running Nginx + Node.js

Re: Optimizing Nginx, Node.js and networking for heavy workloads

#8
post #5

Does this setup work with web sockets?

nginx doesn't support websockets quite yet, so no, but will do soon - http://trac.nginx.org/nginx/roadmap

nginx can support websockets via the tcp_proxy module: https://github.com/yaoweibin/nginx_tcp_proxy_module

Re: Optimizing Nginx, Node.js and networking for heavy workloads

#9
post #4

enabling net.ipv4.tcp_tw_reuse net.ipv4.tcp_tw_recycle can create unexpected problems with NAT, so use it with caution.

I only suggested changing tcp_tw_reuse but you are right, especially tcp_tw_recycle can have adverse effects.

According to this reference: http://www.speedguide.net/articles/linux-tweaking-121 "[tcp_tw_reuse] is generally a safer alternative to tcp_tw_recycle"

Re: Optimizing Nginx, Node.js and networking for heavy workloads

#10
Good read, but despite being a major proponent of Node.js and many of the ideals it seeks to embrace, I'm not sure I'm comfortable with calling Apache "archaic". It's not like IE6, which has objectively no redeeming value as a modern platform target -- it did back in the day for sure, and is still relevant in some spheres, but overall I don't think anyone (even Microsoft) would argue that IE6 is "archaic".

But to call Apache, one of the most popular and successful actively developed webservers _archaic_? I think that's a bit much. It's not inherently bad just because it's not really targeting the C10K problem... just different.

[A minor nitpick to be sure, but it bothered me nonetheless as I feel like I'm seeing this "Threads bad. Async good." rhetoric passed around as fact all over the place and it's starting to feel a bit like Animal Farm ;)]

Post reply on HN