But will it blend?
Building A Node.js Server That Won't Melt
11–20 of 49 posts
Re: Building A Node.js Server That Won't Melt
#12But will it blend?
like, make you a smoothie? Or do this: https://github.com/lloyd/node-toobusy/blob/master/toobusy.cc...
Re: Building A Node.js Server That Won't Melt
#13Why 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 think this would simplify implementing a load-balancing proxy in some ways. If a server responds with a 503 generated by node-toobusy, the load balancer will know immediately to reroute the request to another server, rather than having to wait for a timeout or some other threshold.
Re: Building A Node.js Server That Won't Melt
#14Re: Building A Node.js Server That Won't Melt
#15This is great to see! IMO it's something that should be configurable and built into http in node.js.
IIS [1] and other mature web servers like nginx [2] or apache [3] do this kind of thing for you and provide simple configuration on it.
[1] http://support.microsoft.com/kb/943891 [2] http://serverfault.com/questions/412323/nginx-503-error-in-h... [3] http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequ...
Re: Building A Node.js Server That Won't Melt
#16This is great to see! IMO it's something that should be configurable and built into http in node.js. IIS [1] and other mature web servers like nginx [2] or apache [3] do this kind of thing for you and provide simple configuration on it. [1] http://support.microsoft.com/kb/943891 [2] http://serverfault.com/questions/412323/nginx-503-error-in-h... [3] http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequ...
Node itself is a bit low level for this functionality, but it could be built into frameworks like Express.
Re: Building A Node.js Server That Won't Melt
#17i thought node.js was fast as hell bad ass rock star tech that would never melt.
Re: Building A Node.js Server That Won't Melt
#18i thought node.js was fast as hell bad ass rock star tech that would never melt. http://www.youtube.com/watch?v=bzkRVzciAZg
well it's still pretty bad ass and rock star that you can measure server load by looking at "event loop lag", that's actually really neat... how do you do that with threads?
Re: Building A Node.js Server That Won't Melt
#19// 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"?
Side note: caching at a fixed interval is a great way to save CPU cycles. If you're serving 100req/s and you had to grab the current time within 1sec accuracy for them, you could have 1/100th the amount of Date calls by getting the time each second instead of each request.
Re: Building A Node.js Server That Won't Melt
#20Earlier quoted context omitted.
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.
It seems to me that letting the computer calculate when it's in trouble is preferable to have a human guessing.