Building A Node.js Server That Won't Melt
hacks.mozilla.org
Building A Node.js Server That Won't Melt
1–10 of 49 posts
Re: Building A Node.js Server That Won't Melt
#2Why you would do this, instead of putting your node server behind a more battle tested proxy, like Varnish or HAProxy, and limiting the number of simultaneous connections.
Re: Building A Node.js Server That Won't Melt
#3Why you would do this, instead of putting your node server behind a more battle tested proxy, like Varnish or HAProxy, and limiting the number of simultaneous connections.
Because that is a lot of work, and this is a drop-in solution for any node application?
Re: Building A Node.js Server That Won't Melt
#4Why you would do this, instead of putting your node server behind a more battle tested proxy, like Varnish or HAProxy, and limiting the number of simultaneous connections.
Our problem is the the number of simultaneous connections we can support isn't static, it varies depending on the type of traffic bursts (i.e. New vs. Returning users).
But agree that a higher level proxy is useful - because this way your overloaded application doesn't even need to deal with traffic (we hope to use toobusy to have applications instruct the routing layer to temporarily block / reroute traffic in times of load).
Re: Building A Node.js Server That Won't Melt
#5 // check if we're toobusy() - note, this call is extremely fast, and returns
// state that is calculated asynchronously.
if (toobusy()) res.send(503, "I'm busy right now, sorry.");
Re: Building A Node.js Server That Won't Melt
#6Why you would do this, instead of putting your node server behind a more battle tested proxy, like Varnish or HAProxy, and limiting the number of simultaneous connections.
You'd do it because it's
npm install toobusy
require("toobusy");
Re: Building A Node.js Server That Won't Melt
#7Why you would do this, instead of putting your node server behind a more battle tested proxy, like Varnish or HAProxy, and limiting the number of simultaneous connections.
I'd prefer that solution too, especially since such proxies can mitigate some types of DoS attacks (e.g. known patterns in the "Referer" header, or from known IP address ranges) and load will generally be much lower if some of the popular content is cacheable.
Re: Building A Node.js Server That Won't Melt
#8// check if we're toobusy() - note, this call is extremely fast, and returns // state that is calculated asynchronously. if (toobusy()) res.send(503, "I'm busy right now, sorry."); Saying it is calculated "asynchronously" seems pretty confusing in this context. Maybe "is cached at a fixed interval"?
I agree. /me fixes
Re: Building A Node.js Server That Won't Melt
#9Why you would do this, instead of putting your node server behind a more battle tested proxy, like Varnish or HAProxy, and limiting the number of simultaneous connections.
Our problem is the the number of simultaneous connections we can support isn't static, it varies depending on the type of traffic bursts (i.e. New vs. Returning users). But agree that a higher level proxy is useful - because this way your overloaded application doesn't even need to deal with traffic (we hope to use toobusy to have applications instruct the routing layer to temporarily block / reroute traffic in times…
The reason that I asked that is I feel that most applications end up needing something at that layer eventually anyways, but not knowing exactly what level of traffic results in too much load is a good reason to do this.
Re: Building A Node.js Server That Won't Melt
#10Why you would do this, instead of putting your node server behind a more battle tested proxy, like Varnish or HAProxy, and limiting the number of simultaneous connections.
Do both: each layer and service in an application should be able to manage its own load. Helps prevent cascading failures too.
Read up on Netflix's architecture, where they've talked about this a lot. And the book "Release It!: Design and Deploy Production-Ready Software" (Nygard), though Java-oriented in its examples, covers the concepts well.