Live data from Hacker News

Building A Node.js Server That Won't Melt

hacks.mozilla.org

31–40 of 49 posts

Re: Building A Node.js Server That Won't Melt

#31

This is definitely neat; it's a simple, clever way to fail somewhat-gracefully. Interestingly, this is one piece of a broader strategy for building scalable web applications, addressed in Matt Welsh's thesis (SEDA): http://www.eecs.harvard.edu/~mdw/proj/seda/ If you haven't taken a look at the ideas in SEDA, it's definitely worth the time. Most modern web apps incorporate at least some pieces of it to great effect.

That's a very good technique! I did not even know about the event loop lag until now... It feels good to get a daily education from Hacker News!

Re: Building A Node.js Server That Won't Melt

#32

// 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"?

Nope, it is literally calculated asynchronously. Look at https://github.com/lloyd/node-toobusy/blob/master/toobusy.cc... and lines 91/92 which sets up the background timer.

Re: Building A Node.js Server That Won't Melt

#33
If you are writing server software, I recommend Michael Nygard's book "Release It!: Design and Deploy Production-Ready Software". Measuring event loop lag sounds like Nygard's "Circuit Breaker" pattern to avoid cascading failures.

The book's examples and text are all Java, but the lessons are applicable anywhere. He offers many scalability patterns (resource pools) and anti-patterns (runaway log files) with interesting stories from his experience debugging real systems. I especially liked his story about debugging a crash in an Oracle DB driver that caused unexpected Java exceptions to be thrown from java.sql.Statement.close(), which quickly blocked a DB connection pool.

http://michaelnygard.com/

Re: Building A Node.js Server That Won't Melt

#34
post #29

Earlier quoted context omitted.

You'd do it because it's npm install toobusy then somewhere in your project require("toobusy"); If you only need one server that's going to be up to a lot faster than putting anything in front of it.

If you only need one server that's going to be up to a lot faster than putting anything in front of it. A single server setup might be simpler, but it won't be faster. Varnish serving a cached page from memory is going to be faster than 5 asynchronous calls that take 5ms of CPU time (and filesystem I/O in the case of the database and template given in the example). With varnish, even with a 1 second TTL (and 1 second…

You have a problem, and so you try to solve it with caching. Now you have two problems.

I think that's how that quote goes.

Re: Building A Node.js Server That Won't Melt

#35
post #29

Earlier quoted context omitted.

You'd do it because it's npm install toobusy then somewhere in your project require("toobusy"); If you only need one server that's going to be up to a lot faster than putting anything in front of it.

If you only need one server that's going to be up to a lot faster than putting anything in front of it. A single server setup might be simpler, but it won't be faster. Varnish serving a cached page from memory is going to be faster than 5 asynchronous calls that take 5ms of CPU time (and filesystem I/O in the case of the database and template given in the example). With varnish, even with a 1 second TTL (and 1 second…

and what if your whole site is dynamic? varnish doesn't do anything.

Re: Building A Node.js Server That Won't Melt

#37
Forgive my ignorance, but I thought the whole point of Node.js was not to meltdown.

Are there some recommend resources I could learn more from about the out of the box scaling vs tactics and strategies that benefit growth? I love learning how this problem is tackled anywhere. :)

Re: Building A Node.js Server That Won't Melt

#38
post #29

Earlier quoted context omitted.

If you only need one server that's going to be up to a lot faster than putting anything in front of it. A single server setup might be simpler, but it won't be faster. Varnish serving a cached page from memory is going to be faster than 5 asynchronous calls that take 5ms of CPU time (and filesystem I/O in the case of the database and template given in the example). With varnish, even with a 1 second TTL (and 1 second…

and what if your whole site is dynamic? varnish doesn't do anything.

Very few sites are so dynamic that something can't be cached for at least a second. Even a heavily dynamic site like HN with people commenting all the time could at least cache for logged out users.

Re: Building A Node.js Server That Won't Melt

#39
post #29

Earlier quoted context omitted.

If you only need one server that's going to be up to a lot faster than putting anything in front of it. A single server setup might be simpler, but it won't be faster. Varnish serving a cached page from memory is going to be faster than 5 asynchronous calls that take 5ms of CPU time (and filesystem I/O in the case of the database and template given in the example). With varnish, even with a 1 second TTL (and 1 second…

You have a problem, and so you try to solve it with caching. Now you have two problems. I think that's how that quote goes.

I think of caching for apps like clothes for people...while you could survive naked, it's more comfortable with clothes, and you're protected from heat, cold, etc. Of course there is the problem of being over/under dressed, but you have to wear something.
Post reply on HN