

Node.js: details and best practices (a server side guy's analysis) - rpwilcox
http://www.wilcoxd.com/whitepapers/node_js/

======
blago
"Useful Javascript stuff I can NOT use (because it implicitly blocks):
Underscore.js"

Huh? So what are we going to hear next: "Don't use prototype inheritance
because chain traversal implicitly blocks"? Idiotic advise.

How about: Don't hold the event loop for too long. The faster you return, the
faster you can serve.

~~~
saurik
Maybe one day someone will invent a mechanism that can assign some kind of
time slice to each event being processed, and if it doesn't return control to
the master event coordinator, it could preempt that task somehow, storing the
context in which it is executing, and switching to a different one: that way
we could write code without having to worry about this kind of stuff.

Thinking about it more, while most people are using these event loops to
process unrelated web requests (the data being shared between these different
contexts likely being small), we'd still run into mild data corruption issues.
:( I guess we'd also then have to figure out a way to protect these critical
sections of our code... maybe some way to lock people out of your data while
you are using it.

(Silly pipe dream, I know.)

(edit: I've been thinking a lot about this idea, and I realized that once we
figure out all of those critical sections in the code, we might actually be
able to run multiple event loops on the same machine at once, taking advantage
of multiple CPUs or other types of execution core, without having to make any
other serious changes to our code. I'm starting to think someone should
actually work on this.)

------
jeromeparadis
It is hinted in the article that node.js is better for some use cases than
others. One thing node.js is good at is realtime apps and socket.io and the
evented model make these easier.

However, as a server developer guy too, I must point out that if scalability (
or premature optimization ) is dear to you, I would look further than cluster
to run multiple node processes. A good solution I found for a few projects is
to use Redis pub sub to encapsulate socket.io messages to connected clients to
make it easy, non-blocking and performant to scale to multiple nodes. For a
project where I have some potential CPU bound code, I further split these
operations in another process (let's say a game state machine with
calculations) with which I exchange pub sub messages. In such realtime apps,
the worst that can happen is that some process intensive functions may take a
bit more time to dispatch information to the clients but the core
communications node processes won't be blocked and will be screaming fast and
horizontally scalable.

I've found that Redis pub sub is awesome for simple and fast interprocess
communications.

------
davidhollander
> _Underscore.js for Iterations: each implicitly blocks_

???? Blocking refers to IO system calls. underscore is not an IO library. Does
a 15 year programmer with C++ experience not know what an O_NONBLOCK system
call is? Blocking or non blocking is about how you are performing IO with the
external world. It has nothing to do with the world internal to your program:
callbacks are merely correlated with nonblocking io, continuation passing
style does not constitute nonblocking in an of itself. You do not have to use
continuation passing style and lambdas for code that does not perform IO for
it to be "nonblocking".

~~~
rpwilcox
The way I understood it is that if I have a section of Javascript that takes,
say, 1/2 a second to run, and does not yield control back to the event loop,
by definition blocks the event loop from firing.

In a preemptive multithreaded environment it's different, but here you have
one single thread and - at least to my understanding - any code that takes
time to process blocks the event loop from being able to respond to incoming
requests.

Unless I'm missing something and node can (say) preempt your process at
certain defined conditions. ("Call a function? Ok, let's check the event loop
first and come right back"). I didn't see that anywhere (but I also didn't
want to dig into libenv.

I understand that IO is expensive, but so is performing string interpolation
on a string in memory 50 times (for whatever reason).

~~~
bigiain
This is exactly what Zed was pointing out with his intentionally pessimized
fibonacci generator.

Sure node can make waiting on disk or network asyncronous - but it's no silver
bullet, a poorly though out node.js server might scale just as badly as any
other poorly thought out server in any other language. You still need to
understand what's going on and not code yourself into the low performance
corners.

~~~
stock_toaster
> This is exactly what Zed was pointing out with his intentionally pessimized
> fibonacci generator.

You mean Ted Dziuba [1]?

[1]: <http://teddziuba.com/2011/10/node-js-is-cancer.html>

------
twog
Great information, horrible website. I dont expect every whitepaper, website,
or blog to have world class design, but this is information is horribly
displayed. There is no reason for a website in 2011 to look this way.

~~~
rpwilcox
It was originally written in OmniOutliner, then exported to HTML. I'll see
about tweaking the CSS...

------
Androsynth
One of the things I did was write a defer function (ie process.nextTick) and
just threw it anywhere I thought some operation could potentially be blocking.
This requires an analysis of latency vs bandwidth for your application (for
me, extra latency was acceptable and bandwidth was at a premium). This also
allows use of underscore libraries, albeit with extra defer calls everywhere.

Unfortunately I could not convince my old company to use node.js in production
because I was very curious to see how the extra function call overhead
compared against the extra bandwidth.

On another note, I was surprised that the eventEmitter callbacks are not
executed asynchronously. I assumed each one was run on the next tick. That
always struck me as inconsistent with the rest of the API.

------
bilalhusain
[disagreement with a select terminology eg. _research_ , _whitepaper_ ;
agreement with _analysis_ , _best practices_ ]

